accessibility

The accessibility skill is VS Code's primary guidance for building accessible user interfaces and is treated as required for new feature and contribution work, as well as updates to existing UI -- even when a request never mentions accessibility. It covers accessibility help dialogs, accessible views, verbosity settings, signals, ARIA announcements, keyboard navigation, and ARIA labels and roles.

Its central rule is that any new interactive UI surface -- a panel, view, widget, editor overlay, dialog, or rich focusable component -- must ship three accessibility components when they do not already exist: an accessibility help dialog opened via the help keybinding when the feature has focus, an accessible view that presents the feature's content as plain read-only text for screen reader users, and an accessibility verbosity setting that controls whether the help hint is announced. The accessible view is required only when the feature renders rich or visual content a screen reader cannot read directly; a purely keyboard-driven surface with native text input needs only the help dialog. Established features such as the terminal, chat panel, notebook, and diff editor are cited as having all three.

The document gives concrete implementation steps and code skeletons: implementing IAccessibleViewImplementation with the Help or View type, building an AccessibleContentProvider with provideContent() and onClose() to restore focus, and registering via AccessibleViewRegistry in the feature's contribution file. It also stresses that when updating an existing feature by adding commands or shortcuts, the feature's existing help dialog provideContent() must be updated so screen reader users can discover the new functionality. Later sections on signals, ARIA, and keyboard navigation apply to any UI change.