VS Code Accessibility Development Guide
A practical specification for accessible interactive features in VS Code.
This is implementation guidance rather than an executable capability: it requests no credentials, external service access, or data transfer, and it promotes keyboard access, focus restoration, and localization. No red-line risk is visible. Points are deducted because it mandates broad use for interactive UI without specifying permission boundaries, user confirmation, rollback, sensitive-data handling, or abnormal-recovery procedures.
The document gives stepwise procedures, TypeScript skeletons, key interfaces, and registration locations, making the happy path reasonably clear. The examples contain placeholders and there are no skill-specific tests, compatibility matrix, or failure-feedback procedures; the static-review cap limits this to 8.
The target audience and scenarios are explicit, and it distinguishes rich visual content from simple keyboard-driven input. Points are deducted because the default applicability may over-trigger, boundaries for existing or complex implementations remain limited, and there is no evidence of Chinese-language support or mainland-China network reachability.
The document has clear sections, progressive steps, examples, a checklist, and key-file references; repository context also provides MIT licensing and Microsoft maintenance provenance. Points are deducted because the skill itself lacks a version, changelog, named maintenance responsibility, explicit update path, troubleshooting guidance, and FAQ.
It directly guides implementation of accessibility help, accessible views, settings, signals, ARIA behavior, and keyboard navigation, so it covers the core task. Points are deducted because the skeletons require substantial feature-specific adaptation and no evidence shows that outputs were verified as directly mergeable or requiring only light review.
The skill names concrete interfaces, files, and existing feature patterns, providing some auditability. The supplied repository contains CI and test materials, but they do not cover this skill's key paths. There are no skill-specific tests, independent review, or execution records, so 4 is appropriate under static calibration.
- This is a static source review; the examples, build, and screen-reader behavior were not executed, so repository CI must not be treated as validation of the skill.
- The broad default requirement for any interactive UI may over-trigger and add process burden; contributors still need to judge the feature type and existing implementation manually.
- Focus restoration, content generation, and service injection in the examples remain placeholders and require feature-specific tests, error handling, and cross-platform screen-reader verification before merge.
- No evidence is provided for Chinese documentation, translation quality, or mainland-China network reachability.
What it does & when to use it
This skill is defined by .github/skills/accessibility/SKILL.md in the microsoft/vscode repository. It makes accessibility a default concern for new features, contributions, and changes to existing UI, covering help dialogs, accessible views, verbosity settings, signals, ARIA announcements, keyboard navigation, and ARIA semantics. For a new interactive UI surface, it specifies how to provide an accessibility help dialog, an accessible view when visual content requires one, and a verbosity setting. It is intended for contributors developing VS Code workbench, editor, extension, or other interactive UI changes.
It instructs contributors to add AccessibleViewProviderId and AccessibilityVerbositySettingId entries, register the verbosity configuration, and implement and register IAccessibleViewImplementation providers. It requires localized help content and dynamic keybinding syntax, and it describes how to expose rich visual content as plain text through an accessible view. It also explains how to use IAccessibilitySignalService with existing signals, publish dynamic messages through aria.alert() or aria.status(), and implement keyboard operation, focus restoration, ARIA labels, roles, and state attributes. The documented implementation points include accessibleView.ts, accessibleViewRegistry.ts, accessibilityConfiguration.ts, accessibilitySignalService.ts, and aria.ts.
- A VS Code contributor adding a panel, view, editor overlay, widget, or dialog who needs screen-reader support from the start.
- A developer exposing rich visual content from a terminal, chat panel, notebook, diff editor, or similar feature through an accessible view.
- A maintainer adding commands, shortcuts, or interactive behavior to an existing feature and updating its accessibility help dialog.
- A UI contributor changing dynamic states or notifications who needs appropriate accessibility signals, ARIA announcements, keyboard behavior, and labels.
Pros & cons
- It covers the main implementation areas: help dialogs, accessible views, settings, signals, ARIA announcements, keyboard navigation, and semantic attributes.
- It includes TypeScript skeletons, registration locations, key interfaces, and relevant source files.
- It explicitly requires updating provideContent() for new commands and interactions in existing features, supporting discoverability for screen-reader users.
- It gives concrete guidance for keyboard access, focus restoration, dynamic announcements, and localization.
- It is a source-development guide, not a standalone accessibility testing or automatic repair tool.
- The supplied material does not provide a dedicated installation command, automated test suite, or test results for the skill.
- Implementation requires editing VS Code TypeScript source and making feature-specific judgments about accessible views and signals.
- New accessibility signals should not be registered without first coordinating with @meganrogge, according to the source.
How to install
The repository README does not document a separate installation procedure for this individual skill. After obtaining the repository, keep or place the file at microsoft/vscode/.github/skills/accessibility/SKILL.md; the supplied material does not specify a standalone installation command for the skill.
How to use
When asking an Agent to modify an interactive VS Code feature, use a prompt such as “Add a new VS Code panel with complete accessibility support” or “Add keyboard shortcuts to this existing view and update its accessibility help dialog.” Apply the skill by default to new features and contributions, and to existing UI changes; implement the documented help dialog, accessible view when needed, verbosity setting, signals, ARIA announcements, keyboard behavior, and labels according to the feature's scope.