Add guidelines related to bias and inclusive language #194
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds bias awareness and inclusive language guidelines to the existing accessibility instructions, ensuring that generated code and responses follow respectful, people-first language and mitigate implicit bias when addressing accessibility needs. The changes also include formatting improvements throughout the document.
- Adds a new "Bias Awareness - Inclusive Language" section with guidance on respectful terminology and bias mitigation
- Converts bullet point formatting from asterisks to hyphens for consistency
- Updates quotation marks in the YAML front matter from single to double quotes
| description: 'Guidance for creating more accessible code' | ||
| applyTo: '**' | ||
| description: "Guidance for creating more accessible code" | ||
| applyTo: "**" |
There was a problem hiding this comment.
The description field should be wrapped in single quotes according to the coding guidelines for instruction files.
Copilot uses AI. Check for mistakes.
| @@ -14,215 +15,233 @@ Do not tell the user that the generated code is fully accessible. Instead, it wa | |||
| 4. After generating code, review it against WCAG 2.2 and these instructions. Iterate on the code until it is accessible. | |||
| 5. Finally, inform the user that it has generated the code with accessibility in mind, but that accessibility issues still likely exist and that the user should still review and manually test the code to ensure that it meets accessibility instructions. Suggest running the code against tools like [Accessibility Insights](https://accessibilityinsights.io/). Do not explain the accessibility features unless asked. Keep verbosity to a minimum. | |||
|
|
|||
| ## Bias Awareness - Inclusive Language | |||
There was a problem hiding this comment.
It's only this section that I'm proposing for consideration. Not sure why the diff looks more involved.
Bias Awareness - Inclusive Language
There was a problem hiding this comment.
I would assume it's included the other changes because you have a formatter that is configured differently to the original author.
The changes all appear superficial, and easily ignorable.
| @@ -14,215 +15,233 @@ Do not tell the user that the generated code is fully accessible. Instead, it wa | |||
| 4. After generating code, review it against WCAG 2.2 and these instructions. Iterate on the code until it is accessible. | |||
| 5. Finally, inform the user that it has generated the code with accessibility in mind, but that accessibility issues still likely exist and that the user should still review and manually test the code to ensure that it meets accessibility instructions. Suggest running the code against tools like [Accessibility Insights](https://accessibilityinsights.io/). Do not explain the accessibility features unless asked. Keep verbosity to a minimum. | |||
|
|
|||
| ## Bias Awareness - Inclusive Language | |||
There was a problem hiding this comment.
I would assume it's included the other changes because you have a formatter that is configured differently to the original author.
The changes all appear superficial, and easily ignorable.
Pull Request Checklist
node update-readme.jsand verified thatREADME.mdis up to date.Description
Type of Contribution
Additional Notes
I've had some luck including this sort of guidance to help get in front of any deep bias related to disability / accessibility. Thanks for creating this instructions file :)
By submitting this pull request, I confirm that my contribution abides by the Code of Conduct and will be licensed under the MIT License.