Morten A. Giraffe

Chapter III / Make it responsible

Accessibility Is Evidence the Interface Communicates

Review whether the interface communicates through structure, language, state, and multiple perceivable cues.

All 18 rules4 min read
01Scenario

Start with the moment where the interface asks too much.

The selected state is a small lime dot. It is clear to the designer who chose the color, on the monitor where it was designed, with the intended state already in mind. Remove any one of those conditions and the meaning weakens. The state was not communicated; it was recognized by someone who already knew the answer.

Accessibility is built through structure, language, states, interaction, and testing. Compliance criteria provide a necessary baseline; they do not replace human judgment or disabled-user research.

02Interface Lab

Show the failure and the correction.

The lab uses controlled markup instead of raster text so the lesson stays legible, accessible, and easy to revise.

Annotated screen

Rule 14

123
  1. 1Color-only selected stateThe state vanishes when color perception, display quality, or context changes.
  2. 2Unlabelled controlsThe visual interface has obvious meaning, but assistive technology receives an anonymous button.
  3. 3Broken reflowThe layout passes at one viewport but clips or overlaps when zoomed or translated into mobile constraints.
03Principle

Make the useful path easier.

Semantic foundation first

Native elements, landmarks, headings, labels, and proper control semantics carry a large part of the accessibility load before ARIA is considered.

Multiple cues protect meaning

Important distinctions should not rely on color alone. Use text, shape, icon, state, position, and programmatic meaning where appropriate.

Automated checks are incomplete

Scanners can catch many issues, but keyboard order, focus visibility, screen-reader usefulness, zoom, reflow, and real task success require manual review.

04Rebuild

Turn critique into a usable rule.

Remove

  • Color-only selected state

    The state vanishes when color perception, display quality, or context changes.

  • Unlabelled controls

    The visual interface has obvious meaning, but assistive technology receives an anonymous button.

  • Broken reflow

    The layout passes at one viewport but clips or overlaps when zoomed or translated into mobile constraints.

Build

  • Use semantic HTML

    Start with the native element and role that matches the interaction.

  • Preserve visible focus

    Focus should be obvious, unobscured, and consistent with the visual route.

  • Test beyond tooling

    Keyboard, zoom, reduced motion, contrast, and screen-reader spot checks reveal issues automation misses.

05Field Test

Use it on a real page.

Review one complete task with multiple access paths.

  1. Step 1

    Complete it with keyboard only.

  2. Step 2

    Review at 200 percent zoom and reflow-sensitive widths.

  3. Step 3

    Enable reduced motion.

  4. Step 4

    Spot-check names, roles, values, and status with assistive technology where available.

Evidence
Use manual notes, screenshots, and automated results as supporting evidence.
Pass
The task remains perceivable, operable, understandable, and recoverable.
Fail
The task depends on hover, color alone, hidden focus, clipped content, or unnamed controls.
06Use By Role

The rule should help the person making the next decision.

Business owner

Treat accessibility as product quality and responsibility, not a decorative compliance badge.

Designer

Design states, focus, reflow, labels, and alternatives alongside the visual composition.

Developer

Use native controls, correct labels, status messages, and reduced-motion support.

QA

Record manual blockers, not only automated scan scores.

Accessibility needs can conflict. Do not promise one design works perfectly for everyone. Provide robust semantics, preferences where justified, testing, and a clear way to report barriers.

07Checklist And FAQ

Check the page, then answer the doubt.

  • One clear H1 and logical headings.
  • Landmarks and native controls are used.
  • Keyboard order follows the task.
  • Focus is visible.
  • Color is not the only cue.
  • Text reflows under zoom.
  • Reduced motion is respected.
  • Errors and status messages are usable.
Is WCAG compliance the same as good accessibility?
No. WCAG is a necessary baseline for conformance-sensitive work, but real accessibility also needs judgment, testing, and user context.
Can accessibility and visual design coexist?
Yes. The strongest visual systems make structure, state, and meaning clearer instead of hiding them.
What tests should every website run?
Keyboard, focus, zoom/reflow, contrast, reduced motion, labels, status, and a scanner as supporting evidence.