Every new UI component that we add to VS Code needs to be accessible so all developers out there can use it with joy. If you have not already, please read these public facing docs as well: https://code.visualstudio.com/docs/editor/accessibility and https://www.w3.org/TR/WCAG20/#guidelines.
Test the feature with a screen reader to determine if the feature could benefit from an explanation. To educate screen reader users about what to expect and how to interact with a new feature, an accessibility.verbosity setting and an accessibility help menu should be added via registerProvider on IAccessibleViewService.
If you are using an existing widget in your component you still need to make sure the new experience is accessible by trying it out. Interact with it using the keyboard and by turning on a Screen Reader and make sure the content that is announced is informative. For example, if you are using a List widget, you might have missed that you need to implement an IListAccessibilityProvider.
If the component is introducing colors make sure all colors pass the required color contrast:
- HC themes - all color contrast MUST be at least
4.5:1but we SHOULD strive towards7:1. - All other themes everything inside the Editor MUST be
3:1but we SHOULD strive towards4.5:1. Everything outside the Editor MUST be4.5:1
Every actionable element in your component needs to be keyboard navigable, or there needs to be a great keyboard alternative. No functionality should only be accessed by mouse. Focus movement in your experience should go in a naturaly visual way. Focus can also be moved using arrow keys to save on tabs tops - ActionBar is doing that right now.
When an element gets focus, a screen reader will read something if the element has an aria-label attribute set. Set an informative aria-label attribute on the element that gets focus. aria-label should be informative but concise. Always make sure to put the most important information to the front of the aria-label so if users skip the announcement they first hear the important stuff. When there are multiple things to express in the aria label , separate them. For example, here's an aria-label of one Breakpoint: main.js 12, ~/Development/vscode/src/main.js. First the most important information: filename and line number, and then comma separated additional details.
Ideally aria announcements are done as focus moves in VS Code, however in some experiences that is not possible (e.g. parameter hints). In those cases you our helper method aria.alert to announce. This should be used as a workaround, since we can not control when the screen reader announces these alerts.
It’s best to use a native HTML control if possible, but roles are available when we are building custom components.
Make sure controls have associated labels.
Some experiences can be enriched with audio cues (e.g. existence of a breakpoint on a line). Audio cues should be used when just focus and aria-label are not enough. When in doubt, reach out to Megan Rogge and she can also put you in contact with our sound designer.
Important accessibility issues are labeled with the accessibility-sla tag. Please prioritize the fix or reply in the issue within ~ 30 days. Also feel free to reach out to Megan Rogge or Isidor Nikolic for help.
The most common screen readers used per platform are:
- Windows - NVDA, JAWS, Narrator (in descending order of support)
- MacOS - VoiceOver
- Linux - Orca (often is tricky)