Security and Accessibility

Build Accessibility into the Working Slice

Design keyboard, screen-reader, contrast, form, error, caption, and testing needs into the first version.

Build stage · Module 9 of 15

Outcome for this lesson

Make the working slice usable with keyboard, screen reader, zoom, reflow, labels, errors, and non-color cues.

Bring forward: Bring the working thin slice and its acceptance tests from Module 8.

Produce: An accessibility test record with failures found, changes made, remaining limits, and retest evidence.

0 of 15 core modules complete

Progress is saved on this browser. Create a free membership to sync across devices.

Recommended prerequisite: complete Module 8, “Build and Verify the First Useful Slice,” and bring its artifact. You may still use this page as a reference.

Build stage

Build the next result

Accessibility is part of the result, not a later decoration. Test the same working journey through keyboard, assistive technology, zoom, reflow, labels, and recovery.

Your result for this module

An accessibility test record with failures found, changes made, remaining limits, and retest evidence.

Continuous case study

Worked example: Repairing the tracker form

The first version uses placeholder-only labels, a red border for errors, and a custom clickable card. The repair adds persistent labels, text errors associated with fields, a real button, visible focus, logical order, and a summary that moves focus to the problem.

Do the work

  1. Complete the journey without a mouse

    Record focus order, visible focus, control names, activation, and recovery.

  2. Check structure with a screen reader

    Confirm headings, landmarks, labels, buttons, status messages, and reading order.

  3. Test zoom and reflow

    Use large text, narrow width, and touch-sized controls without hiding essential actions.

  4. Record automated and human findings separately

    Automated tools can find patterns; manual and disabled-user testing reveal interaction problems they cannot.

Copy-and-complete template

Create your module artifact

Journey tested:

Keyboard findings:

Screen-reader findings:

Zoom and reflow findings:

Automated findings:

Changes made:

Remaining limits and owner:

Retest evidence:

Keep sensitive information, passwords, API keys, payment data, and private customer details out of course notes and AI prompts.

Quality gate

Check the result before the quiz

  • Every control is keyboard operable.
  • Labels and errors are programmatically connected.
  • Meaning is not conveyed by color alone.
  • Remaining limitations are visible and owned.

How this moves the project forward

Module 10 uses the same working system to reduce privacy and security exposure.

Evidence checkpoint and lesson summary

Confirm the artifact, then answer the key questions

The questions cover a core idea, a realistic decision, and evidence from the lesson. Incorrect answers identify concepts to review; they are not a complete measure of your experience or ability.

Artifact checkpoint

This is an honest self-check. Do not enter private data here; keep the artifact in your own approved workspace.

1. A control can receive focus but pressing Enter does nothing. What does that show?
2. Which error treatment is accessible?
3. Which test record supports completion?

Confirm the artifact and answer all three questions correctly to unlock the recommended next step.

About the author

Son Kim

Son Kim writes from first-hand experience as a blind AI user. He tests vibe-coding tools, models, plugins, connected hardware, and everyday AI workflows to document what improves accessibility, independence, productivity, earning opportunities, problem-solving, and quality of life—and what still requires human judgment.

Read the full author background

Review the editorial, correction, advertising, and affiliate standards