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.
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.
8 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.
9 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.