WCAG 2.2: how to assess each requirement

Non-text content that conveys something has a text alternative

• Rules decide part of it
• Tools: The browser's developer tools

1. Look through the whole page for content that isn't text: photos, icons, logos, charts, maps, diagrams, video posters, and the pictures inside buttons and links.
2. For each, select it in the developer tools' Elements pane and read the Name in its Accessibility pane.
3. Note each one that has no name and isn't hidden from assistive technology (with alt="", aria-hidden="true", role="presentation" or as a CSS background).
4. Look also for information that only CSS shows: background images, icon fonts and pictures added with the content property. Inspect each, since there is no alt attribute to read, and check that what it shows is also given in text that a screen reader reads.
5. For content that can't be described in a few words, such as a chart or a map, check that the name at least says what it is, and that a fuller description is on the page or linked beside it.

Passes when

Every piece of non-text content a person needs has a text alternative, or is hidden from assistive technology because it is decorative.

Fails when

Non-text content that conveys something has no text alternative, so a screen reader user meets an unnamed image or nothing at all, which fails WCAG 1.1.1.

Rules that test it: img-alt-present, role-img-text-alternative-present, canvas-text-alternative-present, embed-text-alternative-present, svg-text-alternative-present, svg-image-text-alternative-present, object-text-alternative-present, video-poster-text-alternative-present, meter-name-present, progressbar-name-present

Images and icons used as controls are named by what they do

• Rules decide part of it
• Tools: The browser's developer tools

1. Find every link, button and other control whose only content is an image or icon, such as a logo that links home, a magnifier for search or a cross that closes a dialog.
2. For each, select it in the developer tools' Elements pane and read the Name in its Accessibility pane.
3. Check that the name says what the control does or where it leads ("Search", "Close", "Home"), not what the picture shows ("magnifying glass") or a file name.

Passes when

Every control made of an image or icon has a name that says what it does or where it goes.

Fails when

A control made of an image or icon has no name, or one that describes the picture rather than what it does, which fails WCAG 1.1.1.

Rules that test it: input-image-alt-present, area-alt-present

Decorative images are hidden from assistive technology, and only those

• Only a person can check it
• Tools: The browser's developer tools

1. Look through the page for images, icons and graphics that only decorate: borders, dividers, background pictures, ornaments, and pictures whose content the text next to them already gives.
2. For each, select it in the developer tools' Elements pane and check in its Accessibility pane that it is ignored (alt="", aria-hidden="true", role="presentation", or a CSS background).
3. For a decorative SVG drawn in the page, check that it has aria-hidden="true". Without it, some browser and screen reader pairs announce it as an image with no name, or read the text inside it.
4. Then do the reverse: for each image that is hidden that way, ask whether a user would miss anything if it were gone: information, a label, a chart's data.

Passes when

Decorative images are hidden from assistive technology, and every image that is hidden is truly decorative.

Fails when

A decorative image is announced (often by its file name), or an image that conveys information is hidden from assistive technology, which fails WCAG 1.1.1.

Each text alternative gives what its image gives

• Rules decide part of it
• Tools: The browser's developer tools

1. For each image and other non-text content that has a text alternative, read the alternative (the Name in the developer tools' Accessibility pane) and look at the content in its place on the page.
2. Ask what the content gives a reader there, and check that the alternative gives the same: the words in an image of text, the point a photo makes, the facts a chart shows.
3. Where the alternative only names a complex image, such as a chart or diagram, check that the details are in a caption, text or table next to it, or a link beside it, that a screen reader user can find from the image.
4. Note alternatives that are a file name, a web address, a word such as "image" or "photo", or that repeat the text right next to them.
5. Check the language of each alternative: it should be in the language of the page, or marked with its own.

Passes when

Each text alternative gives what its content gives in that place, directly or through a description a screen reader user can reach from it.

Fails when

A text alternative doesn't give what the content does, for example a file name, a generic word or a chart named without its data anywhere, which fails WCAG 1.1.1 (F30).

Rules that test it: area-alt-quality, canvas-text-alternative-quality, embed-text-alternative-quality, img-alt-decorative, img-alt-quality, input-image-alt-decorative, input-image-alt-quality, object-text-alternative-quality, svg-text-alternative-quality

A CAPTCHA says what it is for and offers another form that uses a different sense

• Only a person can check it
• Tools: A screen reader

1. Find any test the page uses to tell people from programs, such as distorted letters to type, pictures to pick or a puzzle to drag.
2. Check that it has a text alternative that says what it is and what to do, without giving the answer away.
3. Check that it offers another form that uses a different sense, such as an audio version of a visual test, or another way altogether, such as a code by email.
4. Try the other form with a screen reader and the keyboard.

Passes when

The page has no such test, or the test says what it is and offers a form that uses another sense and can be completed.

Fails when

The test can only be passed by seeing (or only by hearing), or has no text saying what it is, which fails WCAG 1.1.1.

Prerecorded audio-only and video-only media has a transcript or an equivalent alternative

• Rules decide part of it
• Tools: a browser only

1. Find every audio player and every video without sound on the page, including ones in frames, and play each.
2. For audio, look next to the player and elsewhere on the page for a transcript or a link to one.
3. For a video without sound, look for a transcript, or an audio version that describes everything shown, that you can find and play from the page with the keyboard.
4. Compare each alternative with the media and check that it gives the same information: speech, important sounds and what is shown.
5. Leave out media that is itself an alternative for text on the page and is labelled as such.

Passes when

Every prerecorded audio-only or video-only item has a transcript, or for video an audio version, that gives what it gives, or is a labelled alternative for text on the page.

Fails when

Prerecorded audio-only media has no transcript, or prerecorded video-only media has neither a transcript nor an audio version with the same information, which fails WCAG 1.2.1.

Rules that test it: media-alternative-transcript-evidence

Prerecorded video with sound has captions

• Only a person can check it
• Tools: a browser only

1. Find every prerecorded video with sound on the page, including ones in frames and players of other sites.
2. Play each with the sound on and note whether its sound carries information: speech, or sounds that matter.
3. Where it does, look for captions: the player's CC button, captions burned into the picture, or a captioned version of the same video linked next to it. A transcript on its own doesn't replace captions.
4. Leave out a video that is itself an alternative for text on the page and is labelled as such.

Passes when

Every prerecorded video whose sound carries information has captions, here or in a captioned version linked next to it, or is a labelled alternative for text on the page.

Fails when

A prerecorded video has dialogue or important sounds and no captions, here or in a linked captioned version, even if a transcript is offered, which fails WCAG 1.2.2.

Rules that test it: video-caption

Captions give all the dialogue, who is speaking, and the sounds that matter, in time with the video

• Only a person can check it
• Tools: a browser only

1. Play each captioned video with the sound on and the captions turned on.
2. Compare the captions with what is said and heard, all the way through.
3. Check that they carry all the dialogue, say who is speaking when that isn't clear, and describe the sounds that matter (music, alarms, laughter), and that they stay in time with the picture.
4. Treat automatically generated captions with care: they often get names, numbers and punctuation wrong and don't describe sounds, so they rarely meet this criterion without editing.

Passes when

The captions carry all dialogue, the speakers where needed, and the important sounds, in time with the video.

Fails when

Captions leave out dialogue or important sounds, don't say who is speaking where that matters, or run out of time with the video, which fails WCAG 1.2.2 (F8).

Prerecorded video with sound has an audio description or a full text alternative

• Only a person can check it

No procedure for this yet.

Live video with sound has captions

• Only a person can check it

No procedure for this yet.

Prerecorded video with sound has an audio description

• Only a person can check it

No procedure for this yet.

Text that looks like a heading is marked up as one, at a level that matches the page's outline

• Rules decide part of it
• Tools: The browser's developer tools, A screen reader

1. Look through the page and note every piece of text that works as a heading: it is larger or bolder than the text around it and introduces what follows.
2. For each, check in the developer tools' Elements pane that it is an <h1> to <h6>, or has role="heading" with an aria-level.
3. Check the reverse: each heading element on the page introduces content, rather than being used only to make text big.
4. List the headings with a screen reader's headings list, a browser extension such as HeadingsMap, or the Accessibility pane, and check that their levels match the structure the page shows: a section's sub-headings sit below its heading, not at the same level or above it. A skipped level on its own, such as an h2 followed by an h4, doesn't fail this criterion when the nesting is still right. Record it as a best practice issue.

Passes when

Every visual heading is marked up as a heading, every heading element is one, and the levels follow the outline the page shows.

Fails when

Text that looks like a heading is plain text, a heading element is used only for its size, or the levels contradict the outline, so screen reader users can't find or follow the sections, which fails WCAG 1.3.1.

Rules that test it: p-as-heading

Content shown as a list is marked up as a list

• Rules decide part of it
• Tools: The browser's developer tools

1. Look through the page for content shown as a list: items in a row or column with bullets, numbers or the same layout, such as menus, steps and groups of links.
2. For each, check in the developer tools' Elements pane that it is a <ul>, <ol> or <dl> (or has role="list" with role="listitem" items).
3. Check that each list holds only list items directly, and each list item sits in a list.
4. If you test with VoiceOver and Safari, know that Safari does not expose a list whose bullets are removed with list-style: none unless it has role="list". This is a choice of the browser, not a failure of the page, but note it when the list's structure matters to the user.

Passes when

Content shown as a list is marked up as a list, and list markup is complete.

Fails when

Content shown as a list is a run of paragraphs, line breaks or divs, or list markup is broken, so a screen reader doesn't say it is a list or how many items it has, which fails WCAG 1.3.1.

Rules that test it: list-children-valid, listitem-parent-valid, definition-list-children-valid, dlitem-parent-valid

Data tables mark up their headers and caption, and tables used only for layout carry no header markup

• Rules decide part of it
• Tools: The browser's developer tools, A screen reader

1. Find every table on the page, and every grid of data drawn without a table.
2. For a table of data, check in the developer tools' Elements pane that its header cells are <th> (with scope where a header is not plainly a row or column header) and that a title shown above it is its <caption>.
3. For a complex table, with headers on more than one level, check that each data cell names its headers with a headers attribute or scope.
4. With a screen reader, move through a few data cells and check that it reads their headers with them.
5. For a table used only to lay things out, check that it has no <th>, <caption> or summary.

Passes when

Data is in tables whose headers and caption are marked up, a screen reader reads each cell's headers, and layout tables carry no header markup.

Fails when

A table of data has no header markup or a fake caption in a cell, data is laid out as a grid without a table, or a layout table is marked up as data, which fails WCAG 1.3.1.

Rules that test it: table-headers-attr-valid, table-th-has-data-cells, table-fake-caption, td-has-header

Form fields are tied to their visible labels, and groups of fields to the text that names the group

• Rules decide part of it
• Tools: The browser's developer tools, A screen reader

1. Find every form field on the page: text fields, check boxes, radio buttons, drop-downs and custom controls.
2. For each, select it in the developer tools' Elements pane and check that the Name in its Accessibility pane contains its visible label.
3. For a group of fields under one question, such as radio buttons or a date in three parts, check that the group is a <fieldset> with a <legend>, or has role="group" with a name, so the question is read with each field.
4. Check that instructions shown next to a field (a format, a required mark) are tied to it with aria-describedby or are in its label.

Passes when

Every field's name includes its visible label, groups of fields are named by their question, and a field's instructions are tied to it.

Fails when

A field is labelled only by nearby text that isn't tied to it, or a group's question isn't tied to its fields, so a screen reader reads a field without saying what it is for, which fails WCAG 1.3.1.

Rules that test it: form-control-programmatic-label-present

ARIA roles and relationships give the same structure the page shows

• Rules decide part of it
• Tools: The browser's developer tools

1. Find the parts of the page built with ARIA roles: custom menus, tabs, trees, grids, lists and listboxes.
2. For each, open the developer tools' Accessibility tree and check that the structure it shows matches what is on screen: a tablist holding tabs, a menu holding menu items, a grid holding rows and cells.
3. Check that no element with a role is missing the parent or children its role needs, and that aria-owns, where used, gives each element a single owner.
4. Check that <body> is not hidden with aria-hidden="true".

Passes when

The accessibility tree gives the structure the page shows, with every role in the place its role needs.

Fails when

A role is missing its required parent or children, owned twice, or the page is hidden from the tree, so assistive technology gives a structure that doesn't match the screen, which fails WCAG 1.3.1.

Rules that test it: aria-hidden-body, aria-required-children, aria-prohibited-children, aria-required-parent, aria-roles-valid, aria-owns-valid

Meaning shown by styling or layout, such as bold, colour, position or an asterisk, is also given in the markup or the text

• Only a person can check it
• Tools: The browser's developer tools, A screen reader

1. Look for meaning that the page shows only by how things look: required fields marked by an asterisk or colour, emphasised or struck-through words, a selected item shown by its style, text set apart in a box.
2. For each, check whether the same meaning is in the markup (such as required, aria-current, <em>, <del>) or in the text itself ("required", "current page").
3. Look at text and icons added with CSS, through the content property. Browsers differ in whether screen readers read them, so information that only CSS adds must also be in the markup or the text.
4. Read the parts with a screen reader and check that what the styling shows is said.

Passes when

Whatever the styling or layout conveys is also in the markup or the text.

Fails when

Meaning is given only by styling or position, such as required fields marked only by colour or an unexplained asterisk, so a screen reader user misses it, which fails WCAG 1.3.1.

The order assistive technology reads the content in keeps its meaning, and spaces don't lay out text

• Only a person can check it

No procedure for this yet.

Instructions don't rely only on shape, colour, size, position, orientation or sound

• Only a person can check it

No procedure for this yet.

The page works in both portrait and landscape, unless one orientation is essential

• Rules decide part of it
• Tools: The browser's developer tools

1. Open the page in the developer tools' device toolbar, or on a phone or tablet.
2. View it in portrait, then rotate it to landscape (or the reverse), and use its main content and controls in each.
3. Confirm the result on a real phone or tablet with its rotation lock turned off. The device toolbar can't show whether the page locks orientation with script or, for an installed web app, through its manifest.
4. Check that the page doesn't ask you to rotate the device, turn its content sideways, or hide content in one orientation.
5. Where it does, ask whether that orientation is essential, as for a bank cheque or a piano keyboard.

Passes when

The page shows and works in both orientations, or one orientation is essential to it.

Fails when

The page works in only one orientation, by asking to rotate the device, turning its content or hiding it, with no essential reason, which fails WCAG 1.3.4.

Rules that test it: css-orientation-lock

Fields that ask for information about the user name its purpose with the right autocomplete value

• Rules decide part of it
• Tools: The browser's developer tools

1. Find every field that asks for information about the person using the page: name, email, phone, address, birthday, username, password, card details.
2. For each, read its autocomplete attribute in the developer tools' Elements pane.
3. Check that it is the value that matches what the field asks for (name, email, tel, street-address, postal-code, bday, username, new-password, cc-number and so on).
4. A field with autocomplete="off", or with no autocomplete attribute, doesn't identify its purpose, even when the browser still offers to fill it in.
5. Leave out fields that ask about someone else, such as a gift recipient, unless they say so with the right section or value.
6. Only the purposes in WCAG's list of input purposes are in scope. A field for a membership or customer number, for example, has no value in that list and needs none.

Passes when

Every field that asks for the user's own information has the autocomplete value that matches it.

Fails when

A field that asks for the user's own information has no autocomplete value, or a wrong one, so the browser and assistive tools can't fill it in or mark its purpose, which fails WCAG 1.3.5.

Rules that test it: autocomplete-valid

Colour is not the only way information is shown, a choice is asked for or an element is set apart

• Rules decide part of it
• Tools: The browser's developer tools

1. Look for information the page gives by color: links in a paragraph, required or invalid fields, the selected tab or day, chart series, status in red or green.
2. For each, check whether something besides colour gives it too: an underline, an icon, a text label, a pattern, a border or a change of shape.
3. For links in a paragraph that differ only by colour, check that they get an underline or other mark when hovered and focused, and that their colour has a contrast of at least 3:1 with the text around them.
4. View the page in greyscale (in the developer tools' Rendering pane, emulate achromatopsia) and check that nothing is lost.

Passes when

Everything the page gives by colour is also given another way.

Fails when

Information, such as which fields have errors or which text is a link, is given only by colour, which fails WCAG 1.4.1.

Rules that test it: link-in-text-block

Sound that plays by itself for more than 3 seconds can be paused, stopped or turned down

• Only a person can check it
• Tools: A keyboard

1. Load the page with the sound on and listen for sound that starts by itself: music, a video, an advertisement.
2. Where sound plays for more than 3 seconds, look near the top of the page or the player for a way to pause or stop it, or to turn its volume down apart from the computer's volume.
3. Check that the control can be found and used with the keyboard.

Passes when

No sound plays by itself for more than 3 seconds, or a control near the start of the page pauses, stops or lowers it.

Fails when

Sound plays by itself for more than 3 seconds with no way to pause, stop or lower it apart from the computer's volume, so it drowns out a screen reader, which fails WCAG 1.4.2.

Rules that test it: no-autoplay-audio

Text has a contrast of at least 4.5:1 with its background, or 3:1 when large

• Rules decide part of it
• Tools: The browser's developer tools

1. Look through the page for text that seems faint against its background: light grey text, text on coloured panels, placeholders, text over images or gradients, text in buttons.
2. For each, inspect it and click the swatch of its colour in the developer tools' Styles pane: the picker shows its contrast ratio with the background.
3. The colour picker measures against the background colour set in CSS. Where text sits on an image, a gradient or a semi-transparent layer, or its colour comes from opacity or a blend mode, the picker's figure is not reliable: use the next step instead.
4. Where the background is an image, a gradient or a semi-transparent layer, measure the text against the part of the background where it is least visible, with a colour contrast checker.
5. Check the ratio is at least 4.5:1, or 3:1 for large text: at least 24 pixels (18pt), or 18.66 pixels (14pt) and bold.
6. Don't round the result: 4.49:1 fails. Check text in its other states too, such as on hover, on focus and when selected, since a state can lower the contrast.
7. Leave out logos and brand names, text on controls that are disabled, text that is only decoration or that nobody can see, and text that is part of a picture with other important content, such as a street sign in a photo.

Passes when

All text and images of text have a contrast of at least 4.5:1 with their background, or 3:1 when large.

Fails when

Text has less contrast with its background than 4.5:1 (3:1 for large text), so people with low vision can't read it, which fails WCAG 1.4.3.

Rules that test it: contrast-minimum, contrast-computable

Text can be resized to 200% without losing content or function

• Rules decide part of it
• Tools: The browser's zoom

1. Zoom the browser to 200%.
2. Go through the whole page and check that all text has grown, and none is cut off, overlapped or hidden.
3. Use the page's controls, menus and forms at that size and check that they all still work.
4. On a phone, check that you can pinch to zoom the page to 200%. Use Chrome on Android with its "Force enable zoom" accessibility setting turned off: Safari on iOS ignores a viewport that blocks zoom, so it can hide this failure.
5. Leave out captions and images of text.

Passes when

At 200% all text has grown and stays readable, and everything still works.

Fails when

At 200% text is cut off, overlaps or doesn't grow, a control stops working, or pinch zoom is blocked, which fails WCAG 1.4.4.

Rules that test it: meta-viewport-zoom-enabled

Text is shown as text, not in an image, unless its look is essential, as in a logo

• Only a person can check it
• Tools: The browser's developer tools

1. Look for images that contain words: banners, headings, buttons, quotes, menus.
2. Try to select a word of it with the pointer, or inspect it: text that can't be selected is usually in an image, an SVG drawing or a canvas.
3. For each, ask whether the same could be shown with real text styled with CSS.
4. Leave out logos and brand names, images where the particular look of the text is essential, such as a font sample, and images of text that the user can change to suit them, such as a page that lets the user set the font, size and colours of the text in the image.

Passes when

Text is real text, or an image of text is a logo or needs its exact look.

Fails when

Words are shown as an image where styled text would look the same, so people can't resize, recolor or respace them, which fails WCAG 1.4.5.

Rules that test it: image-of-text

At 320 CSS pixels wide, content needs no scrolling in two directions and nothing is lost

• Only a person can check it

No procedure for this yet.

The parts of a control that show it is there and its state have a contrast of at least 3:1

• Only a person can check it

No procedure for this yet.

The parts of a graphic needed to understand it have a contrast of at least 3:1

• Only a person can check it

No procedure for this yet.

Spacing forced in a style attribute doesn't stop text from taking the user's spacing

• Rules decide part of it
• Tools: The browser's developer tools

1. In the developer tools' Elements pane, search the page's markup (Ctrl+F, or Cmd+F on a Mac) for !important, and note each match in a style attribute that sets line-height, letter-spacing or word-spacing.
2. For each, read the resulting value in the Computed tab and compare it with 1.5 times the font size for line-height, 0.12 times for letter-spacing and 0.16 times for word-spacing.
3. Where the value is lower, narrow the window to 320 CSS pixels wide and check whether that text wraps onto more than one line.
4. In the developer tools' Styles pane, add a new style rule for * setting line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important, and a rule for p setting margin-bottom: 2em !important. The element keeps its own value, since its style attribute wins.
5. Check whether that text is cut off, overlaps other text or is hidden.

Passes when

No style attribute forces spacing below those values on text that wraps, or the text it forces still shows in full with the spacing applied.

Fails when

A style attribute forces spacing below those values on wrapping text, so a bookmarklet or browser extension can't apply the person's spacing, and with that spacing the text overlaps or is cut off, which fails WCAG 1.4.12.

Rules that test it: avoid-inline-spacing

With the 1.4.12 spacing applied, no text is cut off or made to overlap (measured in a browser)

• Rules decide part of it
• Tools: The browser's developer tools, A keyboard

1. In the developer tools' Styles pane, add a new style rule for * setting line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important, and a rule for p setting margin-bottom: 2em !important. Rules added in the Styles pane are not blocked by the page's security policy.
2. Scroll through the whole page and look for text that is cut off, overlaps other text or disappears. Text that is part of an image doesn't count.
3. Do this at the widths you test elsewhere, including 320 CSS pixels wide, where text wraps most and is most often cut off.
4. Where text is cut off, check whether the page offers a way to show all of it, such as a "Read more" link or a button that expands the box. It only counts if you can use it with the keyboard and, with the spacing still applied, it shows the whole text.

Passes when

All text stays visible and readable, or any text that is cut off can be shown in full with the keyboard.

Fails when

Some text is cut off, overlaps or is lost with the spacing applied and cannot be shown in full another way, which fails WCAG 1.4.12.

Rules that test it: text-spacing-content-loss

With the 1.4.12 spacing applied, controls, menus and forms keep working and show all their text

• Only a person can check it
• Tools: The browser's developer tools, A keyboard, A mouse or other pointer

1. In the developer tools' Styles pane, add a new style rule for * setting line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important, and a rule for p setting margin-bottom: 2em !important.
2. Use each control on the page: open its menus and drop-downs, fill in and submit its forms, switch its tabs, and open and close its dialogs.
3. Check that each still responds, that no text pushed out of place covers a control, and that every label and button shows all its text.

Passes when

Every control still works and shows all its text with the spacing applied.

Fails when

With the spacing applied, a control stops working, is covered so it can't be used, or loses text that says what it does, which fails WCAG 1.4.12.

With the 1.4.12 spacing applied, content shown only after interaction (menus, dialogs, tabs, messages) keeps all its text

• Only a person can check it
• Tools: The browser's developer tools, A keyboard, A mouse or other pointer

1. In the developer tools' Styles pane, add a new style rule for * setting line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important, and a rule for p setting margin-bottom: 2em !important.
2. Bring up the content the page shows only after you do something: open each menu and dialog, switch to each tab, expand each collapsed section, show each tooltip, and submit a form with a mistake in it to see its error messages.
3. Check each for text that is cut off, overlaps other text or disappears, as on the page itself.
4. Where text is cut off, check whether the page offers a way to show all of it, such as a "Read more" link or a button that expands the box. It only counts if you can use it with the keyboard and, with the spacing still applied, it shows the whole text.

Passes when

Content shown after you do something keeps all its text visible and readable with the spacing applied, or the text that is cut off can be shown in full with the keyboard.

Fails when

Text in a menu, dialog, tab, tooltip or message is cut off or overlaps with the spacing applied and can't be shown in full another way, which fails WCAG 1.4.12.

Extra content that appears on hover or focus can be dismissed without moving the pointer or focus

• Only a person can check it

No procedure for this yet.

The pointer can move onto extra content that appears on hover without it disappearing

• Only a person can check it

No procedure for this yet.

Extra content that appears on hover or focus stays until it is dismissed, the pointer or focus leaves, or it is no longer true

• Only a person can check it

No procedure for this yet.

All functionality can be operated from a keyboard alone

• Only a person can check it
• Tools: A keyboard

1. Turn off any screen reader. In browse mode a screen reader can activate elements that the keyboard alone can't reach, which hides failures.
2. Reload the page and, without clicking, press Tab repeatedly through the whole page. Note every link, button, field and other control you pass.
3. Compare with what you can click or drag with the pointer, and note anything the keyboard never reaches: a control, a menu item, a scrollable box, a part of a map or a custom widget.
4. Use each control with the keyboard: Enter or Space to activate it, arrow keys inside menus, tabs, lists and sliders, Escape to close what opens.
5. For custom widgets, compare the keys with those the WAI-ARIA Authoring Practices give for that kind of widget, such as the arrow keys in a tab list. A widget that works only with unusual keys may still pass this criterion if the page explains them, but record it as a usability issue.
6. Where something can't be reached or used with the keyboard, check whether the page offers another way to do the same with the keyboard alone, such as previous and next buttons for a carousel. It only counts if it does everything the pointer can.
7. Leave out what depends on the path the pointer takes, such as freehand drawing.

Passes when

Everything the page lets you do with a pointer can be done with the keyboard alone, directly or through another way that does the same job.

Fails when

Something can only be done with a pointer, with no keyboard way to do the same, which fails WCAG 2.1.1.

Rules that test it: iframe-focusable-content, server-side-image-map-absent, scrollable-region-focusable, mouse-only-event-handlers, click-handler-keyboard-operable, widget-keyboard-focusable, focus-not-removed-by-script

Focus can always be moved away from any part of the page with the keyboard

• Only a person can check it

No procedure for this yet.

Shortcuts made of a single letter, number or symbol can be turned off or remapped, or work only while their control has focus

• Only a person can check it

No procedure for this yet.

Each time limit can be turned off, adjusted or extended, unless it is real-time, essential or over 20 hours

• Rules decide part of it
• Tools: a browser only

1. Look for anything on the page that happens after a set time: a session that ends, a form that expires, a page that refreshes or moves on by itself, content that disappears.
2. Check the page's source and wait on it for a while to find limits that aren't announced, such as a <meta http-equiv="refresh"> or a sign-out after inactivity.
3. For a session that ends on the server, ask the team how long it lasts rather than guessing, then wait for the warning at that point. Check the warning with a screen reader: it must be announced, not only shown.
4. For each limit, check that at least one of these holds: you can turn it off before you meet it; you can adjust it to at least ten times its length; or you are warned before it ends, have at least 20 seconds to extend it with a simple action such as pressing a key, and can extend it at least ten times.
5. Leave out limits that are part of a real-time event such as an auction, that are essential such as a timed test, or that are longer than 20 hours.

Passes when

Every time limit can be turned off, adjusted or extended, or is real-time, essential or over 20 hours.

Fails when

A time limit ends a session, a form or a page with no way to turn it off, adjust it or extend it, which fails WCAG 2.2.1.

Rules that test it: meta-refresh-timing-absent

Animations that start by themselves and last over five seconds can be paused, stopped or hidden

• Only a person can check it
• Tools: A keyboard

1. Load the page and watch for anything that moves, blinks or scrolls by itself: carousels, scrolling text, animations, background videos.
2. For each that starts by itself, lasts more than 5 seconds and is shown alongside other content, look for a control to pause, stop or hide it.
3. Check that the control can be found and used with the keyboard, and that it stops the movement rather than only slowing it.
4. Leave out movement that is essential, such as a progress indicator while something loads.

Passes when

Everything that moves, blinks or scrolls by itself for more than 5 seconds next to other content can be paused, stopped or hidden.

Fails when

Content moves, blinks or scrolls by itself for more than 5 seconds next to other content with no way to pause, stop or hide it, which fails WCAG 2.2.2.

Rules that test it: moving-content-pausable, deprecated-elements-not-used

Content that updates by itself can be paused, stopped, hidden or set to update less often

• Only a person can check it
• Tools: A keyboard

1. Watch the page for content that changes by itself: news tickers, live scores, prices, feeds, timers.
2. For each that starts by itself and is shown alongside other content, look for a control to pause, stop or hide it, or to choose how often it updates.
3. Check that the control can be found and used with the keyboard.
4. Leave out updates that are essential to what the page is for.

Passes when

Every part that updates by itself next to other content can be paused, stopped, hidden or slowed, or its updates are essential.

Fails when

Content updates by itself next to other content with no way to pause, stop, hide it or change how often, which fails WCAG 2.2.2.

Nothing flashes more than three times in any one second, or the flashes are small and dim enough

• Only a person can check it

No procedure for this yet.

Blocks repeated on several pages can be skipped

• Rules decide part of it
• Tools: A keyboard, A screen reader, The browser's developer tools

1. Close any dialog or overlay, then note the blocks the page repeats from other pages of the site: header, navigation, search, sidebars.
2. Reload the page and press Tab once: check whether a skip link appears that moves focus past those blocks to the main content, and follow it with Enter.
3. Check, in the developer tools' Accessibility pane or a screen reader's lists, whether the main content is a main landmark or starts with a heading outside the navigation.
4. Where the page has a skip link, check that its target exists and that the next Tab after following it goes into the main content.

Passes when

The page repeats no blocks, or a working skip link, a main landmark or headings let keyboard and screen reader users jump past them.

Fails when

Repeated blocks have no way to skip them, so keyboard and screen reader users must go through them on every page, which fails WCAG 2.4.1.

Rules that test it: bypass-blocks-present

The page has a title that says what it is about or for, and tells it apart from the site's other pages

• Rules decide part of it
• Tools: a browser only

1. Read the page's title in the browser tab, or in <title> in the developer tools' Elements pane.
2. Check that it says what this page is about or what it is for, such as the article's headline or the step of a process ("Delivery address - Checkout - Shop").
3. Open two or three other pages of the site and check that their titles tell the pages apart. Putting the page's own part first, before the site's name, is good practice but isn't required.
4. Where the page changes its content without loading a new page, as a single-page app does, check that the title changes with it.

Passes when

The page's title says what it is about or for and tells it apart from other pages.

Fails when

The page has no title, or one that is generic, a file name, or the same as other pages', which fails WCAG 2.4.2.

Rules that test it: page-title-present, page-title-patterns

Moving focus with Tab and Shift+Tab follows an order that keeps the page's meaning and lets it be used

• Only a person can check it
• Tools: A keyboard

1. Reload the page and press Tab repeatedly until focus has been through the whole page, watching where it goes.
2. Compare the order with the order in which you would read and use the page: a form's fields in the order of their labels, for example, and the steps of a task in their sequence.
3. Press Shift+Tab back through the page and check that focus goes back the same way in reverse.
4. Where the order differs from the reading order, check whether that changes what something means or keeps you from using it, such as reaching a form's Submit button before its fields.

Passes when

Focus moves through the page in an order that keeps its meaning and lets every part be used, even where it differs from the visual order in small ways.

Fails when

Focus jumps around the page so that its meaning or use changes, such as fields filled in out of their order, which fails WCAG 2.4.3.

Focus moves into a dialog, menu or section that opens, stays in a dialog while it covers the page, and comes back when it closes

• Only a person can check it
• Tools: A keyboard

1. With the keyboard, open each dialog, menu, drop-down and collapsed section the page has, by pressing Enter or Space on the control that opens it.
2. Press Tab once and check that focus goes into what opened, or is already in it, rather than to something behind it or far from it.
3. In a dialog that covers the page, press Tab until you have been through all its controls, and check that focus stays in the dialog rather than going to the page behind it.
4. Close it with Escape or its close button, and check that focus goes back to the control that opened it, or to the next sensible place.

Passes when

Focus goes into what opens, stays in a dialog while it covers the page, and comes back to where it was when it closes.

Fails when

Focus stays behind what opens, leaves a dialog for the page behind it, or lands at the top of the page when it closes, so the order no longer follows what is on screen, which fails WCAG 2.4.3.

Focus does not stop on content that is closed, hidden or off screen

• Only a person can check it
• Tools: A keyboard, The browser's developer tools

1. Close any menu or dialog, reload the page, then press Tab through the whole page, watching where focus is.
2. Note each time focus seems to disappear for one or more presses.
3. At each such stop, type document.activeElement in the developer tools' Console and check whether the element it shows is in a closed menu, a hidden panel or off screen.
4. Leave out a skip link that appears when it receives focus: it is shown once focused.

Passes when

Every Tab stop is on something you can see, or on something that appears when it receives focus, such as a skip link.

Fails when

Focus stops on controls in closed menus, hidden panels or off screen, so the order passes through things that aren't there, which fails WCAG 2.4.3.

Each link's purpose can be told from its text, or from its text with the sentence, paragraph, list item or table cell it is in

• Rules decide part of it
• Tools: The browser's developer tools, A screen reader

1. List the page's links with a screen reader's links list, or go through them with Tab and read the Name of each in the developer tools' Accessibility pane.
2. Note links whose name doesn't say where they go or what they do: empty names, "click here", "read more", "PDF", an icon's file name.
3. For each, read the sentence, paragraph, list item or table cell the link is in, or the table header of its cell, and check whether that makes its purpose clear.
4. The context that counts is the link's sentence, paragraph, list item or table cell, the header cells of its table cell, the heading the link sits under, and text tied to the link with aria-describedby. Text that is only near the link, such as a paragraph in another column, doesn't count.
5. Check that links with the same name that lead to different places are told apart by their context.

Passes when

Every link's purpose is clear from its name, or from its name with the sentence, paragraph, list item or table cell it is in.

Fails when

A link has no name, or a name such as "read more" whose purpose nothing around it explains, which fails WCAG 2.4.4.

Rules that test it: link-name-present, link-name-quality

There is more than one way to find a page in the site

• Only a person can check it

No procedure for this yet.

Headings describe the content that follows them

• Only a person can check it
• Tools: A screen reader

1. List the page's headings with a screen reader's headings list, a browser extension such as HeadingsMap, or the developer tools' Accessibility tree.
2. Read each heading and the content under it.
3. Check that each heading says what that content is about, not a placeholder, a file name or a word that could head anything.
4. Check that headings next to each other at the same level can be told apart.
5. This criterion only asks that headings and labels which exist describe their content. A missing heading or label is checked under 1.3.1 or 3.3.2, not here.

Passes when

Every heading says what the content under it is about.

Fails when

A heading doesn't describe the content under it, such as "Section 1" or a file name, which fails WCAG 2.4.6.

Rules that test it: heading-quality

Labels describe their fields, and fields with the same label can be told apart

• Only a person can check it
• Tools: a browser only

1. Read the visible label of every field and control on the page.
2. Check that each says what to enter or choose, such as "Email address" rather than "Field 1" or "Text".
3. Where several fields share a label, such as "Name" twice, check that the page makes clear which is which, by a group heading or the rest of the label.

Passes when

Every label says what its field or control is for, and fields with the same label are told apart.

Fails when

A label doesn't say what its field is for, or several fields have the same label with nothing telling them apart, which fails WCAG 2.4.6.

Rules that test it: form-control-label-quality

Every element that takes keyboard focus shows that it has it

• Rules decide part of it
• Tools: A keyboard

1. Reload the page and press Tab slowly through the whole page.
2. At each stop, check that you can see which element has focus: an outline, a change of colour, an underline or another visible change.
3. Use the keyboard, not the mouse, to move focus. Browsers show the focus of an element clicked with the mouse differently from one reached with Tab, so a mouse test proves nothing here.
4. Note each stop where you can't tell where focus is, and each time focus seems to disappear for a press or more.
5. Do the same inside menus, dialogs and widgets that use the arrow keys.
6. Turn on a contrast theme in Windows and repeat a few stops. A focus style drawn only with box-shadow or a background colour disappears in that mode. WCAG doesn't require it to show there, but record it as a best practice issue.

Passes when

At every stop you can see which element has focus.

Fails when

Focus reaches an element with no visible change, or lands on something hidden or off screen, so keyboard users lose track of where they are, which fails WCAG 2.4.7.

Rules that test it: css-hidden-focus, css-focus-indicator-suppressed, focus-not-removed-by-script

An element that receives focus is not entirely hidden by content the page puts over it

• Only a person can check it

No procedure for this yet.

What a path or multipoint gesture does can also be done with a single tap or click

• Only a person can check it

No procedure for this yet.

Actions run when the pointer is released, not pressed, or can be cancelled or undone

• Only a person can check it

No procedure for this yet.

A control's name contains the text of its visible label

• Rules decide part of it
• Tools: The browser's developer tools

1. Find every control with a visible label made of text: buttons, links, fields, tabs, menu items, and controls labelled by text next to them.
2. For each, read its Name in the developer tools' Accessibility pane.
3. Check that the name contains the visible label's words, in the same order, ideally at the start (a button showing "Send" named "Send message", not "Submit").
4. Ignore differences of case and punctuation when you compare. Text shown as an image counts as a visible label too.
5. Leave out a label made only of symbols, such as "×" or ">": the name should say what it does.
6. Leave out controls with no visible text, such as an icon-only button: they have no visible label to match.

Passes when

Every control's name contains the words of its visible label, in order.

Fails when

A control's name doesn't contain its visible label, so someone who uses speech input can't activate it by saying what they see, which fails WCAG 2.5.3.

Rules that test it: label-in-name

What is done by moving the device can also be done with controls, and the motion response can be turned off

• Only a person can check it

No procedure for this yet.

What is done by dragging can also be done with single taps or clicks

• Only a person can check it

No procedure for this yet.

Targets are at least 24 by 24 CSS pixels, or far enough apart

• Rules decide part of it
• Tools: The browser's developer tools

1. Look for small controls: icons, close buttons, pagination, links in a row, small check boxes.
2. Inspect each and read the size of the area that responds to the pointer, which can be larger than the visible icon, in the developer tools' box model. Check that it is at least 24 by 24 CSS pixels.
3. Where it is smaller, check whether a 24-pixel circle centred on it would touch another target, or the circle of another small target.
4. Leave out links in a sentence or paragraph, controls the browser draws unstyled, controls with a full-size equivalent elsewhere on the page, and targets whose size is essential, such as a map's pins.

Passes when

Every target is at least 24 by 24 CSS pixels, or far enough from others, or one of the exceptions.

Fails when

A target smaller than 24 by 24 CSS pixels sits so close to another that their 24-pixel circles overlap, with no exception that applies, which fails WCAG 2.5.8.

Rules that test it: target-size-minimum

The page's main language is given in its markup, and is the right one

• Rules decide part of it
• Tools: The browser's developer tools

1. Read the lang attribute of the <html> element in the developer tools' Elements pane.
2. Check that it is a language code (en, fr, pt-BR) and that it is the language most of the page's text is in.
3. Where <html> also has xml:lang, check that both give the same language.
4. In a single-page application, change the interface language and check that lang changes with it. A screen reader switches voice only if one for that language is installed, so judge by the markup, not only by what you hear.

Passes when

The <html> element's lang gives the language most of the page is in.

Fails when

The page has no lang, a wrong or invalid one, so screen readers read it with the wrong voice and pronunciation, which fails WCAG 3.1.1.

Rules that test it: html-lang-attr-present, html-xml-lang-mismatch

Passages and phrases in a language other than the page's are marked with their own language

• Rules decide part of it
• Tools: The browser's developer tools, A screen reader

1. Read through the page and note passages, quotes, phrases and names of things written in another language than the page's, including a language picker's options.
2. For each, check in the developer tools' Elements pane that it, or an element around it, has a lang attribute with that language's code.
3. Leave out proper names, technical terms, and words that have become part of the page's language, such as "café" in English.
4. Listen to a few with a screen reader to check it switches pronunciation.

Passes when

Every passage or phrase in another language is marked with a valid lang attribute for that language.

Fails when

A passage or phrase in another language isn't marked with its language, or is marked with a wrong code, so it is read with the wrong pronunciation, which fails WCAG 3.1.2.

Rules that test it: valid-lang

Moving focus onto an element doesn't change the context by itself

• Only a person can check it

No procedure for this yet.

Changing a setting doesn't change the context unless the user is told beforehand

• Only a person can check it

No procedure for this yet.

Navigation repeated on several pages comes in the same relative order each time

• Only a person can check it

No procedure for this yet.

Components that do the same thing across pages are identified the same way

• Only a person can check it

No procedure for this yet.

Help offered on several pages is in the same relative place each time

• Only a person can check it

No procedure for this yet.

An input error the page detects is shown in text that says which field is wrong and what is wrong

• Rules decide part of it
• Tools: A keyboard, A screen reader

1. Find each form on the page and send it empty, then with wrong values: a malformed email, letters in a number field, a date in the past.
2. Check that each error the page detects is shown in text, not only by colour or an icon, next to the field or in a list at the top.
3. Check that the text says which field is wrong and what is wrong with it.
4. The browser's own validation messages count as text, but their wording and how long they stay on screen differ between browsers. Check them in each browser you test.
5. Check with a screen reader that the error is announced or reached easily, and that each wrong field is marked invalid.

Passes when

Every input error the page detects is shown in text that names the field and the problem.

Fails when

An input error is shown only by colour or an icon, not at all, or without saying which field is wrong, which fails WCAG 3.3.1.

Rules that test it: invalid-field-error-message

Fields that ask for input have a visible label, and instructions where the input needs them

• Rules decide part of it
• Tools: The browser's developer tools

1. Find every field and control that asks for input on the page.
2. Check that each has a label you can see without hovering or typing: not only a placeholder that disappears when you type, or a title shown on hover.
3. Where the input must follow rules, such as a date format, a password's requirements or which fields are required, check that the page says so before the user sends it.
4. This criterion asks only that labels and instructions are shown. Whether a label is tied to its field in the markup is checked under 1.3.1 and 4.1.2.

Passes when

Every field has a visible label, and the page gives the instructions the input needs before it is sent.

Fails when

A field has no visible label, only a placeholder or a hover title, or input rules are given only after an error, which fails WCAG 3.3.2.

Rules that test it: form-control-programmatic-label-present, form-control-single-label, form-control-programmatic-label-quality

When the page knows how to fix an input error, it says how

• Only a person can check it

No procedure for this yet.

Submissions with legal or financial effect, or that change stored data, can be reversed, checked or reviewed and confirmed

• Only a person can check it

No procedure for this yet.

Information the user already gave in a process is filled in or offered to pick, not asked for again

• Only a person can check it

No procedure for this yet.

Signing in doesn't require remembering, transcribing or solving something, unless a way around it is offered

• Only a person can check it
• Tools: a browser only

1. Go through each way the site lets you sign in or verify yourself, with a test account.
2. Note each step that asks you to remember something (a password), transcribe it (a code from another device), or solve something (a puzzle, a calculation, picking images).
3. For a password or code, check that you can paste it and that a password manager can fill it, so it needn't be remembered or retyped.
4. Check that a password manager actually fills the fields: the username and password fields need autocomplete="username" and autocomplete="current-password" (or new-password), and a one-time code field works best with autocomplete="one-time-code".
5. Where a code is split into one box per digit, paste the whole code into the first box and check that it fills them all. Boxes that block pasting, or take only one character each, fail.
6. For other tests, check that another method is offered, or that the test only asks to recognise objects or something you gave the site.
7. Count a CAPTCHA shown during sign-in as part of the sign-in. Other methods that need no cognitive test, such as a passkey, a sign-in link sent by email or signing in through a third party, are valid alternatives.

Passes when

Every sign-in step that asks to remember, transcribe or solve something allows pasting and password managers, or offers another way, or only asks to recognise objects or your own content.

Fails when

Signing in requires remembering, transcribing or solving something with no way around it, such as a code field that blocks pasting, which fails WCAG 3.3.8.

Rules that test it: password-paste-enabled

Every link, control, frame and dialog has a name that says what it is for

• Rules decide part of it
• Tools: The browser's developer tools, A screen reader

1. Go through every link, button, field, frame and custom control on the page, by pressing Tab and inside widgets with the arrow keys.
2. For each, read the Name in the developer tools' Accessibility pane, or listen to what a screen reader says.
3. Check names in two browser and screen reader pairs. Names built from aria-labelledby, from a label that wraps the control, or from CSS content can differ between them.
4. Check that each has a name that says what it is for, including icon-only buttons, frames ("Video player", "Map") and dialogs.
5. Check that frames with the same name show the same thing, and that names given only for braille have a spoken equivalent.

Passes when

Every link, control, frame and dialog has a name that says what it is for.

Fails when

A link, control, frame or dialog has no name, or one that doesn't say what it is for, so assistive technology announces only its role, which fails WCAG 4.1.2.

Rules that test it: form-control-programmatic-label-present, link-name-present, button-name-present, input-image-alt-present, binary-control-name-present, combobox-name-present, dialog-name-present, menuitem-name-present, tab-name-present, slider-name-present, textbox-name-present, searchbox-name-present, spinbutton-name-present, listbox-name-present, option-name-present, treeitem-name-present, aria-role-name-present, iframe-name-present, identical-iframes-same-purpose, iframe-title-unique, summary-name-present, tooltip-name-present, aria-braille-equivalent

Every control's role says what it does, and controls aren't nested inside one another

• Rules decide part of it
• Tools: The browser's developer tools, A screen reader

1. For each control on the page, note what it does when used: opens a page (a link), acts on the page (a button), toggles (a check box or switch), opens a list (a menu or combo box).
2. Read its Role in the developer tools' Accessibility pane, or listen to a screen reader, and check that the role matches what it does.
3. Pay attention to custom controls built from divs and spans, links used as buttons and buttons used as links.
4. Check that no control holds another one inside it, such as a button inside a link, and that controls whose children are presentational, such as a tab or a button, hold nothing focusable.

Passes when

Every control's role says what it does, and no control is nested inside another.

Fails when

A control has no role, a wrong one (a clickable div with no role, a link that acts as a button), or holds another control inside it, which fails WCAG 4.1.2.

Rules that test it: aria-roles-valid, aria-deprecated-role, nested-interactive-controls-absent, presentational-children-focusable-absent

Every control's state and value are exposed and change with what is on screen

• Rules decide part of it
• Tools: The browser's developer tools, A screen reader, A keyboard

1. Find the controls that have a state or value: check boxes, switches, radio buttons, expandable sections and menus, tabs, sliders, selected items, pressed buttons.
2. Read each one's state and value in the developer tools' Accessibility pane, or listen with a screen reader: checked, expanded, selected, pressed, the current item (aria-current), and the current value of a slider or spin button.
3. Change each with the keyboard and check that the state or value read changes with what you see.
4. For an expandable control, check that it says expanded only while what it opens is shown.

Passes when

Every control's state and value are exposed and change with what is on screen.

Fails when

A control's state or value isn't exposed, or doesn't change when it changes on screen, such as a custom check box always read as not checked, which fails WCAG 4.1.2.

Rules that test it: aria-required-attr, aria-conditional-attr, aria-checked-state-mismatch, aria-expanded-state-mismatch

ARIA attributes are real, valid and allowed where they are, and nothing focusable is hidden from assistive technology

• Rules decide part of it
• Tools: The browser's developer tools

1. In the developer tools' Elements pane, search the markup for aria- and role= and look at each use.
2. Check that each aria-* attribute is a real one, has a valid value, and is allowed on its element's role.
3. Check that ids that aria-labelledby, aria-describedby, aria-controls and the like point to exist once each.
4. Check that nothing that takes focus is inside an element with aria-hidden="true", and that <body> isn't hidden.

Passes when

ARIA attributes are real, valid and allowed where they are, their ids are unique, and nothing focusable is hidden.

Fails when

An ARIA attribute is misspelt, has an invalid value or is not allowed on its role, an id it points to is missing or repeated, or something focusable is hidden from assistive technology, which fails WCAG 4.1.2.

Rules that test it: aria-hidden-focus, aria-valid-attr, aria-valid-attr-value, aria-allowed-attr, aria-prohibited-attr, aria-hidden-body, duplicate-id-aria

Status messages are announced by assistive technology without taking focus

• Only a person can check it
• Tools: A screen reader

1. Find the messages the page shows without moving focus: "Added to cart", search result counts, "Saved", progress, form errors listed after sending.
2. Turn on a screen reader and cause each message, by the action that shows it.
3. Check that the screen reader says the message without focus moving to it.
4. Repeat in a second browser and screen reader pair. Live regions are among the least consistent parts of screen reader support.
5. Where it says nothing, check in the developer tools that the message is in an element with role="status", role="alert" or aria-live, and that the element is not hidden. A role="status" or aria-live region must already be on the page, empty, before the message is put in it. An element with role="alert" is usually announced even when it is added together with its message.
6. Leave out messages that receive focus, or that come with a new page: those are not status messages, and are checked under other criteria.

Passes when

Every status message is announced by a screen reader without focus moving to it.

Fails when

A status message appears on screen but a screen reader doesn't say it, which fails WCAG 4.1.3.

Rules that test it: live-region-announcements