WCAG Principles and Practical Checks

WCAG (Web Content Accessibility Guidelines) helps you build websites that people with different abilities can use. WCAG is organised around four core principles called POUR:

• Perceivable: Users must be able to perceive the information (it can’t be invisible to all their senses).
• Operable: Users must be able to operate the interface (not just with a mouse).
• Understandable: Users must be able to understand the content and how to use the interface.
• Robust: Content must work reliably across browsers, devices, and assistive technologies.

In this topic, you’ll learn what each principle means in practice, and how to do quick, reliable checks while you build.

---

1) Perceivable: Users can see/hear the content

Key idea

If a user can’t see an image, hear audio, or distinguish colours well, they still need access to the same meaning and functionality.

Practical checks

A. Text alternatives (images, icons, charts)

• Check: Every meaningful image has an appropriate alt description.
• Check: Decorative images have empty alt (alt="") so screen readers skip them.
• Check: Icon-only buttons/links have accessible names.

Examples:

<!-- Meaningful image -->
<img src="team-photo.jpg" alt="Support team standing in front of the Cape Town office">

<!-- Decorative image -->
<img src="divider.svg" alt="">

<!-- Icon button: ensure accessible name -->
<button aria-label="Search">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Common pitfall:

• Writing alt="image" or repeating nearby text unnecessarily. The alt should communicate the purpose.

---

B. Colour contrast
Good contrast helps users with low vision, colour blindness, or when using a phone in bright sunlight.

• Check: Body text contrast meets at least 4.5:1 (normal text).
• Check: Large text (roughly 18pt+ or 14pt bold+) meets at least 3:1.
• Check: Important non-text elements (icons, input borders, focus indicators) also have clear contrast.

Quick workflow:

1. Choose your text and background colours.
2. Use a contrast checker (browser dev tools, Lighthouse, or an online contrast tool).
3. Fix low-contrast colour pairs early, before you design the full UI.

Common pitfalls:

• Light grey text on white backgrounds.
• Placeholder text used as the only label (often too faint and disappears when typing).
• Error messages shown only in red without extra cues.

---

C. Don’t rely on colour alone

• Check: If something is “required”, “error”, “active”, or “selected”, it isn’t indicated only by colour.
• Fix: Add text, icons, patterns, or position changes.

Example:

<label for="email">Email <span aria-hidden="true">*</span></label>
<input id="email" name="email" required aria-describedby="emailHint">
<p id="emailHint">Required field.</p>

---

2) Operable: Users can use it (keyboard, touch, assistive tech)

Key idea

People may navigate with a keyboard, switch device, voice control, screen reader gestures, or other methods. Your site must support these.

Practical checks

A. Keyboard navigation (no mouse)
Do this check often:

• Press Tab to move forward through interactive elements.
• Press Shift + Tab to move backward.
• Press Enter/Space to activate buttons and controls.
• Use arrow keys in components where expected (menus, radios, sliders—depending on the pattern).

Check list

• You can reach all interactive elements.
• The tab order is logical and matches the visual flow.
• Nothing “traps” you (e.g. you tab into a modal and can’t leave it properly).
• Custom components (dropdowns, tabs) work by keyboard.

Common pitfalls:

• Click handlers on non-interactive elements:

  <!-- Avoid -->
  <div onclick="submitForm()">Submit</div>
  

  Use:

  <button type="button" onclick="submitForm()">Submit</button>
  

---

B. Visible focus (focus indicator)
Users must be able to see where they are on the page.

• Check: When you press Tab, you can clearly see the focus indicator.
• Avoid: Removing outlines without providing a replacement.

Bad:

:focus { outline: none; }

Better:

:focus-visible {
  outline: 3px solid #0b5fff;
  outline-offset: 3px;
}

---

C. Focus management (especially modals and dynamic UI)
When the UI changes (opening a modal, showing validation errors, navigating to a new section), you should manage focus so the user doesn’t “get lost”.

• Check: When a modal opens, focus moves into it (usually the modal heading or first interactive element).
• Check: Focus is trapped inside the modal while it’s open.
• Check: When the modal closes, focus returns to the control that opened it.

Common pitfalls:

• A modal opens visually, but keyboard focus stays behind it.
• Closing the modal sends focus back to the top of the page.

---

D. Provide skip links and landmarks
Skip links help keyboard and screen reader users jump past repeated content (like navigation).

• Check: There is a “Skip to main content” link that appears on focus and works.
• Check: Use semantic landmarks like <header>, <nav>, <main>, <footer> to support navigation.

Example:

<a class="skip-link" href="#main">Skip to main content</a>

<header>...</header>
<nav>...</nav>
<main id="main">...</main>

---

3) Understandable: Users can understand content and interactions

Key idea

People should be able to predict what will happen, read the content clearly, and fix mistakes.

Practical checks

A. Clear labels and instructions

• Check: Form fields have visible labels (not placeholder-only).
• Check: Buttons and links have descriptive text (avoid “Click here”).
• Check: Error messages say what went wrong and how to fix it.

Example:

<label for="password">Password</label>
<input id="password" name="password" type="password" aria-describedby="pwHint">
<p id="pwHint">Must be at least 8 characters.</p>

---

B. Consistent navigation and behaviour

• Check: Navigation stays in a consistent place across pages.
• Check: Components behave the same way wherever they appear.

Common pitfall:

• Same icon used for different actions on different pages.

---

C. Avoid unexpected changes

• Check: The page doesn’t suddenly navigate away when a user tabs into a field or changes a selection, unless clearly communicated.
• Fix: If changing a dropdown triggers an update, provide a button like “Apply” or announce the change appropriately.

---

4) Robust: Works across browsers and assistive technologies

Key idea

Use semantic HTML and standards so assistive technologies can interpret your site correctly now and in the future.

Practical checks

A. Semantic HTML first

• Check: Use <button> for buttons, <a> for links, headings in order (<h1> then <h2>, etc.).
• Check: Lists use <ul>/<ol> with <li>.
• Check: Tables are used for data, not layout.

Common pitfall:

• Building everything from <div>s and then trying to patch with ARIA.

---

B. ARIA: use carefully
ARIA can help, but it can also make things worse if misused.

• Rule of thumb: Use native HTML first. Add ARIA only when needed.
• Check: If you use ARIA attributes, they match the actual behaviour.
• Check: Don’t add role="button" to a <div> instead of using a <button>.

---

C. Valid, well-structured markup

• Check: Each id is unique.
• Check: Form controls are associated with labels (for + id, or wrapping).
• Check: Headings reflect page structure (don’t skip levels for styling).

---

Common accessibility pitfalls to watch for (quick “spot checks”)

1. Missing or poor alt text on key images.
2. Low contrast text, icons, placeholder text, and focus indicators.
3. No visible focus or focus styles removed.
4. Mouse-only interactions (hover-only menus, click-only controls).
5. No keyboard support for custom components.
6. No skip link and no landmarks (<main>, <nav>, etc.).
7. Form errors not announced clearly, or only shown in colour.
8. Placeholder as label (users forget what the field is for).
9. Incorrect heading order (used for size instead of structure).
10. Dynamic content updates with no focus management or clear feedback.

---

A practical mini-audit you can do in 10 minutes

Use this simple routine on any page you build:

1. Keyboard-only pass
   • Tab through everything.
   • Confirm focus is visible and order makes sense.
2. Contrast check
   • Check body text, buttons, input borders, error text, focus outline.
3. Screen reader-friendly structure
   • Confirm there is one <h1>, sensible headings, and a <main>.
4. Forms
   • Labels exist, required fields are clear, errors are helpful.
5. Images and icons
   • Meaningful images have good alt. Decorative images are skipped.

If you do these checks consistently during development, you’ll catch most accessibility issues early—before they become expensive to fix.