surea11y scan report

1. Make the field invalid the way a user would (submit the form empty, or type a wrong value).
2. Look for the error message the field points to (its aria-errormessage), and check whether it appears on screen.
3. If it doesn't, look for any text that tells you what is wrong: in the label, next to the field, or in a summary at the top of the form.
4. With a screen reader, move to the field and listen for the error.

Passes: The error is shown in text, and announced, somewhere tied to the field, even if not in the message aria-errormessage names.

Fails: No text tells you which field is wrong and why, or a screen reader user isn't told, which fails WCAG 3.3.1.

1. Find the image the report names and read its alt text (the report gives the reason it looked suspect, if any).
2. Look at the image and its context, and ask what it shows that matters to the page.
3. If the text alternative only names the image, as is common for charts and diagrams, the details may be given elsewhere: in a caption, text or a table next to it, or a link beside it. That counts only if a screen reader user can find it from the image and it gives everything the image shows.
4. Decide whether the alt says what matters, or names the image while that description gives the rest; a file name, web address or generic word such as "image" does neither.

Passes: The alt text conveys what the image shows that a user needs, or it names the image and a description a screen reader user can reach from it gives the rest.

Fails: Neither the alt text nor a description reachable from the image conveys the image's content (for example the alt is a file name, address or generic word), which fails WCAG 1.1.1 (F30).

1. Inspect the elements the report names and note the shared id.
2. Check whether anything refers to that id: a label's for, an aria-* attribute such as aria-labelledby, or a link to #the-id.
3. If something refers to it, follow the reference (click the label or link, or read the name in the Accessibility pane) and check that it reaches the intended element.
4. Check which WCAG version and standard the audit applies; under WCAG 2.2 or 2.0/2.1 with the 2023 errata, 4.1.1 is satisfied for HTML.

Passes: Nothing breaks because of the duplicate (references reach the intended element) and the audit uses WCAG 2.2 or 2.0/2.1 with the errata, under which 4.1.1 is satisfied.

Fails: A label, ARIA reference or link reaches the wrong element (WCAG 1.3.1 or 4.1.2), or the audit follows a standard that keeps 4.1.1's text, such as EN 301 549 V3.2.1, where duplicate ids fail 4.1.1 (F77).

1. Click the browser's address bar, then press Tab repeatedly to move through every link and control on the page.
2. At each stop, check that you can see where focus is, and that the order follows the reading order of the page.
3. Operate each control with the keyboard (Enter, Space, arrow keys) and open and close menus and dialogs.
4. Where something cannot 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, or move up and move down buttons for a list you can drag. It only counts if it does everything the mouse can.
5. Check that focus never gets stuck inside a component and that Escape or Tab lets you move on.

Passes: Everything works with the keyboard, directly or through another way that does the same job, focus moves in a sensible order and is always visible, and it never gets stuck.

Fails: Something cannot be reached or used with the keyboard in any way, focus traps the user, the order is confusing, or focus is invisible, which fails WCAG 2.1.1, 2.1.2, 2.4.3 or 2.4.7.

1. Read the page title the report gives; the browser shows it in the tab.
2. Look at the page's main heading and content and note what the page is about.
3. Decide whether the title says that topic or purpose.

Passes: The title says what the page is about or what it is for.

Fails: The title does not say what the page is about or what it is for, which fails WCAG 2.4.2.