Learn the idea.
Put it into practice.

Keyboard focus identifies the control that will receive the next action. A visible indicator helps people follow their place while tabbing, using alternative keyboards or operating through other keyboard interfaces. A control that works but cannot be located is still a barrier.

By the end: Track focus through a short task and recognise when page content hides it.

button:focus { outline: none; }

button:focus-visible {
  outline: 3px solid var(--focus-colour);
  outline-offset: 3px;
}
/* Check the ring against adjacent colours. */

Keep in mind: Focus styling is not exclusively for keyboard hardware. The browser can also show it in other situations; do not force it off just because a pointer was used.

A button performs an action, such as saving a preference or opening a panel. A link navigates to a destination. Using a native button provides useful role and keyboard behaviour, while a clickable generic element requires those behaviours to be implemented and tested.

By the end: Recognise the difference between an action and navigation, then operate an action without a pointer.

<div onclick="addItem()">Add item</div>

<button type="button" id="add-item">Add item</button>
<!-- Attach the action to the button’s click event. -->

Keep in mind: Adding role='button' describes a role to assistive technology; it does not automatically add focusability, keyboard activation or the action itself.

A form needs to explain what each input is for before a person types and while they correct an error. Persistent visible labels support sighted users; programmatic associations let assistive technology identify the same fields. Error text should explain what needs attention.

By the end: Complete and correct a short form without losing the field's purpose or your previous work.

<input placeholder="Email">
<!-- A red border is the only error indication. -->

<label for="email">Email (required)</label>
<input id="email" type="email" required
  aria-describedby="email-help email-error">
<p id="email-help">For example, [email protected].</p>
<p id="email-error"></p>
<!-- On error: explain the correction and set aria-invalid. -->

Keep in mind: A placeholder is not a reliable replacement for a persistent label. Giving a field an accessible name alone also does not provide every visible instruction a user may need.

Contrast compares foreground and background brightness. It helps determine whether text or an important visual cue is distinguishable, but a ratio does not measure every aspect of readability. Test the actual colours and states people encounter, including text shown over images or tinted surfaces.

By the end: Choose a suitable threshold and improve a sample without relying on visual judgement alone.

/* Judging readability from colour names alone. */
color: grey; background: white;

/* Measure the actual rendered colours. */
/* Normal text at AA: at least 4.5:1. */
/* Large text at AA: at least 3:1. */
/* Large: 18pt, or 14pt bold (normally 24px / 18.67px). */

Keep in mind: A passing ratio does not make tiny, thin or crowded text easy for everyone to read. Keep size, spacing and clear presentation in the review.

The same image can inform, decorate or operate a control in different contexts. Its text alternative should serve that particular job. A product photograph, a decorative divider and an image-only link therefore need different decisions, even when the files look equally detailed.

By the end: Choose between meaningful alternative text, an empty alternative and a fuller description.

Try this

1. Read the surrounding content and decide what the image contributes to this task.
2. Compare the proposed alternatives. Keep information needed here; remove repeated detail or visual description that does not serve the purpose.
3. Check the result in context: describe the action for a functional image, and provide longer information nearby when a short alternative cannot carry it.

What to look for: An informative image has a useful equivalent; a purely decorative image can use alt=''. An image-only control needs an accessible name for its action. A complex chart may need both a short alternative and accessible detailed information. The right choice depends on the page, not a fixed word count.

Practice example

<img src="workshop.svg" alt="image">

<!-- Choose the alternative from purpose and context. -->
<img src="workshop.svg"
  alt="Workshop: 18 September at 10:00.">
<!-- If equivalent text is already nearby: alt="". -->

Keep in mind: Screen readers do not read every image identically. Output depends on markup, context, software and settings; missing alt does not guarantee one particular filename announcement.

People select controls with fingers, mice, pens and other pointing devices. The active area can be larger than the visible icon. Generous targets reduce precision demands, while the gap between neighbouring targets helps prevent selecting the wrong action.

By the end: Evaluate the clickable area and spacing instead of measuring only the picture inside a control.

/* A tiny hit area, crowded by other controls. */
.icon { width: 12px; height: 12px; }

/* A generous target can contain a smaller icon. */
.control { min-width: 44px; min-height: 44px; }
/* WCAG 2.5.8 AA has a 24px rule plus permitted
   spacing and other exceptions; inspect the full criterion. */

Keep in mind: A 20px target is not automatically a WCAG failure: an exception may apply. Conversely, meeting a minimum does not guarantee that a control is comfortable for every person.

A person may scan a page visually or navigate a list of links with assistive technology. Useful link text reduces the work needed to predict a destination. Repeated phrases such as 'Read more' deserve a context check, rather than an automatic pass or fail.

By the end: Rewrite a link so its purpose is clear, and recognise when surrounding context is sufficient.

<a href="media-guide.html">Click here</a>

<a href="media-guide.html">
  Captions, transcripts and description guide
</a>

Keep in mind: Every occurrence of 'click here' is not automatically a 2.4.4 failure. Context matters, although more descriptive wording usually makes the link easier to use.

Headings explain how content is organised and help people move between sections. A large bold paragraph may look like a heading while remaining ordinary text to software. Semantic heading levels should represent the content's relationships, with visual styling handled separately.

By the end: Create an outline that describes both the page's topics and their hierarchy.

<p class="large-bold">Arrival</p>

<section aria-labelledby="arrival">
  <h2 id="arrival">Arrival</h2>
  <p>Describe the entrance and route.</p>
</section>
<!-- Choose levels from the page hierarchy. -->

Keep in mind: Returning from h3 to h2 is normal when a subsection ends and a new main section begins. Heading numbers are a hierarchy, not a sequence that must always increase.

A symbol can have different meanings in different places: a magnifier may search or enlarge an image. An icon button needs an accessible name that identifies its actual action. Visible text also helps people who do not recognise the symbol.

By the end: Compare a control's purpose with its accessible name and remove ambiguity.

<button><svg><!-- bookmark shape --></svg></button>

<button type="button" aria-pressed="false">
  <svg aria-hidden="true"><!-- bookmark --></svg>
  <span class="sr-only">Save example</span>
</button>

Keep in mind: An emoji is not automatically hidden from assistive technology. It may contribute a name, but that name may not explain the action. Adding aria-label to every button is unnecessary when good text already supplies the name.

A modal dialog temporarily makes the surrounding page unavailable while a person completes or dismisses a task. Keyboard focus should enter the dialog, remain in its interaction sequence while open, and reach a sensible place when it closes.

By the end: Test opening, navigating and dismissing a modal without losing your place.

<div class="looks-like-a-modal">
  <!-- The page behind it remains interactive. -->
</div>

<dialog id="plan" aria-labelledby="plan-title">
  <h2 id="plan-title">Plan name</h2>
  <form method="dialog"><button>Close</button></form>
</dialog>
<script>plan.showModal();</script>
<!-- Review initial focus and focus after closing. -->

Keep in mind: Keeping Tab inside an open modal is not automatically a prohibited keyboard trap: there must be a keyboard-operable way to leave. Non-modal panels should not inherit this behaviour indiscriminately.

People who enlarge content need more than bigger letters: the surrounding layout must remain usable. Fixed-width cards, clipped buttons and large sticky panels can hide information or require repeated sideways scrolling. Reflow lets content reorganise while preserving the task.

By the end: Check a narrow layout for missing content, lost functions and unnecessary two-dimensional scrolling.

.card { width: 900px; height: 180px; overflow: hidden; }

.card { width: 100%; max-width: 40rem; }
.card p { overflow-wrap: anywhere; }
/* Allow content to grow; review zoom and reflow separately. */

Keep in mind: Reflow does not mean shrinking the whole page until everything fits. It also does not mean hiding needed information. A table's exception does not exempt the whole page.

An action can update a page without opening a new page or moving focus. A short message such as a saved-state confirmation or result count may be visible while going unnoticed by someone using assistive technology. Status semantics make that change available without forcing a new location.

By the end: Recognise a status message and keep its feedback separate from focus movement.

result.textContent = "3 results";
// No way to announce the update without moving focus.

<p id="result" role="status"></p>
<!-- Create the empty region before the update. -->
<script>
  result.textContent = "3 practice resources available.";
</script>

Keep in mind: Not every inserted element needs a live region. Search results themselves are content; a short results-count message may be a status. More announcements can make an interface harder to follow.

Motion may help show a change, but extra movement can distract people or trigger discomfort. A reduced-motion option should preserve the information and function. Different WCAG criteria cover interaction-triggered animation, automatically moving information and flashing; they are not interchangeable.

By the end: Choose a static alternative and distinguish a lasting pause from a temporary hover effect.

.indicator { animation: slide 2s infinite; }
/* Starts without asking and offers no stop control. */

/* Start only on request, and provide a stop control. */
@media (prefers-reduced-motion: reduce) {
  .indicator { animation: none; }
}

Keep in mind: Stopping movement only while a pointer hovers or keyboard focus stays on it is not a usable persistent pause. A pause button also does not make unsafe flashing acceptable.

An accessible media plan starts with the information in each channel. Captions provide speech and meaningful sound in text. Audio description conveys important visual information that is not available from the soundtrack. A transcript offers another way to read and navigate the content.

By the end: Identify which information a sample clip communicates through audio, visuals or both.

Captions: "Welcome."
// Necessary sounds and essential visual information omitted.

Captions: [Bell rings] HOST: Welcome.
Description: A sign points left to the step-free entrance.
// Check synchronization, accuracy and the complete media task.

Keep in mind: Unreviewed automatic captions are not dependable evidence that the content is accurately captioned. Spoken-word accuracy, meaningful sounds, speaker identification and timing all need appropriate review.

Instructions should identify the control or information needed for a task, and explain unusual requirements before errors occur. Colour, shape, sound and position can be helpful extra cues, but people must not depend on those cues alone to understand what to do.

By the end: Rewrite a vague direction using a control's name and the information needed for the next step.

Use the green option on the right.

Choose “Morning session” from the Session list.
Then select “Send booking”.

Keep in mind: Accessibility does not ban every mention of shape or position. Supplement those clues with information that identifies the control without relying on the clue alone.

Remembering credentials, solving puzzles or transcribing a code can block people from signing in. WCAG 3.3.8 AA addresses cognitive tests at each authentication step. Useful support includes password-manager compatibility and copy-and-paste, or an alternative method that avoids the test.

By the end: Examine a sample sign-in flow for avoidable memory and transcription demands.

<input onpaste="return false">
<!-- Requires the person to remember and retype the code. -->

<label for="code">One-time code</label>
<input id="code" type="text" inputmode="numeric"
  autocomplete="one-time-code">
<!-- Permit paste; assess every authentication step. -->

Keep in mind: Passwords are not forbidden by WCAG. The issue is an unsupported cognitive test. A successful demonstration is also not a review of an actual account's authentication security.