Agent skill · software engineering · microsoft

accessibility

Primary accessibility skill for VS Code. REQUIRED for new feature and contribution work, and also applies to updates of existing UI. Covers accessibility help dialogs, accessible views, verbosity settings, signals, ARIA announcements, keyboard navigation, and ARIA labels/roles.

Why this skill is useful

Provides specific implementation patterns and requirements for creating accessible UI components in VS Code that the AI wouldn't reliably generate on its own.

What it needs

About 8k tokens when loaded. Last updated 2026-08-07. 188,455 stars on the source repository.

What this skill does

When to Use This Skill Use this skill for any VS Code feature work that introduces or changes interactive UI. Use this skill by default for new features and contributions, including when the request does not explicitly mention accessibility. Trigger examples: "add a new feature" "implement a new panel/view/widget" "add a new command or workflow" "new contribution in workbench/editor/extensions" "update existing UI interactions" Do not skip this skill just because accessibility is not named in the prompt. When adding a new interactive UI surface to VS Code — a panel, view, widget, editor overlay, dialog, or any rich focusable component the user interacts with — you must provide three accessibility components (if they do not already exist for the feature): 1. An Accessibility Help Dialog — opened via the accessibility help keybinding when the feature has focus. 2. An Accessible View — a plain-text read-only editor that presents the feature's content to screen reader users (when the feature displays non-trivial visual content). 3. An Accessibility Verbosity Setting — a boolean setting that controls whether the "open accessibility help" hint is announced. Examples of existing features that have all three: the terminal, chat panel, notebook, diff editor, inline completions, comments, debug REPL, hover, and notifications. Features with only a help dialog (no accessible view) include find widgets, source control input, keybindings editor, problems panel, and walkthroughs. Sections 4–7 below (signals, ARIA announcements, keyboard navigation, ARIA labels) apply more broadly to any UI change, including modifications to existing features. When updating an existing feature — for example, adding new commands, keyboard shortcuts, or interactive capabilities — you must also update the feature's existing accessibility help dialog (provideContent()) to document the new functionality. Screen reader users rely on the help dialog as the primary way to discover available actions. …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills microsoft/accessibility

View the source on GitHub

Browse the @skills marketplace