Skip to main content

WCAG Accessibility as Verifiable Quality

What This Concept Is​

Accessibility is the property that people with diverse visual, auditory, physical, speech, cognitive, language, learning, and neurological needs can perceive, operate, understand, and robustly use a system. WCAG 2.2 expresses web accessibility through testable success criteria rather than aesthetic preference.

Why It Matters Here​

Accessibility is a design, implementation, and review concern. Semantic structure affects assistive technology; keyboard and focus behavior affect operation; errors and labels affect understanding; component contracts affect whether accessibility survives refactoring. It therefore belongs in the same evidence loop as correctness, tests, and code review.

Concrete Example​

A custom clickable div opens a dialog with a mouse. Keyboard users cannot reach it, the control has no accessible name, focus remains behind the dialog, and Escape does nothing. Replace it with a semantic button, name the dialog, move focus inside on open, constrain the focus cycle, close on Escape, and restore focus to the trigger. Verify with keyboard-only use and a screen reader; a linter alone cannot prove the interaction.

Common Confusion / Misconception​

Passing an automated scanner does not establish accessibility. Automation detects a useful subset of failures. Keyboard testing, screen-reader inspection, zoom/reflow checks, motion and contrast review, and human task testing remain necessary.

How To Use It​

  1. Prefer native semantic elements before adding ARIA.
  2. Verify meaningful structure, names, relationships, and error messages.
  3. Complete every task with only a keyboard and visible focus.
  4. Test zoom and reflow without losing content or operation.
  5. Run automated checks, then manually inspect high-risk interactions.
  6. Record each applicable WCAG 2.2 criterion, evidence, failure, and remediation.

Check Yourself​

  • Can every interactive element be reached and operated without a pointer?
  • Does focus move predictably through dialogs, errors, and dynamic updates?
  • Can you point to manual evidence in addition to automated output?

Mini Drill or Application​

Audit one complete Semester 3 project flow. Capture keyboard order, accessible names, form errors, contrast, zoom/reflow, and one screen-reader pass. Repair the highest-impact failure and preserve before/after evidence.

Read This Only If Stuck​

  • Good Code, Bad Code is the local source backbone for maintainable contracts and verification.
  • WCAG 2.2 is the normative accessibility source; use the criterion number in the audit rather than a generic “accessible” claim.