Authority lesson · 818 words
Accessibility Testing as an Engineering Workflow
Start with tasks and semantics
Accessibility testing begins by naming what a person must accomplish: understand the page structure, open navigation, complete a form, recover from an error, read a table, play media, or download a resource. Use native HTML elements and relationships so browsers and assistive technologies receive the same structure. Headings, labels, landmarks, buttons, links, fieldsets, tables, and status messages should match their actual purpose before ARIA is considered.
Review source order without CSS. Visual rearrangement must not create a confusing keyboard or reading sequence. Ensure names, roles, values, instructions, and error relationships are programmatically available. Do not rely on colour, position, hover, or placeholder text as the only information. Real content, long labels, zoom, translation, and validation errors are part of the interface, not edge cases.
Combine automated and human checks
Automated tools quickly detect missing labels, duplicate IDs, some contrast failures, invalid relationships, and common ARIA errors. They cannot decide whether alternative text communicates the image’s purpose, whether focus order matches the task, whether instructions are understandable, or whether a custom interaction is usable. Use automation as a regression layer, not a certification claim.
Perform keyboard testing for every interactive path: Tab and Shift+Tab order, Enter and Space activation, arrow-key patterns where appropriate, visible focus, escape and close behaviour, and focus restoration after dialogs. Test at high zoom and narrow widths. Check reflow, clipping, horizontal scrolling, and content that appears only on hover. Use at least one screen reader on each supported platform for critical journeys, while remembering that one combination does not represent every user.
Forms need error architecture
A form must identify required fields, provide persistent instructions, use suitable input types and autocomplete attributes, and preserve entered values after validation. When submission fails, present a summary linked to fields, place clear inline messages near each control, and move focus only in a predictable way. Errors should state the problem and how to fix it. Do not disable submission without explaining unmet conditions.
Dynamic validation should not announce every keystroke. Use polite status updates at meaningful moments. Time limits, session expiry, and destructive actions require warning and recovery. Test with password managers, autofill, copy and paste, and speech input. Security rules that block these tools can make accounts less usable and push users toward weaker practices.
Make accessibility part of release evidence
Define supported browser and assistive-technology combinations and critical journeys. Run HTML validation, automated accessibility checks, keyboard scripts, visual regression, and manual review before release. Record findings with the affected task, user impact, standard reference, evidence, and remediation owner. Retest the actual fix and nearby patterns.
Build accessible components into the design system, but do not assume reuse guarantees correctness. Context, labels, content, and composition can break an accessible primitive. Include accessibility acceptance criteria in stories and review new interaction patterns before they spread. Public statements should describe the work completed and known limitations rather than claiming complete compliance without an appropriate audit.
Scenario
A polished modal traps no one—and helps no one
A custom modal looks correct with a mouse but focus remains behind it, Escape does nothing, the close icon has no accessible name, and closing loses the user’s previous position. Use the native dialog element where supported or implement the complete pattern: labelled dialog, controlled focus entry, contained navigation, Escape, explicit close, background inertness, and focus restoration.
- Prefer native semantics
- Test keyboard and screen-reader behaviour
- Restore focus to the triggering control
- Add regression checks for repeated openings
Worked example
Evaluate a public contact form
- Inspect heading, landmark, label, instruction, autocomplete, and error relationships.
- Complete it with keyboard only at 200 and 400 per cent zoom.
- Run an automated checker and HTML validator.
- Submit empty and invalid values; verify summary links, preserved data, and focus.
- Use a screen reader to confirm labels, errors, status, and success message.
Checklist
Use this before acting
- Define critical user tasks
- Use native semantics before ARIA
- Check source and focus order
- Run automated checks without treating them as complete
- Test keyboard, zoom, reflow, and high-content states
- Review critical journeys with assistive technology
- Build clear form-error architecture
- Retest fixes and retain evidence
Common mistakes
Failure patterns to avoid
- Treating an automated score as accessibility certification
- Adding ARIA to replace correct HTML
- Testing only with a mouse
- Using placeholder text as the label
- Moving focus without warning
- Claiming compliance without scoped evidence
Practical exercise
Create an accessibility release check
Choose one critical public journey. Document semantics, keyboard steps, zoom and reflow checks, automated findings, one screen-reader pass, form errors, and known limitations. Add at least one automated regression and one manual release criterion.
Deliverable: A repeatable accessibility test script and evidence record.
Sources and further reading
Primary and official references
Topic-specific takeaway
Accessibility quality comes from semantic design plus repeated human and automated verification of real tasks, not from a one-time scanner score.
