Accessible design for everyone: disabilities, WCAG, semantic HTML, keyboard use, screen readers, forms, media and testing

Accessibility (a11y) means designing websites and apps that everyone can use, including people who are blind or have low vision, are deaf or hard of hearing, have motor impairments (using a keyboard, switch or voice instead of a mouse), have cognitive or learning disabilities, or are older. It also helps everyone in temporary or situational limits: a broken arm, bright sunlight on a phone, a noisy matatu, a slow connection. Accessible sites reach more customers, rank better (many accessibility practices overlap with SEO), and reduce legal risk. Kenya's Constitution and disability laws, and international standards like WCAG, all point toward inclusive digital services.

Who benefits

WCAG: the standard

The Web Content Accessibility Guidelines (WCAG, by the W3C) define success criteria grouped under four principles, POUR:

Levels: A (minimum), AA (the common target for organisations and many laws), AAA (highest). Aim for WCAG 2.2 AA.

Semantic HTML: the foundation

Use elements for their meaning; browsers and screen readers understand them automatically:

<header style="font-family:system-ui"><a href="#main" class="skip">Skip to main content</a>
  <nav aria-label="Main"><a href="/">Home</a> · <a href="/services">Services</a> · <a href="/contact">Contact</a></nav>
</header>
<main id="main" style="font-family:system-ui">
  <h1>Website design in Nairobi</h1>
  <h2>Our packages</h2>
  <ul><li>Starter website</li><li>Online shop</li></ul>
  <button type="button">Get a quote</button>
</main>
<style>
  .skip { position: absolute; left: -999px; }
  .skip:focus { left: 8px; top: 8px; background: #ffb800; padding: 8px; }
</style>

A skip link lets keyboard users jump past the navigation (press Tab in the preview to reveal it).

Headings and structure

• One <h1> per page describing its topic; then <h2> for sections, <h3> for subsections; don't skip levels for styling.
• Screen-reader users often navigate by headings, so headings should make sense as an outline.
• Use landmarks (header, nav, main, footer) so users can jump between regions.

Keyboard accessibility

Many people navigate with Tab, Shift+Tab, Enter, Space and arrow keys.

• Every interactive element must be reachable and usable by keyboard.
• Visible focus: never remove outlines without a clear replacement (:focus-visible styles).
• Logical tab order (follow the visual order; avoid positive tabindex).
• Menus, dialogs and dropdowns: open/close with keyboard; Esc closes dialogs; focus moves into a dialog and returns afterwards.
• No keyboard traps.

Test: unplug your mouse and try to complete a booking or checkout.

Screen readers and alt text

Screen readers (NVDA and JAWS on Windows, VoiceOver on iPhone/Mac, TalkBack on Android) read content aloud.

Alt text describes images' purpose:

Avoid "image of..." and filenames like "IMG_2045.jpg".

ARIA (use sparingly)

ARIA attributes add meaning when HTML can't: aria-label, aria-expanded (menus), aria-describedby (error messages), aria-live (announce updates like "Payment received"). The first rule of ARIA: use native HTML first; wrong ARIA makes things worse.

<button aria-expanded="false" aria-controls="faq1" onclick="const o=this.getAttribute('aria-expanded')==='true';this.setAttribute('aria-expanded',!o);document.getElementById('faq1').hidden=o;" style="font:16px system-ui;padding:10px 14px">Do you accept M-Pesa?</button>
<div id="faq1" hidden style="font-family:system-ui;padding:8px 0">Yes. Pay via STK push at checkout or to our Paybill.</div>
<p role="status" aria-live="polite" style="font-family:system-ui">Status messages placed in a live region are announced by screen readers.</p>

Colour, contrast and text

• Contrast at least 4.5:1 for normal text, 3:1 for large text and UI components (see the colour lesson).
• Don't use colour alone to convey meaning.
• Text resizable to 200% without breaking layout; use relative units (rem).
• Avoid text in images (unreadable for screen readers and blurry when zoomed).
• Readable fonts, adequate line height and line length.

Accessible forms

• Visible <label> for every field (connected with for/id or wrapping).
• Clear instructions before fields ("Phone format: 07XX XXX XXX").
• Errors in text, linked with aria-describedby, focus moved to the first error.
• Group related options with <fieldset> and <legend> (e.g. delivery method).
• Don't set short timeouts on forms; warn and allow extensions.
• Avoid CAPTCHAs that only work visually; use accessible alternatives.

Video, audio and motion

• Captions for videos (YouTube auto-captions need correction); transcripts for audio/podcasts.
• Don't autoplay audio; provide pause controls for carousels and animations.
• Respect prefers-reduced-motion for users sensitive to motion:

@media (prefers-reduced-motion: reduce) {
  * { animation: none !important; transition: none !important; scroll-behavior: auto !important; }
}

• Nothing should flash more than three times per second.

Plain language and cognitive accessibility

• Short sentences, common words, clear headings, lists.
• Consistent navigation and button placement across pages.
• Explain jargon; show steps for complex processes (applications, payments).
• Offer Kiswahili versions where your audience needs them.

Testing

Accessibility checklist

Summary

• Accessibility helps people with permanent, temporary and situational disabilities, and improves usability and SEO for all.
• Follow WCAG's POUR principles and aim for level AA.
• Use semantic HTML, proper heading order, landmarks and skip links.
• Ensure keyboard access with visible focus, meaningful alt text, and careful ARIA only when needed.
• Meet contrast rules, build accessible forms, caption media, respect reduced motion, and test with automated tools, keyboards and screen readers.