Intro: a real-life situation

Imagine a small community clinic that takes appointments online. Staff have noticed many last-minute phone calls asking for help booking, and a local volunteer who uses a keyboard and screen reader offered to help. The clinic website team wants to be more inclusive but lacks time and a formal accessibility consultant. This article shows how a staff member or volunteer can run quick, ethical accessibility usability testing of the clinic’s appointment booking page focused on keyboard navigation, form labels, zoom, error states and a few screen-reader spot checks — and do so without claiming formal WCAG certification.

Plan the test: consent, scope and quick logistics

Before testing, get consent from the site owner and from any participants. Concrete plan for the clinic:

  • Scope: single page — appointment booking form and confirmation flow.
  • Participants: 1 staff observer, 1 volunteer who uses assistive tech (if available), and optionally 2 non-disabled users for comparison.
  • Timebox: 45–60 minutes for the walkthrough, plus 30 minutes to write findings and suggested fixes.
  • Rules: no changes on production during testing; record notes not audio/video unless participants consent explicitly.

Five practical spot checks (what to do)

Run these checks in this order; they are simple, repeatable and require minimal tooling.

1. Keyboard navigation

Use Tab, Shift+Tab, Enter, Space and arrow keys only. Goal: every interactive element must be reachable and usable without a mouse.

  • Start at page top. Press Tab repeatedly. Does focus move in a logical order that matches visual layout?
  • Are hidden elements skipped? Modals should trap focus while open and return focus afterwards.
  • Can you pick a date, time slot, and submit the form with only keyboard? If not, note which control failed.

2. Form labels, instructions and focus visibility

Check that inputs have readable labels and any instructions are visible when needed.

  • Look for explicit label text associated to fields (visually and programmatically). Without a label, users of screen readers won’t know the field purpose.
  • Place keyboard focus on each input: is the focused element clearly visible (high-contrast outline) and does an on-focus helper appear for complex fields like “reason for visit”?

3. Zoom and reflow

Zoom to 200% in the browser and confirm the page remains usable without horizontal scrolling where possible.

  • For the booking form, check that labels and fields remain readable and the submit button remains visible.
  • If a two-column layout collapses, ensure content stacks in a logical reading order.

4. Error-state checks

Intentionally submit incomplete or invalid input to see how the page responds.

  • Do error messages appear near the field and describe how to fix the error? Example: “Enter a valid date in DD/MM/YYYY format.”
  • After an error, can you navigate to the field via keyboard and is focus moved to the first error?
  • Confirm success/failure responses are announced to screen readers (see next section).

5. Screen-reader spot checks (with consent)

If you have a volunteer who uses a screen reader or can simulate one, do a brief read-through of key elements. Common screen readers: NVDA for Windows, VoiceOver for macOS/iOS.

  • Ask the user to attempt a booking and note where the experience breaks or is slow.
  • Check that field labels are announced, and that the screen reader announces changes like “appointment confirmed” or “error: required field.”

Worked example: one-hour clinic test session

Scenario: volunteer Anna (uses keyboard + NVDA) and admin Ben (tester). Steps and timing:

  • 0–5 min: consent and scope review.
  • 5–20 min: Ben performs keyboard navigation and labels check, taking notes.
  • 20–35 min: Anna repeats with NVDA, attempting to book a sample appointment and reporting readouts.
  • 35–45 min: Error-state testing — Ben triggers common invalid inputs while Anna verifies announcements.
  • 45–60 min: Quick debrief and create an action list.

Concrete outcome: they found that the date picker required a mouse; a simple fix was to add a keyboard-accessible input fallback and an aria-describedby note. The team estimated the change as one day of developer work.

Checklist / mini-template to reuse

Use this checklist to run future tests. Mark pass/fail and add notes.

Appointment booking accessibility checklist
- Test date: ______   Tester: ______
- Consent obtained from site owner and participants: Yes / No
1) Keyboard navigation: PASS / FAIL  Notes: ______
2) Labels & instructions (programmatic): PASS / FAIL  Notes: ______
3) Focus visibility: PASS / FAIL  Notes: ______
4) Zoom behaviour at 200%: PASS / FAIL  Notes: ______
5) Error messages & focus on error: PASS / FAIL  Notes: ______
6) Screen-reader spot check: PASS / FAIL  Notes: ______
Suggested fixes & priority (low/med/high): ______
Estimated developer time: ______

Common mistakes and constrained-resource variations

Typical errors:

  • Visual labels that are not linked to inputs (label without for/id).
  • Custom date pickers that discard a keyboard-accessible input fallback.
  • Error messages only shown visually and not announced to assistive tech.

Low-budget testing options:

  • If you cannot recruit assistive-tech users, use browser-only checks and a free screen reader (NVDA) for spot checks.
  • Use a recorded live session with a colleague in a different role to simulate step pressure (time-limited booking).
  • Prioritize fixes that cost little but improve many users: add labels, ensure keyboard focus, add clear inline error text.

Sources and scope

This article provides practical, non-certified usability testing steps focused on appointment booking workflows. It does not provide formal WCAG conformance statements or legal advice. No external reference links are required to follow these checks, though developers may consult accessibility guidelines directly for technical rules. For a beginner-friendly starting point to accessibility learning, see our guide: Start here.

Use findings as actionable input for developers and accessibility professionals. When in doubt, engage a certified auditor for conformance testing.

Related Posts

Scroll to Top