Manual Accessibility Checks You Can Do Today

Most accessibility failures in real products are caught by six manual checks that take roughly fifteen minutes per screen and require zero specialist tools. Master these six and you will catch the majority of the bugs that automated scanners miss — exactly the bugs that matter most to real users. This lesson walks through each check on a typical login page.

The six-check audit

The six checks form a sequence: keyboard, zoom, contrast, headings, forms, images. Run them in this order on every screen you test. The whole audit takes 10–15 minutes once practised.

1. The keyboard-only test

Unplug your mouse and use the page with only Tab, Shift+Tab, Enter, Space, Escape, and the arrow keys. The keyboard is the universal common ground for nearly every assistive technology — if a page is fully keyboard-operable, it is usable for the largest set of disabled users. Watch for three failure modes: unreachable controls (Tab skips a custom button), invisible focus (Tab moves but you cannot see where), and keyboard traps (focus enters a widget and cannot escape — a Level A failure).

2. The zoom test

Zoom to 200% (Ctrl/Cmd + until the indicator reads 200%). The page should remain fully usable — content reflows, nothing is cut off, no functionality disappears. The most common failure is a fixed-width sidebar that pushes main content off-screen. Many low-vision users browse at 200%+ permanently; a page that fails this is not "a bit cramped" — it is unusable.

3. The colour contrast test

Use a contrast checker (WebAIM Contrast Checker is free; browser extensions like axe DevTools include one built in) on every text element on the page. The thresholds are:

• Body text: 4.5:1 minimum.
• Large text (18pt+ regular, 14pt+ bold): 3:1 minimum.

Then check the second half of the rule: colour alone must not convey information. The classic violation is a form that highlights an error in red, with no other indicator. A red-green colour-blind user — about 8% of men — sees identical colours and never realises the field is in an error state. The fix is to add an icon, a label, or a textual cue alongside the colour.

4. The heading hierarchy test

Open Chrome DevTools (or use the HeadingsMap extension) and look at the document's headings. Two rules:

• Exactly one <h1> per page, naming what the page is about.
• No skipped levels. <h1> may be followed by <h2>; <h2> by <h3>; never <h1> directly to <h3>.

Screen reader users navigate by jumping through headings — pressing H in NVDA or VoiceOver moves to the next heading. A page with broken hierarchy is dramatically harder to navigate, in the same way that a 200-page book without chapter numbers is harder to read.

5. The form test

For every input on the page, verify two things:

• Visible, persistent label. Placeholder text disappears the moment the user starts typing — and screen readers may not announce it. Every input needs a real <label> element associated with it.
• Useful error messages. When the form errors, the message must (a) identify which field is wrong, (b) explain what to fix, and (c) be associated with the input via aria-describedby or a similar mechanism so screen readers announce it on focus.

A login form that says "Please correct the errors below" without naming the fields fails this check.

6. The image test

For every image on the page, examine its alt attribute (right-click → Inspect, or use an alt-text browser extension):

• Informative images (a chart, a product photo, a logo with text) must have descriptive alt text. "Confirmation green tick" is better than "image1.png."
• Decorative images (background flourishes, dividers, purely visual flair) must have alt="". An empty alt tells screen readers "skip this." Missing the attribute entirely makes the screen reader read the file path, which is far worse than skipping.

Quick test: in DevTools' Network tab, block all image requests and reload. The page becomes a sequence of alt strings. Read it aloud. Does it still make sense?

A worked example: the login page

A typical login page audit takes 12 minutes:

• Keyboard: Tab through every control. All reachable, focus visible, Enter submits. Pass.
• Zoom: at 200% the form remains centred and the checkbox label wraps cleanly. Pass.
• Contrast: "Forgot password?" link is #9CA3AF on white — 2.6:1. Fail (needs at least 4.5:1).
• Headings: one <h1> "Sign in." Pass.
• Forms: error message "Invalid credentials" does not name the offending field. Partial fail.
• Images: decorative header pattern has no alt at all. Partial fail (should be alt="").

Twelve minutes; three real bugs. None caught by the team's automated Lighthouse scan.

⚠️ Common mistakes

• Skipping the keyboard check on screens that "obviously" work. Custom dropdowns, modals, and date pickers fail keyboard testing far more often than basic forms. Always run the test, even when you are sure.
• Treating contrast as a designer-only concern. The visible designer file shows the colours. The rendered page is where contrast lives, and CSS overrides, hover states, and disabled states routinely differ from the design.
• Reading alt text without rendering it. "Looks fine in the inspector" does not equal "useful when read aloud." Block images and read the page text-only at least once for any screen with significant imagery.

🎯 Practice task

Spend 30 minutes running the full six-check audit on a real screen.

1. Pick a single page with at least one form and several images — your bank's login screen, a checkout, a contact form.
2. Run all six checks in order. Time yourself.
3. For each check, write pass / partial / fail with one sentence of evidence.
4. Pick the most serious failure you found and draft a bug report — title, environment, repro steps, expected vs actual, and the WCAG criterion it violates.
5. Save the audit. Run it on every new screen you test for the next month. By week four, the six checks will become automatic — exactly what they should be.