[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6998Z08DTEAE5C2MC35E8ZR":3,"skill-same:01M6998Z08DTEAE5C2MC35E8ZR":99},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":46,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M6998Z08DTEAE5C2MC35E8ZR","accessibility",null,"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\u002Froles.","microsoft\u002Fvscode","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6998NK2WED5M549DX06VBCH",195270,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Faccessibility\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"signals","labels","Existing","for","updates","keyboard","contribution","feature","roles","aria","navigation","new feature","settings","work","ui","help","code","2026-11-10 10:12:30",false,"---\nname: accessibility\ndescription: 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\u002Froles.\n---\n\n## When to Use This Skill\n\nUse 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.\n\nTrigger examples:\n- \"add a new feature\"\n- \"implement a new panel\u002Fview\u002Fwidget\"\n- \"add a new command or workflow\"\n- \"new contribution in workbench\u002Feditor\u002Fextensions\"\n- \"update existing UI interactions\"\n\nDo not skip this skill just because accessibility is not named in the prompt.\n\nWhen 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):\n\n1. **An Accessibility Help Dialog** — opened via the accessibility help keybinding when the feature has focus.\n2. **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).\n3. **An Accessibility Verbosity Setting** — a boolean setting that controls whether the \"open accessibility help\" hint is announced.\n\nExamples 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**.\n\nSections 4–7 below (signals, ARIA announcements, keyboard navigation, ARIA labels) apply more broadly to **any UI change**, including modifications to existing features.\n\nWhen **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.\n\n---\n\n## 1. Accessibility Help Dialog\n\nAn accessibility help dialog tells the user what the feature does, which keyboard shortcuts are available, and how to interact with it via a screen reader.\n\n### Steps\n\n1. **Create a class implementing `IAccessibleViewImplementation`** with `type = AccessibleViewType.Help`.\n   - Set a `priority` (higher = shown first when multiple providers match).\n   - Set `when` to a `ContextKeyExpression` that matches when the feature is focused.\n   - `getProvider(accessor)` returns an `AccessibleContentProvider`.\n\n2. **Create a content-provider class** implementing `IAccessibleViewContentProvider`.\n   - `id` — add a new entry in the `AccessibleViewProviderId` enum in `src\u002Fvs\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleView.ts`.\n   - `verbositySettingKey` — reference the new `AccessibilityVerbositySettingId` entry (see §3).\n   - `options` — `{ type: AccessibleViewType.Help }`.\n   - `provideContent()` — return localized, multi-line help text.\n\n3. **Implement `onClose()`** to restore focus to whatever element was focused before the help dialog opened. This ensures keyboard users and screen reader users return to their previous context.\n\n4. **Register** the implementation:\n   ```ts\n   AccessibleViewRegistry.register(new MyFeatureAccessibilityHelp());\n   ```\n   in the feature's `*.contribution.ts` file.\n\n### Example skeleton\n\nThe simplest approach is to return an `AccessibleContentProvider` directly from `getProvider()`. This is the most common pattern in the codebase (used by chat, inline chat, quick chat, etc.):\n\n```ts\nimport { AccessibleViewType, AccessibleContentProvider, AccessibleViewProviderId } from '..\u002F..\u002F..\u002F..\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleView.js';\nimport { IAccessibleViewImplementation } from '..\u002F..\u002F..\u002F..\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleViewRegistry.js';\nimport { AccessibilityVerbositySettingId } from '..\u002F..\u002F..\u002F..\u002Fplatform\u002Faccessibility\u002Fcommon\u002FaccessibilityConfiguration.js';\n\nexport class MyFeatureAccessibilityHelp implements IAccessibleViewImplementation {\n\treadonly priority = 100;\n\treadonly name = 'my-feature';\n\treadonly type = AccessibleViewType.Help;\n\treadonly when = MyFeatureContextKeys.isFocused;\n\n\tgetProvider(accessor: ServicesAccessor) {\n\t\tconst helpText = [\n\t\t\tlocalize('myFeature.help.overview', \"You are in My Feature. …\"),\n\t\t\tlocalize('myFeature.help.key1', \"- {0}: Do something\", '\u003Ckeybinding:myFeature.doSomething>'),\n\t\t].join('\\n');\n\t\treturn new AccessibleContentProvider(\n\t\t\tAccessibleViewProviderId.MyFeature,\n\t\t\t{ type: AccessibleViewType.Help },\n\t\t\t() => helpText,\n\t\t\t() => { \u002F* onClose — refocus whatever was focused before *\u002F },\n\t\t\tAccessibilityVerbositySettingId.MyFeature,\n\t\t);\n\t}\n}\n```\n\nAlternatively, if the provider needs injected services or must track state (e.g., storing a reference to the previously focused element), create a custom class that extends `Disposable` and implements `IAccessibleViewContentProvider`, then instantiate it via `IInstantiationService` (see `CommentsAccessibilityHelpProvider` for an example):\n\n```ts\nclass MyFeatureAccessibilityHelpProvider extends Disposable implements IAccessibleViewContentProvider {\n\treadonly id = AccessibleViewProviderId.MyFeature;\n\treadonly verbositySettingKey = AccessibilityVerbositySettingId.MyFeature;\n\treadonly options: IAccessibleViewOptions = { type: AccessibleViewType.Help };\n\n\tprovideContent(): string { \u002F* … *\u002F }\n\tonClose(): void { \u002F* … *\u002F }\n}\n\n\u002F\u002F In getProvider():\ngetProvider(accessor: ServicesAccessor) {\n\treturn accessor.get(IInstantiationService).createInstance(MyFeatureAccessibilityHelpProvider);\n}\n```\n\n---\n\n## 2. Accessible View\n\nAn accessible view presents the feature's visual content as plain text in a read-only editor. It is required when the feature renders rich or visual content that a screen reader cannot directly read (for example: chat responses, hover tooltips, notifications, terminal output, inline completions).\n\nIf the feature is purely keyboard-driven with native text input\u002Foutput (e.g., a simple input field), an accessible view is not needed — only an accessibility help dialog is required.\n\n### Steps\n\n1. **Create a class implementing `IAccessibleViewImplementation`** with `type = AccessibleViewType.View`.\n2. **Create a content-provider** similar to the help dialog, but:\n   - `options` — `{ type: AccessibleViewType.View }`, optionally with a `language` for syntax highlighting.\n   - `provideContent()` — return the feature's current content as plain text.\n   - Optionally implement `provideNextContent()` \u002F `providePreviousContent()` for item-by-item navigation.\n   - Implement `onClose()` to restore focus to whatever was focused before the accessible view was opened.\n   - Optionally provide `actions` for actions the user can take from the accessible view.\n3. **Register** alongside the help dialog:\n   ```ts\n   AccessibleViewRegistry.register(new MyFeatureAccessibleView());\n   ```\n\n### Example skeleton\n\n```ts\nexport class MyFeatureAccessibleView implements IAccessibleViewImplementation {\n\treadonly priority = 100;\n\treadonly name = 'my-feature';\n\treadonly type = AccessibleViewType.View;\n\treadonly when = MyFeatureContextKeys.isFocused;\n\n\tgetProvider(accessor: ServicesAccessor) {\n\t\t\u002F\u002F Retrieve services, build content from the feature's current state\n\t\tconst content = getMyFeatureContent();\n\t\tif (!content) {\n\t\t\treturn undefined;\n\t\t}\n\t\treturn new AccessibleContentProvider(\n\t\t\tAccessibleViewProviderId.MyFeature,\n\t\t\t{ type: AccessibleViewType.View },\n\t\t\t() => content,\n\t\t\t() => { \u002F* onClose — refocus whatever was focused before the accessible view opened *\u002F },\n\t\t\tAccessibilityVerbositySettingId.MyFeature,\n\t\t);\n\t}\n}\n```\n\n---\n\n## 3. Accessibility Verbosity Setting\n\nA verbosity setting controls whether a hint such as \"press Alt+F1 for accessibility help\" is announced when the feature gains focus. Users who already know the shortcut can disable it.\n\n### Steps\n\n1. **Add an entry** to `AccessibilityVerbositySettingId` in `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Faccessibility\u002Fbrowser\u002FaccessibilityConfiguration.ts`:\n   ```ts\n   export const enum AccessibilityVerbositySettingId {\n       \u002F\u002F … existing entries …\n       MyFeature = 'accessibility.verbosity.myFeature'\n   }\n   ```\n\n2. **Register the configuration property** in the same file's `configuration.properties` object:\n   ```ts\n   [AccessibilityVerbositySettingId.MyFeature]: {\n       description: localize('verbosity.myFeature.description',\n           'Provide information about how to access the My Feature accessibility help menu when My Feature is focused.'),\n       ...baseVerbosityProperty\n   },\n   ```\n   The `baseVerbosityProperty` gives it `type: 'boolean'`, `default: true`, and `tags: ['accessibility']`.\n\n3. **Reference the setting key** in both the help-dialog provider (`verbositySettingKey`) and the accessible-view provider so the runtime can check whether to show the hint.\n\n---\n\n## 4. Accessibility Signals (Sounds & Announcements)\n\nAccessibility signals provide audible and spoken feedback for events that happen visually. Use `IAccessibilitySignalService` to play signals when something important occurs (e.g., an error appears, a task completes, content changes).\n\n### When to use\n\n- **Use an existing signal** when the event already has one defined (see `AccessibilitySignal.*` static members — e.g., `AccessibilitySignal.error`, `AccessibilitySignal.terminalQuickFix`, `AccessibilitySignal.clear`).\n- **If no existing signal fits**, reach out to @meganrogge to discuss adding a new one. Do not register new signals without coordinating first.\n\n### How signals work\n\nEach signal has two modalities controlled by user settings:\n- **Sound** — a short audio cue, configurable to `auto` (on when screen reader attached), `on`, or `off`.\n- **Announcement** — a spoken message via `aria-live`, configurable to `auto` or `off`.\n\n### Usage\n\n```ts\n\u002F\u002F Inject the service via constructor parameter\nconstructor(\n\t@IAccessibilitySignalService private readonly _accessibilitySignalService: IAccessibilitySignalService\n) { }\n\n\u002F\u002F Play a signal\nthis._accessibilitySignalService.playSignal(AccessibilitySignal.terminalQuickFix);\n\n\u002F\u002F Play with options\nthis._accessibilitySignalService.playSignal(AccessibilitySignal.error, { userGesture: true });\n```\n\n---\n\n## 5. ARIA Alerts vs. Status Messages\n\nUse the `alert()` and `status()` functions from `src\u002Fvs\u002Fbase\u002Fbrowser\u002Fui\u002Faria\u002Faria.ts` to announce dynamic changes to screen readers.\n\n### `alert(msg)` — Assertive live region (`role=\"alert\"`)\n- **Use for**: Urgent, important information that the user must know immediately.\n- **Examples**: Errors, warnings, critical state changes, results of a user-initiated action.\n- **Behavior**: Interrupts the screen reader's current speech.\n\n### `status(msg)` — Polite live region (`aria-live=\"polite\"`)\n- **Use for**: Non-urgent, informational updates that should be spoken when the screen reader is idle.\n- **Examples**: Progress updates, search result counts, background state changes.\n- **Behavior**: Queued and spoken after the screen reader finishes its current output.\n\n### Guidelines\n\n- **Prefer `status()` over `alert()`** unless the information is time-sensitive or the result of a direct user action. Overusing `alert()` creates a noisy, disruptive experience.\n- **Keep messages concise.** Screen readers read the entire message; long messages delay the user.\n- **Do not duplicate** — if an accessibility signal already announces the event, do not also call `alert()` \u002F `status()` for the same information.\n- **Localize** all messages with `nls.localize()`.\n\n---\n\n## 6. Keyboard Navigation\n\nEvery interactive UI element must be fully operable via the keyboard.\n\n### Requirements\n\n- **Tab order**: All interactive elements must be reachable via `Tab` \u002F `Shift+Tab` in a logical order.\n- **Arrow key navigation**: Lists, trees, grids, and toolbars must support arrow key navigation following WAI-ARIA patterns.\n- **Focus visibility**: Focused elements must have a visible focus indicator (VS Code's theme system provides this via `focusBorder`).\n- **No mouse-only interactions**: Every action reachable by click or hover must also be reachable via keyboard (context menus, buttons, toggles, etc.).\n- **Escape to dismiss**: Overlays, dialogs, and popups must be dismissable with `Escape`, returning focus to the previous element.\n- **Focus trapping**: Modal dialogs must trap focus within the dialog until dismissed.\n\n### Explaining unavailable options\n\nFollow the [discoverable unavailable-feature pattern](..\u002Fdesign-philosophy\u002FSKILL.md#make-unavailable-features-understandable): a feature promoted in documentation should not become inexplicably absent solely because the user cannot enable it. Announce both the disabled state and its reason using the control's supported ARIA semantics; a grey label, briefcase icon, or hover alone is insufficient. Keep icons decorative when text already conveys their meaning.\n\nExplanatory links must remain independently mouse- and keyboard-operable without activating the disabled option. Verify actual Tab\u002FShift+Tab and Enter behavior, not just `tabIndex` or a programmatic `focus()`; list navigation may skip disabled rows. Preserve focus\u002Fselection on policy refresh, guard stale actions, and update the feature's accessibility help with the available explanation and next step. Reuse the settings, model, harness, and permission-picker examples linked in the design guidance.\n\n---\n\n## 7. ARIA Labels and Roles\n\nAll interactive UI elements must have appropriate ARIA attributes so screen readers can identify and describe them.\n\n### Requirements\n\n- **`aria-label`**: Every interactive element without visible text (icon buttons, icon-only actions, custom widgets) must have a descriptive `aria-label`. Labels should be localized.\n- **`aria-labelledby`** \u002F **`aria-describedby`**: Use these to associate elements with existing visible text rather than duplicating strings.\n- **`role`**: Custom widgets that do not use native HTML elements must declare the correct ARIA role (e.g., `role=\"button\"`, `role=\"tree\"`, `role=\"tablist\"`).\n- **`aria-expanded`**, **`aria-selected`**, **`aria-checked`**: Toggle and selection states must be communicated via the appropriate ARIA state attributes.\n- **`aria-hidden=\"true\"`**: Decorative or redundant elements (icons next to text labels, decorative separators) must be hidden from the accessibility tree.\n\n### Guidelines\n\n- Avoid generic labels like \"button\" or \"icon\" — describe the action: \"Close panel\", \"Toggle sidebar\", \"Run task\".\n- Test with a screen reader (VoiceOver on macOS, NVDA on Windows) to verify labels are spoken correctly in context.\n- Lists and trees should use `aria-setsize` and `aria-posinset` when virtualized so screen readers report the correct count.\n\n---\n\n## Checklist for Every New Feature\n\n- [ ] New `AccessibleViewProviderId` entry added in `accessibleView.ts`\n- [ ] New `AccessibilityVerbositySettingId` entry added in `accessibilityConfiguration.ts`\n- [ ] Verbosity setting registered in the configuration properties with `...baseVerbosityProperty`\n- [ ] `IAccessibleViewImplementation` with `type = Help` created and registered\n- [ ] Content provider references the correct `verbositySettingKey`\n- [ ] Help text is fully localized using `nls.localize()`\n- [ ] Keybindings in help text use `\u003Ckeybinding:commandId>` syntax for dynamic resolution\n- [ ] `when` context key is set so the dialog only appears when the feature is focused\n- [ ] If the feature has rich\u002Fvisual content: `IAccessibleViewImplementation` with `type = View` created and registered\n- [ ] Registration calls in the feature's `*.contribution.ts` file\n- [ ] Accessibility signal played for important events (use existing `AccessibilitySignal.*` or register a new one)\n- [ ] `aria.alert()` or `aria.status()` used appropriately for dynamic changes (prefer `status()` unless urgent)\n- [ ] All interactive elements reachable and operable via keyboard\n- [ ] All interactive elements without visible text have a localized `aria-label`\n- [ ] Custom widgets declare the correct ARIA `role` and state attributes\n- [ ] Decorative elements are hidden with `aria-hidden=\"true\"`\n\n## Key Files\n\n- `src\u002Fvs\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleView.ts` — `AccessibleViewProviderId`, `AccessibleContentProvider`, `IAccessibleViewContentProvider`\n- `src\u002Fvs\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleViewRegistry.ts` — `AccessibleViewRegistry`, `IAccessibleViewImplementation`\n- `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Faccessibility\u002Fbrowser\u002FaccessibilityConfiguration.ts` — `AccessibilityVerbositySettingId`, verbosity setting registration\n- `src\u002Fvs\u002Fplatform\u002FaccessibilitySignal\u002Fbrowser\u002FaccessibilitySignalService.ts` — `IAccessibilitySignalService`, `AccessibilitySignal`\n- `src\u002Fvs\u002Fbase\u002Fbrowser\u002Fui\u002Faria\u002Faria.ts` — `alert()`, `status()` for ARIA live region announcements\n","## When to Use This Skill\n\nUse 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.\n\nTrigger examples:\n- \"add a new feature\"\n- \"implement a new panel\u002Fview\u002Fwidget\"\n- \"add a new command or workflow\"\n- \"new contribution in workbench\u002Feditor\u002Fextensions\"\n- \"update existing UI interactions\"\n\nDo not skip this skill just because accessibility is not named in the prompt.\n\nWhen 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):\n\n1. **An Accessibility Help Dialog** — opened via the accessibility help keybinding when the feature has focus.\n2. **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).\n3. **An Accessibility Verbosity Setting** — a boolean setting that controls whether the \"open accessibility help\" hint is announced.\n\nExamples 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**.\n\nSections 4–7 below (signals, ARIA announcements, keyboard navigation, ARIA labels) apply more broadly to **any UI change**, including modifications to existing features.\n\nWhen **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.\n\n---\n\n## 1. Accessibility Help Dialog\n\nAn accessibility help dialog tells the user what the feature does, which keyboard shortcuts are available, and how to interact with it via a screen reader.\n\n### Steps\n\n1. **Create a class implementing `IAccessibleViewImplementation`** with `type = AccessibleViewType.Help`.\n   - Set a `priority` (higher = shown first when multiple providers match).\n   - Set `when` to a `ContextKeyExpression` that matches when the feature is focused.\n   - `getProvider(accessor)` returns an `AccessibleContentProvider`.\n\n2. **Create a content-provider class** implementing `IAccessibleViewContentProvider`.\n   - `id` — add a new entry in the `AccessibleViewProviderId` enum in `src\u002Fvs\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleView.ts`.\n   - `verbositySettingKey` — reference the new `AccessibilityVerbositySettingId` entry (see §3).\n   - `options` — `{ type: AccessibleViewType.Help }`.\n   - `provideContent()` — return localized, multi-line help text.\n\n3. **Implement `onClose()`** to restore focus to whatever element was focused before the help dialog opened. This ensures keyboard users and screen reader users return to their previous context.\n\n4. **Register** the implementation:\n   ```ts\n   AccessibleViewRegistry.register(new MyFeatureAccessibilityHelp());\n   ```\n   in the feature's `*.contribution.ts` file.\n\n### Example skeleton\n\nThe simplest approach is to return an `AccessibleContentProvider` directly from `getProvider()`. This is the most common pattern in the codebase (used by chat, inline chat, quick chat, etc.):\n\n```ts\nimport { AccessibleViewType, AccessibleContentProvider, AccessibleViewProviderId } from '..\u002F..\u002F..\u002F..\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleView.js';\nimport { IAccessibleViewImplementation } from '..\u002F..\u002F..\u002F..\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleViewRegistry.js';\nimport { AccessibilityVerbositySettingId } from '..\u002F..\u002F..\u002F..\u002Fplatform\u002Faccessibility\u002Fcommon\u002FaccessibilityConfiguration.js';\n\nexport class MyFeatureAccessibilityHelp implements IAccessibleViewImplementation {\n\treadonly priority = 100;\n\treadonly name = 'my-feature';\n\treadonly type = AccessibleViewType.Help;\n\treadonly when = MyFeatureContextKeys.isFocused;\n\n\tgetProvider(accessor: ServicesAccessor) {\n\t\tconst helpText = [\n\t\t\tlocalize('myFeature.help.overview', \"You are in My Feature. …\"),\n\t\t\tlocalize('myFeature.help.key1', \"- {0}: Do something\", '\u003Ckeybinding:myFeature.doSomething>'),\n\t\t].join('\\n');\n\t\treturn new AccessibleContentProvider(\n\t\t\tAccessibleViewProviderId.MyFeature,\n\t\t\t{ type: AccessibleViewType.Help },\n\t\t\t() => helpText,\n\t\t\t() => { \u002F* onClose — refocus whatever was focused before *\u002F },\n\t\t\tAccessibilityVerbositySettingId.MyFeature,\n\t\t);\n\t}\n}\n```\n\nAlternatively, if the provider needs injected services or must track state (e.g., storing a reference to the previously focused element), create a custom class that extends `Disposable` and implements `IAccessibleViewContentProvider`, then instantiate it via `IInstantiationService` (see `CommentsAccessibilityHelpProvider` for an example):\n\n```ts\nclass MyFeatureAccessibilityHelpProvider extends Disposable implements IAccessibleViewContentProvider {\n\treadonly id = AccessibleViewProviderId.MyFeature;\n\treadonly verbositySettingKey = AccessibilityVerbositySettingId.MyFeature;\n\treadonly options: IAccessibleViewOptions = { type: AccessibleViewType.Help };\n\n\tprovideContent(): string { \u002F* … *\u002F }\n\tonClose(): void { \u002F* … *\u002F }\n}\n\n\u002F\u002F In getProvider():\ngetProvider(accessor: ServicesAccessor) {\n\treturn accessor.get(IInstantiationService).createInstance(MyFeatureAccessibilityHelpProvider);\n}\n```\n\n---\n\n## 2. Accessible View\n\nAn accessible view presents the feature's visual content as plain text in a read-only editor. It is required when the feature renders rich or visual content that a screen reader cannot directly read (for example: chat responses, hover tooltips, notifications, terminal output, inline completions).\n\nIf the feature is purely keyboard-driven with native text input\u002Foutput (e.g., a simple input field), an accessible view is not needed — only an accessibility help dialog is required.\n\n### Steps\n\n1. **Create a class implementing `IAccessibleViewImplementation`** with `type = AccessibleViewType.View`.\n2. **Create a content-provider** similar to the help dialog, but:\n   - `options` — `{ type: AccessibleViewType.View }`, optionally with a `language` for syntax highlighting.\n   - `provideContent()` — return the feature's current content as plain text.\n   - Optionally implement `provideNextContent()` \u002F `providePreviousContent()` for item-by-item navigation.\n   - Implement `onClose()` to restore focus to whatever was focused before the accessible view was opened.\n   - Optionally provide `actions` for actions the user can take from the accessible view.\n3. **Register** alongside the help dialog:\n   ```ts\n   AccessibleViewRegistry.register(new MyFeatureAccessibleView());\n   ```\n\n### Example skeleton\n\n```ts\nexport class MyFeatureAccessibleView implements IAccessibleViewImplementation {\n\treadonly priority = 100;\n\treadonly name = 'my-feature';\n\treadonly type = AccessibleViewType.View;\n\treadonly when = MyFeatureContextKeys.isFocused;\n\n\tgetProvider(accessor: ServicesAccessor) {\n\t\t\u002F\u002F Retrieve services, build content from the feature's current state\n\t\tconst content = getMyFeatureContent();\n\t\tif (!content) {\n\t\t\treturn undefined;\n\t\t}\n\t\treturn new AccessibleContentProvider(\n\t\t\tAccessibleViewProviderId.MyFeature,\n\t\t\t{ type: AccessibleViewType.View },\n\t\t\t() => content,\n\t\t\t() => { \u002F* onClose — refocus whatever was focused before the accessible view opened *\u002F },\n\t\t\tAccessibilityVerbositySettingId.MyFeature,\n\t\t);\n\t}\n}\n```\n\n---\n\n## 3. Accessibility Verbosity Setting\n\nA verbosity setting controls whether a hint such as \"press Alt+F1 for accessibility help\" is announced when the feature gains focus. Users who already know the shortcut can disable it.\n\n### Steps\n\n1. **Add an entry** to `AccessibilityVerbositySettingId` in `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Faccessibility\u002Fbrowser\u002FaccessibilityConfiguration.ts`:\n   ```ts\n   export const enum AccessibilityVerbositySettingId {\n       \u002F\u002F … existing entries …\n       MyFeature = 'accessibility.verbosity.myFeature'\n   }\n   ```\n\n2. **Register the configuration property** in the same file's `configuration.properties` object:\n   ```ts\n   [AccessibilityVerbositySettingId.MyFeature]: {\n       description: localize('verbosity.myFeature.description',\n           'Provide information about how to access the My Feature accessibility help menu when My Feature is focused.'),\n       ...baseVerbosityProperty\n   },\n   ```\n   The `baseVerbosityProperty` gives it `type: 'boolean'`, `default: true`, and `tags: ['accessibility']`.\n\n3. **Reference the setting key** in both the help-dialog provider (`verbositySettingKey`) and the accessible-view provider so the runtime can check whether to show the hint.\n\n---\n\n## 4. Accessibility Signals (Sounds & Announcements)\n\nAccessibility signals provide audible and spoken feedback for events that happen visually. Use `IAccessibilitySignalService` to play signals when something important occurs (e.g., an error appears, a task completes, content changes).\n\n### When to use\n\n- **Use an existing signal** when the event already has one defined (see `AccessibilitySignal.*` static members — e.g., `AccessibilitySignal.error`, `AccessibilitySignal.terminalQuickFix`, `AccessibilitySignal.clear`).\n- **If no existing signal fits**, reach out to @meganrogge to discuss adding a new one. Do not register new signals without coordinating first.\n\n### How signals work\n\nEach signal has two modalities controlled by user settings:\n- **Sound** — a short audio cue, configurable to `auto` (on when screen reader attached), `on`, or `off`.\n- **Announcement** — a spoken message via `aria-live`, configurable to `auto` or `off`.\n\n### Usage\n\n```ts\n\u002F\u002F Inject the service via constructor parameter\nconstructor(\n\t@IAccessibilitySignalService private readonly _accessibilitySignalService: IAccessibilitySignalService\n) { }\n\n\u002F\u002F Play a signal\nthis._accessibilitySignalService.playSignal(AccessibilitySignal.terminalQuickFix);\n\n\u002F\u002F Play with options\nthis._accessibilitySignalService.playSignal(AccessibilitySignal.error, { userGesture: true });\n```\n\n---\n\n## 5. ARIA Alerts vs. Status Messages\n\nUse the `alert()` and `status()` functions from `src\u002Fvs\u002Fbase\u002Fbrowser\u002Fui\u002Faria\u002Faria.ts` to announce dynamic changes to screen readers.\n\n### `alert(msg)` — Assertive live region (`role=\"alert\"`)\n- **Use for**: Urgent, important information that the user must know immediately.\n- **Examples**: Errors, warnings, critical state changes, results of a user-initiated action.\n- **Behavior**: Interrupts the screen reader's current speech.\n\n### `status(msg)` — Polite live region (`aria-live=\"polite\"`)\n- **Use for**: Non-urgent, informational updates that should be spoken when the screen reader is idle.\n- **Examples**: Progress updates, search result counts, background state changes.\n- **Behavior**: Queued and spoken after the screen reader finishes its current output.\n\n### Guidelines\n\n- **Prefer `status()` over `alert()`** unless the information is time-sensitive or the result of a direct user action. Overusing `alert()` creates a noisy, disruptive experience.\n- **Keep messages concise.** Screen readers read the entire message; long messages delay the user.\n- **Do not duplicate** — if an accessibility signal already announces the event, do not also call `alert()` \u002F `status()` for the same information.\n- **Localize** all messages with `nls.localize()`.\n\n---\n\n## 6. Keyboard Navigation\n\nEvery interactive UI element must be fully operable via the keyboard.\n\n### Requirements\n\n- **Tab order**: All interactive elements must be reachable via `Tab` \u002F `Shift+Tab` in a logical order.\n- **Arrow key navigation**: Lists, trees, grids, and toolbars must support arrow key navigation following WAI-ARIA patterns.\n- **Focus visibility**: Focused elements must have a visible focus indicator (VS Code's theme system provides this via `focusBorder`).\n- **No mouse-only interactions**: Every action reachable by click or hover must also be reachable via keyboard (context menus, buttons, toggles, etc.).\n- **Escape to dismiss**: Overlays, dialogs, and popups must be dismissable with `Escape`, returning focus to the previous element.\n- **Focus trapping**: Modal dialogs must trap focus within the dialog until dismissed.\n\n### Explaining unavailable options\n\nFollow the [discoverable unavailable-feature pattern](..\u002Fdesign-philosophy\u002FSKILL.md#make-unavailable-features-understandable): a feature promoted in documentation should not become inexplicably absent solely because the user cannot enable it. Announce both the disabled state and its reason using the control's supported ARIA semantics; a grey label, briefcase icon, or hover alone is insufficient. Keep icons decorative when text already conveys their meaning.\n\nExplanatory links must remain independently mouse- and keyboard-operable without activating the disabled option. Verify actual Tab\u002FShift+Tab and Enter behavior, not just `tabIndex` or a programmatic `focus()`; list navigation may skip disabled rows. Preserve focus\u002Fselection on policy refresh, guard stale actions, and update the feature's accessibility help with the available explanation and next step. Reuse the settings, model, harness, and permission-picker examples linked in the design guidance.\n\n---\n\n## 7. ARIA Labels and Roles\n\nAll interactive UI elements must have appropriate ARIA attributes so screen readers can identify and describe them.\n\n### Requirements\n\n- **`aria-label`**: Every interactive element without visible text (icon buttons, icon-only actions, custom widgets) must have a descriptive `aria-label`. Labels should be localized.\n- **`aria-labelledby`** \u002F **`aria-describedby`**: Use these to associate elements with existing visible text rather than duplicating strings.\n- **`role`**: Custom widgets that do not use native HTML elements must declare the correct ARIA role (e.g., `role=\"button\"`, `role=\"tree\"`, `role=\"tablist\"`).\n- **`aria-expanded`**, **`aria-selected`**, **`aria-checked`**: Toggle and selection states must be communicated via the appropriate ARIA state attributes.\n- **`aria-hidden=\"true\"`**: Decorative or redundant elements (icons next to text labels, decorative separators) must be hidden from the accessibility tree.\n\n### Guidelines\n\n- Avoid generic labels like \"button\" or \"icon\" — describe the action: \"Close panel\", \"Toggle sidebar\", \"Run task\".\n- Test with a screen reader (VoiceOver on macOS, NVDA on Windows) to verify labels are spoken correctly in context.\n- Lists and trees should use `aria-setsize` and `aria-posinset` when virtualized so screen readers report the correct count.\n\n---\n\n## Checklist for Every New Feature\n\n- [ ] New `AccessibleViewProviderId` entry added in `accessibleView.ts`\n- [ ] New `AccessibilityVerbositySettingId` entry added in `accessibilityConfiguration.ts`\n- [ ] Verbosity setting registered in the configuration properties with `...baseVerbosityProperty`\n- [ ] `IAccessibleViewImplementation` with `type = Help` created and registered\n- [ ] Content provider references the correct `verbositySettingKey`\n- [ ] Help text is fully localized using `nls.localize()`\n- [ ] Keybindings in help text use `\u003Ckeybinding:commandId>` syntax for dynamic resolution\n- [ ] `when` context key is set so the dialog only appears when the feature is focused\n- [ ] If the feature has rich\u002Fvisual content: `IAccessibleViewImplementation` with `type = View` created and registered\n- [ ] Registration calls in the feature's `*.contribution.ts` file\n- [ ] Accessibility signal played for important events (use existing `AccessibilitySignal.*` or register a new one)\n- [ ] `aria.alert()` or `aria.status()` used appropriately for dynamic changes (prefer `status()` unless urgent)\n- [ ] All interactive elements reachable and operable via keyboard\n- [ ] All interactive elements without visible text have a localized `aria-label`\n- [ ] Custom widgets declare the correct ARIA `role` and state attributes\n- [ ] Decorative elements are hidden with `aria-hidden=\"true\"`\n\n## Key Files\n\n- `src\u002Fvs\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleView.ts` — `AccessibleViewProviderId`, `AccessibleContentProvider`, `IAccessibleViewContentProvider`\n- `src\u002Fvs\u002Fplatform\u002Faccessibility\u002Fbrowser\u002FaccessibleViewRegistry.ts` — `AccessibleViewRegistry`, `IAccessibleViewImplementation`\n- `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Faccessibility\u002Fbrowser\u002FaccessibilityConfiguration.ts` — `AccessibilityVerbositySettingId`, verbosity setting registration\n- `src\u002Fvs\u002Fplatform\u002FaccessibilitySignal\u002Fbrowser\u002FaccessibilitySignalService.ts` — `IAccessibilitySignalService`, `AccessibilitySignal`\n- `src\u002Fvs\u002Fbase\u002Fbrowser\u002Fui\u002Faria\u002Faria.ts` — `alert()`, `status()` for ARIA live region announcements\n",{"name":5,"description":7},"main","11ba54a90a0ff8720cf47c086f5a9948eef9cf2c",".github\u002Fskills\u002Faccessibility",43791,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode","https:\u002F\u002Fcode.visualstudio.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 03:13:10",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add microsoft\u002Fvscode --skill accessibility",{"tool":57,"command":58},"bunx","bunx skills add microsoft\u002Fvscode --skill accessibility",{"tool":60,"command":61},"pnpm","pnpm dlx skills add microsoft\u002Fvscode --skill accessibility","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Faccessibility\u002FSKILL.md",true,[65,71,75,79,83,87,91,95],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"domain-steps\u002Fstep-01-init.md","REFERENCE","参考文档",5394,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-domain-research\u002Fdomain-steps\u002Fstep-01-init.md",{"path":72,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":73,"sourceHtmlUrl":74},"domain-steps\u002Fstep-02-domain-analysis.md",8640,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-domain-research\u002Fdomain-steps\u002Fstep-02-domain-analysis.md",{"path":76,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":77,"sourceHtmlUrl":78},"domain-steps\u002Fstep-03-competitive-landscape.md",9525,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-domain-research\u002Fdomain-steps\u002Fstep-03-competitive-landscape.md",{"path":80,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":81,"sourceHtmlUrl":82},"domain-steps\u002Fstep-04-regulatory-focus.md",6967,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-domain-research\u002Fdomain-steps\u002Fstep-04-regulatory-focus.md",{"path":84,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":85,"sourceHtmlUrl":86},"domain-steps\u002Fstep-05-technical-trends.md",7506,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-domain-research\u002Fdomain-steps\u002Fstep-05-technical-trends.md",{"path":88,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":89,"sourceHtmlUrl":90},"domain-steps\u002Fstep-06-research-synthesis.md",16973,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-domain-research\u002Fdomain-steps\u002Fstep-06-research-synthesis.md",{"path":92,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":93,"sourceHtmlUrl":94},"research.template.md",581,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-domain-research\u002Fresearch.template.md",{"path":96,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":97,"sourceHtmlUrl":98},"workflow.md",2280,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fbmad-domain-research\u002Fworkflow.md",[100,126,148,161,176,191],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":36},"01M70H0ANBKZAVEP1NVV4K28M3","sweeper-query","Answer natural-language questions about the VS Code Sweeper's published issue index (index-\u003Cname>.json for microsoft\u002Fvscode and the enrolled family repos) — which issues are agent-ready to implement or plan, what the sweeper proposed for an assignee or area, whether the sweeper knows a report as a duplicate, the highest-value open bugs in a lane — and, for one issue, the review's full record (evidence with file citations, fix brief, proposed comment). Use ONLY when the request explicitly names the sweeper — \"sweeper\", \"vscodesweeper\", \"sweeper-query\", a sweeper verdict, record, brief or index, an agent-ready issue — or asks what \"the sweeper\" found, proposed or knows. Do NOT use for general questions about issues, duplicates, priorities or ranking that do not mention the sweeper. Read-only; discovery only.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsweeper-query\u002FSKILL.md",[],[107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,35],"sweeper query","query","sweeper","review","fix","when","request","which","natural-language","ranking","duplicates","ready","only","read","plan","open","Citations","brief","issues",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":36},"01M699DRJS4YJCV600Q72SVVWE","update-skills","Create or update repository skills and instructions when major learnings are discovered during a session. Use when the user says \"learn!\", when a significant pattern or pitfall is identified, or when reusable domain knowledge should be captured for future sessions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-skills\u002FSKILL.md",[],[133,134,22,135,136,137,138,139,140,141,142,143,144,145,146,147,112],"update","update skills","pattern","domain","learnings","reusable","use","session","user","instructions","knowledge","repository","learn","create","sessions",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":36},"01M699DPWHZ72B66P82EW31RNE","update-pr","Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-pr\u002FSKILL.md",[],[133,155,156,112,113,21,22,139,140,141,157,158,159,160],"pr","update pr","push","pull","pull request","changes",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":36},"01M699DJMR6CE1MH5XCJZ0GFQ0","sync","Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync\u002FSKILL.md",[],[163,168,169,157,158,170,112,160,171,172,173,174,139,140,141,175],"SET","publish","rebase","latest","with","remote","upstream","branch",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":36},"01M699DGXHX6A2A72X57R6GGHJ","sync-upstream","Update a stale session branch by rebasing onto the latest origin. Use when the upstream has moved significantly and the session needs to catch up, resolving conflicts by preserving upstream changes and adapting session work to fit.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync-upstream\u002FSKILL.md",[],[174,163,183,184,112,185,186,160,171,187,188,189,190,139,140,175,32,133],"sync upstream","fit","catch","catch up","origin","conflicts","stale","up",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":36},"01M699DEXYFWDGW0BAXJ5QQ377","merge","Merge changes from the topic branch to the merge base branch. Use when the user wants to merge their session's work back to the base branch.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fmerge\u002FSKILL.md",[],[193,140,139,32,175,141,112,198,199,160],"back","base"]