Skip to main content

4. Accessibility & WCAG Compliance

Purpose of These Notes​

These notes explain:

  • why accessibility matters (moral and practical reasons)
  • the W3C Web Content Accessibility Guidelines (WCAG 2.1)
  • specific, actionable techniques to make designs accessible
  • how to verify accessibility before submission

Key Concepts​

By the end of this topic, you must understand:

  • Accessibility: Designing so people with disabilities can use your site
  • Universal design: Designs that work for everyone benefit everyone
  • WCAG 2.1: The international standard for web accessibility
  • Assistive technologies: Screen readers, keyboard navigation, text magnification

Accessibility is not optional. WCAG Level AA compliance is a minimum requirement for AS91901.

Core Explanation​

Why Accessibility Matters​

Common misconception: "Accessibility is for disabled people; I don't need to design for them."

Reality:

  • 15% of the world's population has a disability (WHO)
  • Vision problems (colour blindness, low vision, blindness) affect 1 in 8 people
  • Hearing problems affect 1 in 5 people
  • Motor disabilities (arthritis, tremor, paralysis) affect many
  • Cognitive disabilities (dyslexia, ADHD, autism) are common

More importantly: Accessible design benefits everyone:

  • Captions help people in noisy environments (and people learning a language)
  • Large text helps people with low vision (and people reading on a small phone)
  • Keyboard navigation helps people with motor disabilities (and people on a train using one hand)
  • Simple language helps people with cognitive disabilities (and people reading in their second language)

WCAG 2.1 Standards​

The W3C Web Content Accessibility Guidelines (WCAG) 2.1 define accessibility standards.

Three Levels​

  • Level A: Basic accessibility
  • Level AA: Enhanced accessibility (recommended for most websites)
  • Level AAA: Optimal accessibility (very strict; not required for most sites)

For AS91901: You must achieve Level AA compliance.

Four Principles (POUR)​

WCAG organizes around four principles:

  1. Perceivable: Users must be able to perceive content
  2. Operable: Users must be able to navigate and use the site
  3. Understandable: Content must be clear and the site must be predictable
  4. Robust: The site must work with assistive technologies

WCAG 2.1 Specific Requirements​

Perceivable​

Colour Contrast

Text Alternatives (Alt Text)

  • All images must have descriptive alt text
  • Alt text describes the image's purpose, not just the content
  • Example: Image of a climbing wall
    • Bad alt text: "climbing wall"
    • Good alt text: "Indoor climbing wall with coloured holds at the climbing gym, 15 feet tall"

Don't use colour alone

  • Never convey information through colour alone (e.g., "required fields are red")
  • Pair colour with another indicator (text label, icon, asterisk)

Operable​

Keyboard Navigation

  • All interactive elements (buttons, links, forms) must be operable via keyboard
  • Users must be able to see which element currently has focus
  • Tab order should be logical (top-to-bottom, left-to-right)

Avoid Keyboard Traps

  • Users shouldn't get stuck unable to navigate away from an element using only the keyboard

Skip Links

  • Provide a "Skip to main content" link so keyboard users don't have to tab through the entire navigation

Understandable​

Clear Language

  • Use simple, plain language
  • Avoid jargon or define it when necessary
  • Short paragraphs, lists, and headings improve scannability

Consistent Navigation

  • Navigation structure should be consistent across pages
  • Buttons and links should be labelled clearly
  • Users shouldn't be confused about where they are

Error Messages

  • Forms must have clear error messages that identify the problem
  • Error messages should suggest how to fix the problem

Robust​

Valid HTML

  • Code should validate against HTML5 standards
  • This helps screen readers and other assistive technologies parse your content correctly

Semantic HTML

  • Use proper HTML tags:
    • <h1>, <h2> for headings (not <div> styled to look like headings)
    • <button> for buttons (not <div onclick>)
    • <nav> for navigation
    • <main> for primary content
    • <form> with <label> for forms (not <div> acting as forms)

Assistive Technologies​

Screen Readers​

  • Software that reads website content aloud
  • Popular: NVDA (free), JAWS (expensive), VoiceOver (Mac/iOS)
  • Users navigate by headings, landmarks, and tabbing
  • Test your site: Use NVDA or VoiceOver to navigate without looking at the screen

Keyboard Navigation​

  • Users who can't use a mouse rely entirely on keyboard
  • Tab through your site; verify you can reach all interactive elements
  • Verify focus indicators are visible (browser default is often sufficient)

Text Magnification​

  • Users may zoom to 200% or larger
  • Responsive design matters; layouts shouldn't break at large zoom

High Contrast Mode​

  • Some operating systems offer high-contrast modes (e.g., Windows High Contrast)
  • Test your site in high-contrast mode; verify text and buttons are visible

Worked Example: Conceptual Reasoning​

Scenario: Designing a form for a booking website.

Initial design (inaccessible):

Name: [input box]
Email: [input box]                Required fields are RED
Phone: [input box]
[Submit button]

Problems:

  • No labels associated with inputs (screen reader users won't know what each field is)
  • "Required" is conveyed by colour alone (colourblind users don't know which are required)
  • No error messages; if submission fails, users don't know why
  • Submit button isn't keyboard-accessible if the form uses JavaScript improperly

Accessible redesign:

<form>
  <fieldset>
    <legend>Booking Details</legend>
    
    <label for="name">Name *</label>
    <input id="name" type="text" required aria-required="true">
    
    <label for="email">Email *</label>
    <input id="email" type="email" required aria-required="true">
    
    <label for="phone">Phone</label>
    <input id="phone" type="tel">
    
    <p class="note">* Required fields</p>
    
    <button type="submit">Book Appointment</button>
  </fieldset>
</form>

Improvements:

  • Semantic HTML: <label>, <input>, <fieldset>, <legend> clearly define form structure
  • Labels linked to inputs via for and id attributes (screen readers announce labels)
  • Required indicated by * and text "* Required fields" (not colour alone)
  • Valid form element (not a <div> disguised as a form)
  • Keyboard-accessible: Tab through inputs; Enter submits

Testing:

  • Use NVDA screen reader to navigate; verify labels are read
  • Zoom to 200%; verify layout doesn't break
  • Use keyboard only; verify all fields and buttons are reachable
  • Check colour contrast; verify 4.5:1 minimum

Common Misconceptions​

Misconception 1: "Accessibility is only for blind users"​

Why it's wrong: Disability is diverse. Accessibility benefits people with:

  • Visual disabilities (blindness, low vision, colour blindness)
  • Motor disabilities (can't use a mouse)
  • Hearing disabilities (need captions)
  • Cognitive disabilities (need clear language)
  • Temporary disabilities (broken arm, sunglasses on a bright day)

Correct thinking: Design for everyone. Accessibility is universal design.

Misconception 2: "Accessible design looks boring"​

Why it's wrong: You can have beautiful, accessible design. They're not mutually exclusive.

Correct thinking: Accessibility constrains some decisions (e.g., colour contrast) but doesn't prevent good design. Many gorgeous, accessible sites exist.

Misconception 3: "I'll add accessibility after the design is done"​

Why it's wrong: Retrofitting accessibility is expensive and often produces poor results. Design accessibility from the start.

Correct thinking: Make accessibility decisions early. It's faster and produces better outcomes.

Misconception 4: "Alt text is optional because I have a caption"​

Why it's wrong: Captions describe audio; they don't describe images. Alt text is separate and mandatory.

Correct thinking: All images need alt text, even if there's a caption nearby.

WCAG Checklist for AS91901​

Before submission, verify:

  • Colour Contrast: All text has 4.5:1 contrast with background (test with WebAIM Contrast Checker)
  • Alt Text: All images have descriptive alt text
  • Semantic HTML: Headings, buttons, forms, and landmarks use proper HTML tags
  • Keyboard Navigation: All interactive elements are reachable and operable via Tab key
  • Focus Indicators: Clear visual indication of which element is currently focused
  • Form Labels: All form inputs have associated <label> elements
  • Error Messages: Form errors are clearly explained; suggestions for fixing are provided
  • Plain Language: Text is clear, jargon is explained, paragraphs are short
  • Responsive: Layout works at 200% zoom; no horizontal scrolling at 320px width

Assessment Relevance​

In AS91901, you must submit:

  • Accessibility checklist verifying WCAG 2.1 Level AA compliance
  • Evidence of testing: Screenshots of contrast checks, keyboard navigation tests, screen reader testing
  • Design rationale: Explain how your design decisions support accessibility (e.g., why you chose this colour, how you structured headings)

In your design critique, your teacher will ask:

  • "Why did you choose this colour? What's the contrast ratio?"
  • "Can you navigate this form using only your keyboard?"
  • "What would a screen reader user hear when they visit your site?"
  • "Does your design work for colourblind users?"

Accessibility is not optional. It's part of professional web design.

External Resources​

WCAG & Standards​

Tools & Checkers​

Learning Resources​

Videos​

Key Vocabulary​

  • Alt text: Descriptive text for images, read by screen readers
  • ARIA: Accessible Rich Internet Applications; attributes that provide additional meaning to HTML
  • Assistive technology: Software or hardware that helps people with disabilities use computers
  • Captions: Text transcription of audio content (for deaf/hard-of-hearing users)
  • Colour blindness: Difficulty distinguishing certain colours (affects ~8% of men)
  • Contrast ratio: Measure of brightness difference between text and background
  • Focus: The interactive element currently selected (via keyboard or mouse)
  • Focus indicator: Visual indicator of which element is focused
  • Keyboard navigation: Using only the keyboard (Tab, Enter, Arrow keys) to interact with a website
  • Screen reader: Software that reads website content aloud
  • Semantic HTML: HTML that uses proper tags to convey meaning (e.g., <button> for buttons, not <div>)
  • Skip link: Link that allows keyboard users to skip repetitive navigation
  • WCAG: Web Content Accessibility Guidelines; international standard for web accessibility

Next Steps​

You now understand accessibility principles. In the next topic, Prototyping & Tools, you'll learn how to create functional, testable prototypes in Figma or similar tools.

End of Topic 4: Accessibility & WCAG Compliance