Check a page for accessibility

Open a page and choose A11y in the rail on the right. The number on the rail is how many issues block people.

Two checks in one list

The panel checks the page twice and shows the results as one list.

• The content is checked as you type: images without alt text in this page's language, link text such as "Read more" that says nothing on its own, links with no text, tables without header cells, long text in capitals, text and background colour fields with too little contrast, and headings that skip a level.
• The rendered page in the preview is checked with axe-core, about two seconds after each change and each time the preview loads. It finds what the website's design adds, such as text over a photo that is hard to read, buttons without a name, or form fields without a label.

When both checks find the same problem, such as a link with no text, it is listed once, marked Content and page. The line under the heading says when the rendered page was last checked; Check again runs it now.

If the panel says Update the SDK to check the rendered page, the website's preview can't run the check yet. Only the content is checked until a developer updates the website's SDK; see Set up the live preview.

Reading the list

Issues are grouped by how much they matter, then by the WCAG success criterion they come under, such as 1.1.1 Non-text content (A):

• Blocks people: Someone can't use this part of the page. Fix these first.
• Needs review: A check found something that is probably wrong, or that a machine can't decide, such as text over an image. Look at it and fix it, or leave it as it is with a reason.

Each issue says which block it is in. Why it matters explains the problem in plain words, shows the element on the page and links to the rule. Issues outside the page's blocks are in the website's template, such as its header or footer; a developer fixes those.

At the bottom, the panel says how many rules passed on the rendered page and which guidelines were checked, such as WCAG 2.2 AA and best practice. An administrator chooses the guidelines in Accessibility › Settings.

Find the problem on the page

Point at an issue and the preview scrolls to it and outlines it in red. Click it to select its block and jump to the field to change.

Fix it from the panel

Some issues have a fix right under them. Each one changes the draft, so the preview updates at once and ⌘Z undoes it.

• Alt text: Write what the image shows, in this page's language. With AI writing switched on for image descriptions, Suggest alt text from the image looks at the image itself and at the page around it, and writes a suggestion for you to read and change before you save. Alt text is saved on the image in the media library, so it is used on every page that shows it; Undo in the message puts the old text back.
• Link text: Choose a suggestion, such as the name of the page the link goes to, or write your own. With AI writing switched on, it can suggest a rewrite.
• Contrast: Choose a text colour that passes 4.5 to 1 against the background. The website's own colours for that field come first, then the nearest shade of the current colour.
• Heading order: Where the block lets you choose its heading level, Make it H3 sets the level that follows the heading before it.

Nothing is changed without you choosing it.

Leave an issue as it is

Some findings are fine as they are, such as a photo that is only decoration. Choose … beside the issue, then Leave as it is…, and say why. The issue moves to Left as they are, stops counting against the page and the report, and no longer stops publishing. Fix after all puts it back.

What the checks can't tell

Automatic checks find about half of what matters. Before a big launch, use the page with the keyboard alone, and listen to it with a screen reader such as VoiceOver or NVDA.