detecting-accessibility-issues
Skill33 starsChanged 5 days agoMITView on GitHub
Detects and fixes accessibility issues in React/Fluent UI webviews. Use when reviewing code for screen reader compatibility, fixing ARIA labels, ensuring keyboard navigation, adding live regions for status messages, or managing focus in dialogs.
In this repository17 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- backportSkill
- documentation-screenshotsSkill
- error-translationSkill
- flagging-fresh-dependenciesSkill
- fluentuiSkill
- leadSkill
- prepare-pull-requestSkill
- previewing-docs-siteSkill
- react-webview-architectureSkill
- review-external-prSkill
- skill-creatorSkill
- telemetry-instrumentationSkill
- tree-cluster-architectureSkill
- ux-pr-reviewSkill
- webview-trpc-messagingSkill
- writing-release-notesSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 3 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Verify and fix accessibility in React/Fluent UI webview components.
- Very specific: line 14
Add missing aria-label to icon-only buttons or form inputs
- Distinctive: line 195
Use for: loading states, search results, success/error messages.
- Very specific: line 266
Import FocusableBadge from @microsoft/vscode-ext-webview-fluentui/components.
- Very specific: line 267
Keep Tooltip at the call site with relationship="description".
- Very specific: line 268
Use focusable={false} only for plain badges in a mixed list.
- Distinctive: line 281
When you name a focusable container yourself rather than using these components, give it a role.
- Very specific: line 288
Use the Announcer component for WCAG 4.1.3 (Status Messages) compliance.
- Very specific: line 321
Condition resets automatically: - when when goes back to false, it's ready for the next announcement
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Accessibility Expert for Webviews
Verify and fix accessibility in React/Fluent UI webview components.
When to Use
- Review webview code for accessibility issues
- Fix double announcements from screen readers
- Add missing
aria-labelto icon-only buttons or form inputs - Make tooltips accessible to keyboard/screen reader users
- Announce status changes (loading, search results, errors)
- Manage focus when dialogs/modals open
- Group related controls with proper labels
Core Pattern: Tooltip Accessibility
For a badge whose tooltip must be reachable by keyboard, use the package component and keep the tooltip as a description:
<Tooltip content="Detailed explanation" relationship="description">
<FocusableBadge>Badge text</FocusableBadge>
</Tooltip>- The visible content is the name through
aria-labelledby. - Tooltip content is the supplementary description through
aria-describedby. - The badge carries
role="group", because ARIA cannot name a role-less element. - Browser-computed results do not prove what a real screen reader says.
Detection Rules
1. Tooltip Content Never Reaches the Accessibility Tree
❌ Problem: the tooltip declares no ARIA relationship, so its content is invisible to assistive
technology — and the aria-label here only restates the visible text
<Tooltip content="Save document to database">
<Button aria-label="Save">Save</Button>
</Tooltip>✅ Fix: declare the relationship and let the tooltip be the description
<Tooltip content="Save document to database" relationship="description">
<Button>Save</Button>
</Tooltip>relationship="description" wires aria-describedby to the tooltip. Do not also copy the
tooltip text into aria-label: that announces it twice (rule 2). Use relationship="label" only
when the trigger has no visible text of its own.
2. Composed Badge Name Repeats Its Description
❌ Problem: Tooltip details occur in both the name and description
<Tooltip content="Query is inefficient" relationship="description">
<Badge tabIndex={0} aria-label="Collection scan. Query is inefficient">
<span aria-hidden="true">Collection scan</span>
</Badge>
</Tooltip>✅ Fix: Let visible content name FocusableBadge; keep details in the description
<Tooltip content="Query is inefficient" relationship="description">
<FocusableBadge>Collection scan</FocusableBadge>
</Tooltip>3. Redundant aria-label (NOT Needed)
❌ Problem: aria-label identical to visible text adds no value
<Button aria-label="Save">Save</Button>
<ToolbarButton aria-label="Validate" icon={<CheckIcon />}>Validate</ToolbarButton>✅ Fix: Remove redundant aria-label OR make it more descriptive
<Button>Save</Button>
<ToolbarButton icon={<CheckIcon />}>Validate</ToolbarButton>Keep aria-label only when it adds information:
<ToolbarButton aria-label="Save document to database" icon={<SaveIcon />}>
Save
</ToolbarButton>4. Icon-Only Button Missing aria-label
❌ Problem: No accessible name
<ToolbarButton icon={<DeleteRegular />} onClick={onDelete} />✅ Fix: Add aria-label
<Tooltip content="Delete selected items" relationship="description">
<ToolbarButton aria-label="Delete selected items" icon={<DeleteRegular />} onClick={onDelete} />
</Tooltip>5. Decorative Elements Not Hidden
❌ Problem: Progress bar announced unnecessarily
<ProgressBar thickness="large" />✅ Fix: Hide decorative elements
<ProgressBar thickness="large" aria-hidden={true} />6. Input Missing Accessible Name
❌ Problem: SpinButton/Input without accessible name
<SpinButton value={skipValue} onChange={onSkipChange} />
<Input placeholder="Enter query..." />✅ Fix: Add aria-label or associate with label element
<SpinButton aria-label="Skip documents" value={skipValue} onChange={onSkipChange} />
<Label htmlFor="query-input">Query</Label>
<Input id="query-input" placeholder="Enter query..." />7. Visible Label Not in Accessible Name
❌ Problem: aria-label doesn't contain visible text (breaks voice control)
<ToolbarButton aria-label="Reload data" icon={<RefreshIcon />}>
Refresh
</ToolbarButton>✅ Fix: Accessible name must contain visible label exactly
<ToolbarButton aria-label="Refresh data" icon={<RefreshIcon />}>
Refresh
</ToolbarButton>Voice control users say "click Refresh" – only works if accessible name contains "Refresh".
8. Status Changes Not Announced
❌ Problem: Screen reader doesn't announce dynamic content
<span>{isLoading ? 'Loading...' : `${count} results`}</span>✅ Fix: Use the Announcer component
import { Announcer } from '<relative-path>/components/accessibility';
// Announces when `when` transitions from false to true
<Announcer when={isLoading} message={l10n.t('Loading...')} />
// Dynamic message based on state
<Announcer
when={!isLoading && documentCount !== undefined}
message={documentCount > 0 ? l10n.t('Results found') : l10n.t('No results found')}
/>Use for: loading states, search results, success/error messages.
9. Dialog Opens Without Focus Move
❌ Problem: Focus stays on trigger when modal opens
{
isOpen && <Dialog>...</Dialog>;
}✅ Fix: Move focus programmatically
const dialogRef = useRef<HTMLDivElement>(null);
useEffect(() => {
if (isOpen) dialogRef.current?.focus();
}, [isOpen]);
{
isOpen && (
<Dialog ref={dialogRef} tabIndex={-1} aria-modal="true">
...
</Dialog>
);
}10. Related Controls Without Group Label
❌ Problem: Buttons share visual label but screen reader misses context
<span>How would you rate this?</span>
<Button>👍</Button>
<Button>👎</Button>✅ Fix: Use role="group" with aria-labelledby
<div role="group" aria-labelledby="rating-label">
<span id="rating-label">How would you rate this?</span>
<Button aria-label="I like it">👍</Button>
<Button aria-label="I don't like it">👎</Button>
</div>When to Use aria-hidden
DO use on:
- Decorative icons, spinners, progress bars
- Visual separators (`|`, `—`)
Last resort only: visible text that a composed aria-label already covers. Prefer naming the
element from its visible content with aria-labelledby, which needs no hiding at all — that is
what FocusableBadge and MetricCard do.
DO NOT use on:
- The only accessible content (hides it completely)
- Interactive/focusable elements
- Error messages or alerts
FocusableBadge Pattern
For keyboard-accessible badges with tooltips:
- Import
FocusableBadgefrom@microsoft/vscode-ext-webview-fluentui/components. - Keep
Tooltipat the call site withrelationship="description". - Use
focusable={false}only for plain badges in a mixed list; never infer focusability from an accessible-name override.
<Tooltip content="Tooltip details" relationship="description">
<FocusableBadge>Visible text</FocusableBadge>
</Tooltip>For rich tooltip content that visually repeats the badge name, set the content slot's aria-label
to only the supplementary details. For truncated values, keep the visible label and truncated value
as the badge name and the full value as the description; do not use relationship="label".
When you name a focusable container yourself rather than using these components, give it a role.
ARIA forbids naming the generic role, so aria-labelledby on a bare div (or on Fluent's Badge
or Card, neither of which sets a role) is a name a conforming screen reader may discard.
role="group" is usually the least-weight role that makes the name legitimate.
Screen Reader Announcements
Use the Announcer component for WCAG 4.1.3 (Status Messages) compliance.
import { Announcer } from '<relative-path>/components/accessibility';Basic Usage
// Announces "AI is analyzing..." when isLoading becomes true
<Announcer when={isLoading} message={l10n.t('AI is analyzing...')} />
// Dynamic message based on state (e.g., query results)
<Announcer
when={!isLoading && documentCount !== undefined}
message={documentCount > 0 ? l10n.t('Results found') : l10n.t('No results found')}
/>
// With assertive politeness (default is polite)
<Announcer when={hasError} message={l10n.t('Error occurred')} politeness="assertive" />Props
when: Announces when this transitions fromfalsetotruemessage: The message to announce (usel10n.t()for localization)politeness:'assertive'(default, interrupts) or'polite'(waits for idle)
Key Points
- Placement doesn't matter - screen readers monitor all live regions regardless of DOM position; place near related UI for code readability
- Store relevant state (e.g.,
documentCount) to derive dynamic messages - Use
l10n.t()for messages - announcements must be localized - Condition resets automatically - when
whengoes back tofalse, it's ready for the next announcement - Prefer 'assertive' for user-initiated actions, 'polite' for background updates
Quick Checklist
- Icon-only buttons have
aria-label - Form inputs have associated labels or
aria-label - Tooltips declare a
relationship; their text is not also copied intoaria-label - Visible text is not hidden with
aria-hiddento make room for a composedaria-label - Redundant aria-labels removed (identical to visible text)
- Visible button labels are contained in the accessible name (for voice control)
- Decorative elements have
aria-hidden={true} - Badges with keyboard-reachable tooltips use
FocusableBadge+relationship="description" - Focusable elements carrying
aria-labelledbyhave a role (ARIA cannot namegeneric) - Status updates use
Announcercomponent - Focus moves to dialog/modal content when opened
- Related controls wrapped in
role="group"witharia-labelledby
References
- WCAG 2.1.1 Keyboard
- WCAG 2.4.3 Focus Order
- WCAG 2.5.3 Label in Name
- WCAG 4.1.2 Name, Role, Value
- WCAG 4.1.3 Status Messages
- See
packages/vscode-ext-webview-fluentui/src/components/FocusableBadge/README.mdfor the badge pattern
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

