Accessibu11y for VS Code
Quick and easy accessibility checks while you edit. It covers alt text, roles, labels, colour contrast and accessible naming conventions. Accessibu11y adapts checks from the Accessibu11y Chrome extension for your editor. It shows warnings in VS Code’s Problems panel and updates them as you type.
What it checks
Each warning shows the WCAG success criterion it relates to, for example WCAG 1.1.1. Click the code in the Problems panel to open that criterion on the WCAG 2.2 Quick Reference, which lists every criterion and what it means.
| WCAG criterion |
What Accessibu11y flags |
| 1.1.1 Non-text Content |
<img> elements with no alt attribute. Empty alt="" is allowed, because that is the correct way to mark a decorative image. |
| 1.3.1 Info and Relationships |
A missing <main> landmark in an HTML page (a file with <html> or <body>). role="main" also counts. JSX and TSX files are usually components, so they are skipped unless you turn on the accessibu11y.checkMainInComponents setting. |
| 1.4.3 Contrast (Minimum) |
A 3- or 6-digit hex text color and background color in the same inline style (HTML style="..." or JSX style={{ ... }}) or CSS/SCSS block, when the contrast ratio is below 4.5:1. |
| 4.1.2 Name, Role, Value |
<input> elements with no aria-label, aria-labelledby, title, or id. Hidden, submit, button, reset, and image inputs are skipped, and so are tags that use spread props like {...props}, since their attributes can’t be seen in source. |
It works in HTML, JSX, TSX, CSS, and SCSS files. Commented-out markup (<!-- ... --> and {/* ... */}) is ignored.
What it doesn’t check
This is a quick check while you write code, not a full audit.
- 1.1.1: it doesn’t judge whether alt text is any good, and it doesn’t look at SVGs or other non-text content.
- 1.3.1: it only looks for a
<main> landmark. It doesn’t check headings, lists, tables, other landmarks, or form structure.
- 1.4.3: it only reads opaque hex colors written together in source. It does not resolve CSS variables, named colors,
rgb() values, alpha transparency, the cascade, inherited backgrounds, or framework-generated markup. It flags anything below 4.5:1, but large text only needs 3:1, so large text can be flagged when it doesn’t need to be.
- 4.1.2: it only checks
<input> elements. It doesn’t check buttons, links, selects, textareas, custom ARIA roles, or invalid ARIA. An id doesn’t prove an input is connected to a real <label>.
The browser extension analyzes rendered pages and computed colors. A source editor can’t see computed styles. Treat findings as quick prompts to review, not a complete accessibility audit or a WCAG conformance result.
Use it
- Install Accessibu11y from the Extensions panel.
- Open an HTML, JSX, TSX, CSS, or SCSS file. Warnings appear in the Problems panel (
Cmd+Shift+M on Mac, Ctrl+Shift+M on Windows) as you edit.
- To scan matching files throughout the open workspace, run Accessibu11y: Scan Workspace from the Command Palette.
Settings
accessibu11y.checkMainInComponents (default false): also check JSX and TSX files for a <main> landmark.
Development
- Open this folder in VS Code.
- Press F5 to launch an Extension Development Host window.
- Open a supported file in that window to see warnings.
To package the extension for installation, run npx @vscode/vsce package in this folder to create a VSIX file.
src/extension.js implements the diagnostics and workspace command.package.json declares VS Code compatibility, the command, and the setting..vscode/launch.json lets F5 start the Extension Development Host..vscodeignore keeps development files out of the packaged extension.
| |
