How to check a website for accessibility in ten minutes

Ten minutes will not produce a conformance claim. It will find the problems that stop people using a page at all - a control the keyboard cannot reach, a layout that breaks when text is enlarged, a form field with no name. The order below is the order that finds the most in the least time:

1. Automated scan - one minute. Lighthouse's accessibility audit, or axe DevTools, on the page as it loads.
2. Keyboard pass - three minutes. Tab through everything, with the mouse out of reach.
3. Zoom and reflow - two minutes. 400% in a 1280px-wide window, then a text-spacing check.
4. Contrast - one minute. Body text, placeholder text, focus rings, button borders.
5. Structure - one minute. The page title, the heading outline and the landmarks.
6. Images and forms - two minutes. Alt text that says something, and fields that have names.

The success criteria named below are from WCAG 2.2, the current version of the standard. Several laws still cite 2.1 - the European standard behind the European Accessibility Act, and the US rule for state and local government sites - but 2.2 only adds to it, so a page meeting 2.2 at level AA meets 2.1 as well.

What do automated accessibility checks catch and miss? #

A scanner can decide anything that is a fact about the markup: whether an image has an alt attribute, whether a field has a programmatic label, whether two colours meet a ratio, whether <html> declares a language. It cannot decide anything that needs judgement or interaction.

Caught

Missing alt attributes, unlabelled fields and buttons, low text contrast on solid backgrounds, a missing page language, duplicate IDs referenced by ARIA, invalid ARIA roles and attributes.

Missed

Whether alt text is accurate, whether the focus order makes sense, keyboard traps, whether content survives 400% zoom, contrast over images and gradients, whether a heading actually describes its section.

A clean automated report means nothing it can test is broken. It says nothing about the rest, and the rest is where the failures that lock people out tend to be.

How do you test a website with only a keyboard? #

Click the address bar, then press Tab repeatedly. Shift+Tab goes back, Enter activates links and buttons, Space toggles checkboxes and buttons, arrow keys move within radio groups, menus and tabs, and Escape should close any dialog. At every stop, ask four questions:

1. Can you see where you are? A visible focus indicator on every stop - 2.4.7 Focus Visible.
2. Is the focused element visible at all? Not hidden behind a sticky header or a cookie banner - 2.4.11 Focus Not Obscured (Minimum), new in 2.2.
3. Is the order sensible? Focus should follow the reading order, not jump around the layout - 2.4.3 Focus Order.
4. Can you get out? A modal or an embedded player that holds focus forever fails 2.1.2 No Keyboard Trap.

And one question for the page as a whole: could you do everything with the keyboard that you could with a mouse? Menus that open only on hover and custom controls built from <div> are the usual failures of 2.1.1 Keyboard. A skip link as the first stop, jumping past the navigation, is the common way to meet 2.4.1 Bypass Blocks.

On macOS, Safari moves only between form controls on Tab until Press Tab to highlight each item on a webpage is switched on in its Advanced settings, and Firefox skips links until keyboard navigation is switched on in System Settings. Test in Chrome, or change the setting first, or a working page will look broken.

How do you test zoom and reflow at 400%? #

Make the browser window 1280 CSS pixels wide and zoom to 400%. That leaves a 320px viewport, which is exactly what 1.4.10 Reflow asks for: content readable and usable without scrolling in two directions. Text should wrap, navigation should collapse, and nothing should be cut off or overlap.

• 1.4.4 Resize Text - text enlarged to 200% loses no content or function.
• 1.4.10 Reflow - no horizontal scrolling at 320px, except for content that needs two dimensions, such as data tables, maps and diagrams.
• 1.4.12 Text Spacing - nothing is clipped when line height is 1.5 times the font size, paragraph spacing twice the font size, letter spacing 0.12 times and word spacing 0.16 times.

* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}
p { margin-bottom: 2em !important; }

Fixed-height boxes are what fail. A button or card with a set height and overflow: hidden cuts off the second line of its own label.

What contrast does WCAG 2.2 require? #

1.4.3 - normal text

4.5:1 against its background, at level AA.

1.4.3 - large text

3:1. Large means at least 24px, or about 18.66px when bold.

1.4.11 - non-text

3:1 for the boundaries and states of controls - input borders, focus indicators, toggle states - and for graphics that carry meaning.

In a ten-minute pass, check the four places it fails most: placeholder text, light-grey secondary copy, focus rings on coloured backgrounds, and text over images. The last one is the hardest, and the note on contrast on real backgrounds explains why a two-colour checker gets it wrong.

How do you check headings, landmarks and the page title? #

Screen reader users move through a page by headings and landmarks far more than by reading top to bottom, so the outline is the page's real table of contents. Check that:

• The <title> names the page, not just the site - 2.4.2 Page Titled.
• There is one <h1> describing the page, and the levels below it nest without being chosen for their font size - 1.3.1 Info and Relationships, 2.4.6 Headings and Labels.
• The page has <header>, <nav>, <main> and <footer>, or the equivalent roles, and repeated <nav> elements carry distinguishing labels.
• <html lang> is set to the page's language - 3.1.1 Language of Page.

Firefox's Accessibility panel and Chrome's full-page accessibility tree (in the Elements panel's Accessibility pane) both show the page as assistive software receives it: roles and names, not markup.

How do you check alt text and form labels? #

For images, 1.1.1 Non-text Content asks for a text alternative that serves the same purpose. Read the alt text with the images out of mind and ask whether it carries what the image carries:

• Informative images need alt text that says what matters, not what the file is. A chart's alt text gives the conclusion; a product photo's names the product.
• Decorative images take an empty alt="" so screen readers skip them. A missing attribute is not the same - some screen readers read the file name instead.
• Images inside links or buttons need alt text naming the destination or action, because it is the control's only name.

For forms, click each field's visible label: if the field takes focus, the two are associated. Then check:

• Every field has a persistent visible label - 3.3.2 Labels or Instructions. A placeholder disappears on typing and is not a label.
• Every control has an accessible name - 4.1.2 Name, Role, Value. An icon-only button with no text alternative is announced as just "button".
• Personal-data fields carry autocomplete - 1.3.5 Identify Input Purpose: email, given-name, postal-code and so on.
• Errors are named in text, not only shown in red - 3.3.1 Error Identification.
• Information already entered is not asked for again in the same process - 3.3.7 Redundant Entry, new in 2.2.

What else did WCAG 2.2 add? #

Besides Focus Not Obscured and Redundant Entry above, three new criteria are quick to check on most pages: 2.5.8 Target Size (Minimum) asks for pointer targets of at least 24 by 24 CSS pixels or enough spacing around smaller ones; 2.5.7 Dragging Movements asks for a single-pointer alternative to anything done by dragging; and 3.3.8 Accessible Authentication (Minimum) rules out a login that depends on a cognitive test, such as transcribing a code, without an alternative - pasting into the field and password managers must work. WCAG 2.2 also removed 4.1.1 Parsing as obsolete.

How LoupeKit shortens the manual half #

The A11y tab runs the automated half - an audit that prints the value it measured, contrast against AA, AAA and APCA, and the accessibility tree. The tools below take the parts a scanner cannot do and turn them into readings rather than memory:

• Keyboard walk records a Tab pass and logs each stop with its faults, traps included.
• Focus path draws the tab order over the layout, so a backwards jump is visible at a glance.
• Reflow reads the page at 320 CSS pixels and reports clipping, lost content and a second scroll axis.
• Outline shows landmarks and headings as the tree a screen reader moves through.
• Forms lists every field with its accessible name, its constraints and its autocomplete token.
• Images flags missing alt text alongside the image weight it already measures.

None of them replaces a test with real assistive technology and the people who use it. They replace the resizing, tabbing and remembering - which is most of what a ten-minute check is.