Accessibility Conformance Decision for a Public Sector Procurement Portal
A government agency must publish an online procurement portal. The tender requires WCAG 2.2 Level AA and EN 301 549. The supplier ran an automated accessibility scan after remediation and reports zero "critical" issues. Manual testing by the agency found: a keyboard trap in the date picker; focus not visible on a custom dropdown; a screen reader announces an icon-only button only as "button"; at 320 CSS pixels the table forces horizontal scrolling; and the CAPTCHA has no non-visual alternative. The supplier says the automated scan is the objective evidence and wants to publish an accessibility statement claiming full conformance. The procurement deadline is in 10 days. The agency has one accessibility tester and access to NVDA, JAWS, VoiceOver, and keyboard-only testing. A supplier representative argues that WCAG 2.2 AA does not require support for every screen reader.
1. Should the agency accept the automated scan as evidence of WCAG 2.2 AA conformance? Justify using the defects found.
Read the worked answer
No. Automated scans detect only a subset of WCAG failures. They are useful for repeatable checks such as some contrast and missing-label cases, but they cannot establish conformance.
The defects found require manual or assistive-technology testing:
- Keyboard trap violates keyboard accessibility and requires actual keyboard navigation to detect.
- Focus not visible on a custom dropdown is a visual keyboard issue that scanners commonly miss.
- Icon-only button announced only as "button" is an accessible-name problem that needs a screen reader or accessibility tree inspection.
- Reflow at 320 CSS pixels requires viewport testing and judgement about content loss and horizontal scrolling.
- CAPTCHA with no non-visual alternative requires a functional alternative, not a code scan.
WCAG conformance also requires that full pages meet the success criteria. Known failures mean the agency cannot honestly claim full conformance. The supplier's point that not every screen reader is supported is true in itself, but it does not excuse failures that affect the tested combinations and keyboard users. The statement must be accurate, not optimistic.
2. Prioritise the five defects for remediation. Which would block launch, and why?
Read the worked answer
Prioritise by severity and breadth of impact:
- Keyboard trap: blocks keyboard-only users from completing the date selection. This is a launch blocker because it prevents task completion outright.
- CAPTCHA with no non-visual alternative: blocks users who cannot solve the visual challenge. This is also a launch blocker unless a functional alternative is provided.
- Icon-only button without an accessible name: screen reader users cannot identify the control. High severity; fix before launch if it affects a core procurement task.
- Focus not visible on custom dropdown: keyboard users lose position and may make errors. High severity; fix before launch or provide a verified workaround.
- Reflow failure at 320 CSS pixels: serious for small-screen and zoom users, but impact depends on whether the table remains operable. It should be fixed, but may be documented as a known limitation only if the task can still be completed and the statement is honest.
The trap and CAPTCHA are the clearest blockers. A 10-day deadline does not justify a false conformance claim; it justifies prioritising blockers and publishing an accurate statement with known limitations.
3. What should the accessibility statement say, and what testing should be repeated before publication?
Read the worked answer
The statement should identify the standard targeted, the conformance status, the date of assessment, the scope, known inaccessible content, alternatives or workarounds, and a contact route for accessibility feedback. It should not say "fully conformant" while known failures remain. If the portal partially conforms, say so and list the specific limitations.
Before publication, repeat:
- Keyboard-only navigation through core procurement tasks, including the date picker and dropdown.
- Screen reader checks with at least two relevant combinations, such as NVDA with Firefox and VoiceOver with Safari, plus the supplier's claimed combination.
- Zoom and 320 CSS-pixel reflow checks.
- CAPTCHA alternative verification.
- Automated scanning as a supplement, not as the sole evidence.
Record defects, fixes, retest results, and residual limitations. The statement should be reviewed by someone who can accept the residual risk.