IAAP WAS — Web Accessibility Specialist
WAS is the technical credential. Where CPACC covers concepts, WAS covers WCAG 2.2 success criteria, testing methodology, remediation, and assistive technology use. It’s the cert employers ask for when they need someone who can actually audit a website.
1 The Hook
An Auckland government agency needs a WCAG 2.2 Level AA accessibility audit of their flagship citizen-facing portal. Their internal tester runs axe and reports “no automated violations.”
The third-party auditor — WAS certified — finds 23 additional failures in 4 hours. Keyboard traps on the document upload modal (SC 2.1.2). Images used as decorative links with null alt text (SC 1.1.1). Colour contrast failures in the footer (SC 1.4.3). A PDF form with no accessible name on any field.
axe caught 0 of these. A WAS-certified tester knows to test what automated tools cannot catch.
The agency’s internal tester was not incompetent. They ran axe correctly. The problem is that axe only catches around 35% of WCAG failures. The remaining 65% require manual testing with keyboard, screen reader, and human judgement. That’s what WAS trains you to do.
2 The Rule
Automated tools catch 30–40% of WCAG failures. The remaining 60–70% require manual testing with keyboard, screen reader, and human judgement. WAS certification proves you can do both.
3 The Analogy
Running only automated accessibility tools is like doing a fire safety inspection with a smoke detector app on your phone.
It catches some hazards. But the inspector who walks every room, tests every exit, checks every extinguisher, and verifies the emergency lighting is the one who certifies the building as safe. The smoke detector app gives you a partial picture and a false sense of security. A WAS-certified tester does the full walk-through.
Senior engineer insight
The hardest part of WAS isn't memorising success criteria — it's developing the instinct to know which manual test to reach for when automated tools return zero violations. On a NZ public-sector portal audit, I once spent 45 minutes confirming a clean axe report before running a single keyboard test. Within three Tab presses I hit a focus trap in a custom date-picker widget that locked keyboard users out of the entire booking flow. The widget had passed axe because axe doesn't simulate keyboard interaction sequences — it inspects DOM attributes.
Most common mistake: treating a clean automated scan as permission to stop testing. Automated tools are the starting line, not the finish line — the failures that matter most to real users (keyboard traps, unlabelled dynamic content, broken focus management) are invisible to scanners by design.
From the field
A Wellington agency contracted an accessibility audit ahead of a NZ Web Accessibility Standard 1.2 compliance deadline. Their dev team had run axe-core in CI for six months and assumed the site was clean. The WAS-certified auditor started with keyboard-only navigation and found that every modal dialog on the site — there were eleven — failed SC 2.1.2 (No Keyboard Trap): focus entered the modal but Escape didn't close it, and Tab eventually cycled out into the background page without closing the overlay, leaving screen reader users stranded in inert content. The team had never tested modals with a keyboard because their automated pipeline couldn't simulate user interaction sequences. After remediation, they discovered their modal library had a known accessibility bug filed two years prior that no one had actioned. The lesson: AT test coverage gaps don't show up in CI dashboards — they show up in audits, and by then the cost is remediation under a compliance deadline rather than a one-line config fix during development.
4 Watch Me Do It
The WAS exam is 75 scenario-based questions, 90 minutes, passing score 65%. Here are the key WCAG 2.2 AA success criteria you need to know cold — with NZ audit examples.
SC 1.1.1 Non-text Content (Level A)
All images need alt text. Decorative images need empty alt (alt="").
Test: Navigate with NVDA. Does the screen reader announce images meaningfully? Icon-only buttons with no aria-label are a common failure.
✔ <img src="divider.png" alt=""> <!-- decorative -->
❌ <img src="alert-icon.svg"> <!-- no alt at all -->
SC 1.4.3 Contrast (Minimum) (Level AA)
Normal text: minimum 4.5:1 contrast ratio. Large text (18pt+ or 14pt+ bold): minimum 3:1.
Test: Browser DevTools → Inspect element → Accessibility panel → Contrast ratio. Or use the Colour Contrast Analyser tool (free download). Common failure: grey text on white backgrounds in footers and form labels.
SC 2.1.1 Keyboard Accessible (Level A)
All functionality must be operable by keyboard alone. No mouse required.
Test: Tab through the entire page without touching the mouse. Can you reach and operate every control? Common failures: custom dropdown menus, date pickers, and modal dialogs that trap focus and cannot be dismissed with Escape.
SC 2.4.7 Focus Visible (Level AA)
Keyboard focus must be clearly visible at all times.
Test: Tab through the page — can you always see which element has focus? The single most common failure in NZ government sites: outline: none or outline: 0 in CSS without a custom focus style to replace it.
✔ :focus-visible { outline: 3px solid #0064d2; outline-offset: 2px; }
SC 4.1.2 Name, Role, Value (Level A)
All UI components must have accessible names, roles, and states that assistive technologies can interpret.
Test with NVDA: Does the screen reader announce button labels, form field names, and current states (checked, expanded, selected)? Common failure: icon-only buttons with no aria-label announce as “button” with no description.
✔ <button aria-label="Open navigation menu"><svg aria-hidden="true">...</svg></button>
WAS testing methodology — the 5-stage approach:
5 When to Use It
WAS is the right credential when:
- You are auditing NZ government or public-sector websites and need to produce a formal WCAG 2.2 AA conformance report
- Your organisation must meet the NZ Web Accessibility Standard 1.2 and needs someone who can conduct and document a compliant audit
- Clients request a Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR)
- You are setting up an internal accessibility testing practice and need the technical credibility to lead it
6 Common Mistakes
🚫 “I used to think: WAS is just about running axe on websites.”
Actually: WAS requires deep knowledge of WCAG 2.2 success criteria, the manual testing methodology, and hands-on assistive technology use. axe is a starting point. The exam scenarios assume you know what to do after axe finds nothing.
🚫 “I used to think: if axe passes, the site is accessible.”
Actually: axe catches around 35% of WCAG failures at best. The failures it misses — keyboard traps, missing focus indicators, unlabelled form fields, inaccessible modal dialogs — are often the most severe. A clean axe report is a starting point, not a pass certificate.
🚫 “I used to think: WCAG 2.1 and WCAG 2.2 are the same thing.”
Actually: WCAG 2.2 added 9 new success criteria and removed SC 4.1.1 (Parsing, which was deprecated). The NZ Web Accessibility Standard 1.2 mandates WCAG 2.2 AA — not 2.1. If you are auditing against 2.1, you are not meeting the NZ standard. Check your audit scope documentation explicitly states WCAG 2.2.
7 Now You Try
A NZ government portal has a modal dialog for document upload. When the modal opens, focus does not move into it. When the Escape key is pressed, the modal closes but focus jumps to the top of the page. Identify which WCAG 2.2 success criteria are violated, explain why, and describe how to remediate each violation.
Why teams fail here
- Stopping at axe — automated tools catch 30–40% of WCAG failures; teams interpret a clean scan as a passing audit and never open a screen reader or lift their hands off the mouse
- Auditing against WCAG 2.1 when the NZ Web Accessibility Standard 1.2 mandates WCAG 2.2 AA — the nine new success criteria in 2.2 (Focus Appearance, Target Size Minimum, Dragging Movements) are regularly missed because teams use outdated checklists
- Testing with NVDA + Firefox instead of NVDA + Chrome — the NVDA + Chrome pairing reflects real-world NZ public-sector usage and is what the WAS exam scenarios assume; Firefox produces different virtual buffer behaviour that can mask failures
- Writing remediations that fix the DOM without testing the AT experience — adding
aria-labelto a button and closing the ticket without confirming NVDA actually announces it correctly; the attribute can be present and still produce a broken announcement due to ARIA authoring errors
Key takeaway
WAS certification means you audit the 65% of WCAG failures that no automated tool will ever find — and in the NZ public sector, that unreachable majority is exactly where the compliance risk lives.
8 Interview Questions
What NZ hiring managers ask about IAAP WAS Web Accessibility Specialist technical certification.
Q1. What is WAI-ARIA and when should you use it?
Strong answer: WAI-ARIA adds semantic meaning to HTML elements without native accessibility semantics. Use it when: native HTML cannot express the required role (role="tabpanel" for custom tab components), dynamic content updates need announcement (aria-live="polite"), or interactive widgets need state communication (aria-expanded="true/false" on accordions). The first rule of ARIA: use native HTML instead wherever possible. A
9 Self-Check
Click each question to reveal the answer.
What percentage of WCAG failures can automated tools typically catch?
Approximately 30–40%. The exact figure varies by tool and page type, but the industry consensus is that no automated tool catches more than 40% of WCAG failures. The remaining 60–70% require manual testing with keyboard, screen reader, and human judgement. WAS trains you for the 60% that tools miss.
Name 3 WCAG 2.2 success criteria that are new — not in WCAG 2.1.
Three of the nine new SCs in WCAG 2.2: Focus Appearance (2.4.11, Level AA) — focus indicators must meet minimum size and contrast; Target Size Minimum (2.5.8, Level AA) — touch targets must be at least 24×24 CSS pixels; Dragging Movements (2.5.7, Level AA) — all functionality using dragging must have a pointer alternative.
What is the minimum contrast ratio for body text under WCAG 2.2 AA?
4.5:1 for normal text (under 18pt, or under 14pt bold). 3:1 for large text (18pt or larger, or 14pt+ bold). These ratios apply to text against its background. Non-text elements (icons, borders that convey information) require a 3:1 contrast ratio under SC 1.4.11 Non-text Contrast.
10 ISTQB Mapping
IAAP WAS — not an ISTQB qualification, but mapped to ISTQB concepts.
CTFL v4.0 Section 4.1.1 covers non-functional testing including accessibility. WAS goes much deeper than CTFL on accessibility specifically. The testing methodology (automated + manual + AT) maps to CTFL’s general test techniques but applied to a specialised domain.
NZ legislative basis: NZ Web Accessibility Standard 1.2 (mandates WCAG 2.2 AA for government agencies). Human Rights Act 1993 s.21 (disability as prohibited discrimination ground). Both create legal weight behind WAS audits in the NZ public sector.