01 | USABLE MEANS MORE THAN ATTRACTIVE

A page can look polished and still be difficult to use. A learner may navigate with a keyboard, enlarge text, use a screen reader or need a clearer colour contrast.

Accessibility helps people with different abilities and access needs use content. Usability concerns how effectively and comfortably people achieve their goals. They overlap, but one does not automatically guarantee the other.

Build on meaningful HTML, clear labels and responsive layouts. Then test actual tasks rather than assuming the appearance proves the page works.

02 | FOLLOW KEYBOARD FOCUS

Focus identifies the element receiving keyboard input. Tab and Shift+Tab usually move through focusable controls in source order. Links activate with Enter; native buttons support Enter and Space.

Native radio groups and select menus have their own keyboard behaviour. Not every control is operated by repeatedly pressing Tab, so preserve the browser’s expected interactions.

1. Open the page and stop using the mouse.
2. Move through links and controls.
3. Check that focus stays visible.
4. Activate each important action.
5. Check that you can leave each component and continue.

A keyboard trap prevents users from moving out of a component. Complex widgets require careful focus management; begin with native controls.

03 | KEEP A VISIBLE FOCUS INDICATOR

a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible {
  outline: 3px solid #176c65;
  outline-offset: 3px;
}

:focus-visible matches focused elements when the browser determines that a visible indicator is appropriate, commonly during keyboard navigation. It is not simply a rule that “only applies to Tab”.

Do not remove the browser’s outline unless you provide a suitable replacement. Hover styling alone is not a keyboard focus indicator.

Ensure the indicator can be seen against surrounding colours and is not clipped by containers or covered by fixed headers. An outline generally does not consume layout space like a border.

04 | USE NATIVE CONTROLS AND LOGICAL ORDER

<a href="projects.html">Explore our projects</a>
<button type="button">Reveal project details</button>

Use links for destinations and buttons for actions. Native elements provide semantics and keyboard behaviour that a clickable div does not have automatically.

Keep the HTML order logical. Grid placement, Flexbox order and reversed directions can change visual order while reading and sequential keyboard navigation still follow the source.

Avoid positive tabindex values that force a custom sequence. tabindex="-1" can make a target focusable without adding it to the ordinary Tab order. Adding tabindex="0" to every paragraph is unnecessary and makes navigation tiring.

05 | SKIP REPEATED CONTENT

<a class="skip-link" href="#main-content">Skip to main content</a>
<header>
  <nav aria-label="Main navigation">
    <a href="index.html">Home</a>
    <a href="projects.html">Projects</a>
  </nav>
</header>
<main id="main-content" tabindex="-1">
  <h1>Our projects</h1>
</main>

A skip link lets people bypass repeated navigation. Keep it visible in your first version. If you later hide it visually until focus, it must still become clearly available and usable.

Descriptive link text, meaningful headings and page landmarks help users find information. Do not replace these structures with visual boxes that only look like sections.

06 | CHECK TEXT CONTRAST

Contrast ratio compares the relative luminance of two colours. A higher ratio generally means a greater light-dark difference, but readability also depends on size, font and spacing.

Under WCAG AA text contrast rules, ordinary text needs at least 4.5:1. Qualifying large text needs at least 3:1. Large text means at least 18pt, or 14pt when bold, approximately 24 CSS pixels or 18.67 CSS pixels respectively.

These thresholds have exceptions, including some incidental text and logotypes. Use them as a practical foundation, and review the applicable requirement when evaluating a real page.

Measure the rendered foreground and background, including relevant transparency or images. A passing text ratio does not prove that controls, focus indicators or the whole page are accessible.

07 | TRY IT: COMPARE SOLID COLOURS

Select opaque foreground and background colours. This checker calculates their contrast ratio and reports whether the pair meets the AA thresholds for ordinary and qualifying large text.

08 | DON’T RELY ONLY ON COLOUR OR HOVER

A red border alone may not explain which field needs correction. Pair colour with text such as “Enter a whole number from 1 to 6”. Keep useful descriptions associated with controls.

Touch users may not have a convenient hover interaction. Important instructions and actions must remain discoverable without hovering. Buttons and links should have clear labels and comfortable target spacing.

Do not use an unexplained icon as the only label for an important action. A short descriptive word or accessible name can clarify its purpose.

Use consistent navigation wording and predictable actions. For example, a button labelled “Download workbook” should not unexpectedly open a subscription signup instead.

09 | ENLARGED TEXT, ERRORS AND FEEDBACK

Test enlarged text and narrow layouts together. Avoid unnecessary fixed heights, clipped controls and disabled zoom. Keep essential content available as it reflows.

For forms, provide associated labels, visible requirements, helpful errors and preserved valid entries. A custom error summary can guide people back to fields needing correction.

Changes such as a score or successful check should be communicated through suitable feedback. role="status" can support polite announcements for short updates. Do not flood users with an announcement on every keystroke.

Opening a modal or implementing a custom menu adds focus-management responsibilities. Native HTML and simple interactions are a good starting point.

10 | TEST A REAL TASK

Ask a partner to find a project, reach the joining instructions and complete a practice form. Observe where they hesitate or lose focus, then make a specific improvement.

• Keyboard: can all important controls be reached, used and left?
• Focus: is the current control visible and unobscured?
• Structure: do titles, headings and landmarks describe the content?
• Contrast: are the actual text/background pairs suitable?
• Reflow: does enlarged text remain usable on a narrow layout?
• Feedback: are errors and results understandable?

Automated checkers can identify some issues, but manual testing and feedback from users remain essential. This lesson’s checklist is not a claim of complete WCAG compliance.