Lesson 3 of 3 · Accessibility Certification

Full Accessibility Audit — Practice Exercise

Apply everything from CPACC and WAS to a realistic NZ government portal. Find the WCAG 2.2 AA failures, document them correctly, and write the remediation guidance.

Accessibility Certification WCAG 2.2 AA ยท IAAP WAS ~35 min · Practice exercise
Scenario: Rātonga NZ — Government Service Portal

You are auditing Rātonga NZ — a fictional NZ government service portal where citizens update their address and download official documents. The portal has recently had a design refresh. Your task: audit six HTML fragments, identify every WCAG 2.2 AA violation, and document each finding as you would in a formal audit report.

For each fragment: (1) which WCAG 2.2 SC is violated, (2) Level A or AA, (3) one-sentence description of the issue, (4) how to remediate it.

The HTML Fragments

Fragment 1 — Images

<img src="/hero-banner.jpg" alt="banner">
<img src="/icons/download.svg">

Fragment 2 — Navigation Button

<button onclick="openMenu()">
  <svg aria-hidden="true" width="24" height="24">...</svg>
</button>

Fragment 3 — Form Inputs

<input type="text" placeholder="Enter your address">
<input type="email" placeholder="Email">

Fragment 4 — Colour Contrast (text colour #767676 on #ffffff background)

<p style="color: #767676;">Last updated: 12 June 2026</p>

Fragment 5 — Modal Dialog

<!-- Focus stays on the originating button when modal opens -->
<div role="dialog" aria-label="Confirm address update" tabindex="-1">
  <p>Are you sure you want to update your address?</p>
  <button>Confirm</button>
  <button>Cancel</button>
  <!-- No focus management on open, no Escape key handler -->
</div>

Fragment 6 — Logo Link + Skip Navigation

<a href="#content">
  <img src="/logo.png" alt="">
</a>
<!-- No skip navigation link before main navigation -->

Model Audit Findings

Fragment 1 — SC 1.1.1 Non-text Content (Level A)

Issue 1a: hero-banner.jpg has alt="banner" — the alt text describes the element type, not the content. A screen reader announces “banner” with no information about what is depicted.

Remediation: Replace with meaningful alt text describing the image content, e.g. alt="New Zealand families using the Rātonga NZ digital portal on a laptop".

Issue 1b: download.svg has no alt attribute at all. The browser treats this as a missing attribute (different from alt=""). Screen readers may announce the file name or skip the element unpredictably.

Remediation: If the icon is inside a button with a visible label, add aria-hidden="true" to the SVG. If it is a standalone interactive element, add aria-label="Download" to the parent anchor or button.

Fragment 2 — SC 4.1.2 Name, Role, Value (Level A)

Issue: The button has no accessible name. The SVG is hidden from assistive technologies (aria-hidden="true"), leaving the button with no announced label. Screen readers announce “button” — users have no way to know what the button does.

Remediation: Add aria-label="Open navigation menu" to the <button> element. This gives keyboard and screen reader users a clear label without changing the visual design.

Fragment 3 — SC 1.3.1 Info and Relationships (Level A) + SC 3.3.2 Labels or Instructions (Level A)

Issue: Both inputs have no associated <label> element. Placeholder text is not a label — it disappears when the user types, leaving them with no visible indication of what the field expects. Screen readers announce placeholder text as a hint, not as the field’s persistent label.

Remediation: Add explicit <label for="address">Your address</label> before each input, and add matching id attributes to the inputs. Keep placeholder text as supplementary guidance only, never as the sole label.

Fragment 4 — SC 1.4.3 Contrast (Minimum) (Level AA) — Near-Fail

Issue: #767676 on #ffffff = 4.48:1 contrast ratio. WCAG 2.2 AA requires 4.5:1 for normal text. This technically fails by 0.02:1 — a marginal failure, but a failure nonetheless. Near-fail values are particularly important to flag because they may render on some displays or in some colour modes at lower actual contrast.

Remediation: Darken the text colour to #696969 (4.8:1) or #666666 (5.74:1) on #ffffff to achieve a comfortable pass. Avoid values that only just scrape over the threshold — aim for 5:1 or better for body-weight text.

Fragment 5 — SC 2.4.3 Focus Order (Level A) + SC 2.1.2 No Keyboard Trap (Level A)

Issue 5a (SC 2.4.3): When the modal dialog opens, focus is not moved into it. Focus remains on the button that opened it. Keyboard users Tab away from the button and navigate through background content — they cannot interact with the modal unless they discover it by chance.

Issue 5b (SC 2.1.2): The modal has no Escape key handler. Keyboard users cannot dismiss the dialog. The dialog element has tabindex="-1" (correct) but no programmatic focus shift on open, and no keyboard containment within the dialog while it is open.

Remediation: On modal open: call dialog.focus() or focus the first interactive element within it. Constrain Tab/Shift+Tab within the dialog while it is open. Add keydown handler for Escape to close and return focus to the originating button. Implement per the ARIA Authoring Practices Guide Dialog Pattern.

Fragment 6a — SC 2.4.4 Link Purpose (Level A)

Issue: The logo is a linked image with alt="". An empty alt on a linked image removes all accessible name from the link. Screen readers announce “link” with no destination or purpose. Keyboard users cannot determine where the link leads.

Remediation: Change to alt="Rātonga NZ — home page". For a logo link this is the correct pattern: the alt describes the link destination, not the image aesthetics.

Fragment 6b — SC 2.4.1 Bypass Blocks (Level A)

Issue: No skip navigation link exists before the main navigation. Keyboard and screen reader users must Tab through all navigation items on every page load before reaching main content. On a site with a 20-item nav, this is a significant interaction burden.

Remediation: Add <a href="#main-content" class="skip-link">Skip to main content</a> as the very first element inside <body>. Style it to be visually hidden until focused (not display:none which removes it from tab order). Ensure #main-content exists as an id on the main landmark.

Writing a Formal Accessibility Finding

After completing the audit, each finding needs to be documented in a format that developers can act on. Here is the standard structure for Fragment 5 (modal focus management):

FINDING: Modal dialog focus management WCAG SC: 2.4.3 Focus Order (Level A), 2.1.2 No Keyboard Trap (Level A) SEVERITY: Critical (blocks keyboard and screen reader users from using the feature) ENVIRONMENT: Desktop Chrome 125 + NVDA 2024.1 / Windows 11 STEPS TO REPRODUCE: 1. Navigate to the address update page using keyboard only (Tab key) 2. Tab to the "Update address" button and press Enter 3. Observe: modal opens, focus remains on the originating button 4. Continue pressing Tab: focus moves through background page content, not the modal 5. Press Escape: modal does not close 6. No keyboard path exists to reach the Confirm or Cancel buttons EXPECTED: Focus moves into the modal on open. Tab is constrained within the modal. Escape closes the modal and returns focus to the originating button. ACTUAL: Focus stays on the background page. Keyboard users cannot interact with or dismiss the modal. The dialog is functionally inaccessible to keyboard users. REMEDIATION: - Move focus to dialog element or first focusable child on open: dialog.focus() - Implement Tab/Shift+Tab containment within the dialog while open - Add keydown listener for Escape key to close dialog and restore focus - Reference: ARIA APG Dialog (Modal) Pattern https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

Navigation

← WAS Technical Accessibility Certification Track Hub →