If you are commissioning a custom web app or portal in Singapore, “must be accessible” in the SOW is not an acceptance criterion. Name the standard and level (WCAG 2.2 Level AA), list the screens and user journeys in scope, say how conformance will be tested (automated scan plus manual keyboard and screen-reader passes), and say what evidence the vendor hands over before you sign off. Below: the wording, a test matrix for the new WCAG 2.2 criteria, and the traps to avoid.
Educational only; not legal advice. Have your counsel review contract wording. The worked example below is constructed for illustration and is not a client case.
Who this is for, and who should skip it
For: the product owner, head of IT or procurement lead at a Singapore company buying a customer portal, booking flow, claims form, staff app or similar custom build, especially if your users include older customers, or if you supply digital services to a government agency.
Skip if: you need a full UAT plan, which the custom software UAT checklist covers; you need the go-live evidence bundle as a whole, covered in the acceptance test evidence pack; or you only publish static marketing pages on an off-the-shelf theme. This article does one job: make WCAG 2.2 AA something you can accept or reject.
What changed in WCAG 2.2, in plain terms
The W3C published WCAG 2.2 as a Recommendation on 5 October 2023. According to the W3C’s What’s New in WCAG 2.2 page, it adds nine success criteria to WCAG 2.1, and one older criterion, 4.1.1 Parsing, is now obsolete and removed. Everything else from 2.0 and 2.1 carries over essentially unchanged.
Of the nine new criteria, six are at Level A or AA, so they apply if your contract says “WCAG 2.2 AA”:
- 2.4.11 Focus Not Obscured (Minimum), AA: when an element gets keyboard focus, it must not be entirely hidden by things like sticky headers, cookie banners or chat widgets.
- 2.5.7 Dragging Movements, AA: anything done by dragging (reordering a list, a slider, a kanban card) must also work with a single click or tap.
- 2.5.8 Target Size (Minimum), AA: pointer targets should be at least 24 by 24 CSS pixels, or spaced so they don’t crowd each other, with listed exceptions such as links inside a sentence.
- 3.2.6 Consistent Help, A: if help (a phone number, a contact link, a chat option, an FAQ) appears on multiple pages, keep it in the same relative order.
- 3.3.7 Redundant Entry, A: don’t make people retype information they already gave earlier in the same process; auto-fill it or let them pick it.
- 3.3.8 Accessible Authentication (Minimum), AA: logging in must not depend on a memory or puzzle test unless there is an alternative or a helper; the W3C gives password-manager support and allowing paste as examples.
The other three (2.4.12, 2.4.13 and 3.3.9) are AAA, usually treated as good practice rather than contract scope.
Why this matters for Singapore buyers
For government work, the baseline is explicit. GovTech’s Digital Service Standards (DSS) control catalogue says the DSS incorporates WCAG Levels A and AA, and that agencies and their industry partners who design, develop or deliver government digital services are expected to apply the relevant requirements. The DSS operable controls include WO-13 Focus Visible and Not Obscured and WO-18 Minimum Pointer Target Size, which line up with the new 2.2 criteria above. If your system will be used by or on behalf of an agency, check which DSS controls your contract points to.
For private-sector systems, WCAG conformance is usually something you buy through the contract rather than something a vendor owes you by default. If it is not in the SOW with a test method, it will not be in UAT, and retrofitting focus states or target sizes after the design system is built is painful.
It is not only about compliance. Small tap targets, login flows that block paste and forms that ask for the same details twice frustrate older customers on phones and busy staff too.
The acceptance matrix for the new WCAG 2.2 A/AA criteria
This is the original element of this guide: one row per new criterion, written so a tester can pass or fail it and a vendor knows what evidence to hand over. Attach it to the SOW as a schedule, alongside the existing WCAG 2.1 AA criteria.
| Criterion | Acceptance criterion (contract wording) | How to test | Evidence at UAT | Where it usually fails |
|---|---|---|---|---|
| 2.4.11 Focus Not Obscured (Min) | On every in-scope screen, each focusable element remains at least partly visible when it receives keyboard focus, with sticky headers, footers, cookie banners and chat launchers in their default state. | Tab through each screen at 100% and 200% zoom on desktop; repeat on the mobile breakpoint. | Short screen recording per journey; list of components checked. | Sticky footers, consent banners, floating chat buttons. |
| 2.5.7 Dragging Movements | Every function that uses dragging has a single-pointer alternative (buttons, a menu, or tap-to-select then tap-to-place). | Inventory all drag interactions from the design file; operate each with click or tap only. | Interaction inventory with the alternative for each. | Sortable lists, file drop zones without a browse button, map pins, date-range sliders. |
| 2.5.8 Target Size (Min) | Pointer targets are at least 24 by 24 CSS pixels or meet the W3C spacing exception; any other exception is listed and justified. | Automated check plus manual check of icon buttons, table row actions and pagination. | Scan report; exception register. | Icon-only buttons in data tables, close “x” on modals, dense pagination. |
| 3.2.6 Consistent Help | Help mechanisms (contact details, contact form, chat, self-help link) appear in the same relative order on every page where they are repeated. | Compare page templates side by side; check logged-in and logged-out states. | Template comparison screenshots. | Help moving between the header on marketing pages and the footer inside the app. |
| 3.3.7 Redundant Entry | Within one process, information the user already entered is auto-populated or selectable, except where re-entry is essential, needed for security, or no longer valid. | Walk each multi-step form; list every field asked twice. | Field map per process with the handling for repeats. | Billing vs delivery address, claimant vs policyholder details, multi-page applications. |
| 3.3.8 Accessible Authentication (Min) | No step in sign-in, sign-up or password reset relies only on a cognitive function test; password fields allow paste and password managers; OTP fields allow paste. | Sign in with a password manager; paste into password and OTP fields; check any CAPTCHA has an alternative. | Recording of each auth path; CAPTCHA alternative described. | Paste blocked “for security”, split one-digit OTP boxes, image puzzles with no alternative. |
Keep the full WCAG 2.1 AA set in scope too: missing form labels, poor contrast and keyboard traps still cause plenty of failures.
What to write into the SOW
Use this as a checklist when you review the vendor’s draft. Each line should be answerable with yes or no. (For broader SOW traps, see Singapore SOW red flags.)
- Standard and level: “WCAG 2.2 Level AA” by name and version, not “accessibility best practice”.
- Scope: the screens, user journeys, platforms (web, iOS, Android) and states (logged in, logged out, error states) that must conform. Third-party widgets you choose (payment pages, chat, maps) listed separately with who is responsible.
- Design gate: designs reviewed for contrast, target size, focus states and drag alternatives before build starts, not only at UAT.
- Test method: automated scanning in CI plus manual keyboard-only and screen-reader passes on named journeys. Name the screen readers and browsers.
- Defect severity: accessibility defects classified on the same severity scale as functional defects. A blocked login for keyboard users is a severity 1, not a “nice to have”.
- Evidence: scan reports, manual test logs, recordings and an exception register delivered before UAT sign-off.
- Content ownership: who writes alt text, link text and error messages, and who checks content added after launch.
- Regression: accessibility checks stay in the release checklist after go-live, including during the support period.
Automated tools help, but they do not sign off
Automated scanners are fast and catch a lot, but some criteria need a human. GovTech’s open-source checker Oobee is a useful example: it groups WCAG A and AA issues as “Must Fix”, AAA and best-practice rules as “Good to Fix”, and separates out items that need manual review because they could be false positives. Whatever tool your vendor uses, ask to see the same split.
A scanner cannot tell whether a re-asked field is “essential” or whether help sits consistently across templates, so the matrix asks for manual evidence on those rows.
Worked example (constructed)
A Singapore insurer is replacing a claims form with a five-step web portal used on phones. The vendor’s draft SOW says “responsive and accessible”.
- Before: no level named; UAT has no accessibility cases; the design uses an icon-only row of actions on each claim, a drag-to-upload area for receipts, and a login that blocks paste into the password field.
- After applying the matrix: the SOW names WCAG 2.2 AA for the five claim steps, login and password reset. The design review flags the icon row (2.5.8), the upload area gets a “choose file” button (2.5.7), paste is allowed in password and OTP fields (3.3.8), and the policyholder details from step one pre-fill the claimant section in step three with an “edit” option (3.3.7).
- At UAT: the tester finds the cookie banner covers the “Next” button when tabbing on mobile (2.4.11). Because it is a named criterion with evidence required, it is logged as a defect inside warranty, not a change request.
Decision framework: how much to put in scope
| Your situation | Suggested scope |
|---|---|
| Delivering for, or on behalf of, a Singapore government agency | Map to the DSS controls your contract cites; WCAG 2.2 A and AA as a minimum. |
| Public-facing customer portal (insurance, healthcare, banking, utilities, education) | WCAG 2.2 AA on all customer journeys, including login and error states; see the healthcare software hub for related data duties. |
| Internal staff tool with a known user group | WCAG 2.2 AA on core journeys; agree documented exceptions for admin-only screens. |
| Prototype or MVP for validation | Design gate and the six new A/AA criteria at minimum, so the design system does not need rework later. |
Mistakes that turn accessibility into a change request
- Naming WCAG without a version. “WCAG compliant” lets a vendor test against 2.0. Write 2.2 AA.
- Testing only at UAT. Target sizes and focus styles live in the design system. Catch them in design review.
- Ignoring third-party widgets. Your users will not care that the chat launcher belongs to another vendor. List who fixes what.
- Blocking paste “for security”. It works against 3.3.8 and against password managers. Ask your security lead for the actual risk being addressed.
- No owner after launch. New content and features can break conformance. Keep checks in the release process; see quality engineering for how that fits into a test strategy.
FAQ
Is WCAG 2.2 AA mandatory for private companies in Singapore?
For government digital services, GovTech’s DSS sets WCAG A and AA as the baseline for agencies and their industry partners. For private-sector systems, treat it as a contractual and customer-experience decision, and ask counsel if your sector has specific rules.
If our vendor already tests to WCAG 2.1 AA, what extra work is 2.2?
Six extra A/AA criteria: focus not obscured, dragging alternatives, target size, consistent help, redundant entry and accessible authentication. Use the matrix above to check each one.
Can an automated scan prove conformance?
No. Scans are a strong first pass, but criteria such as redundant entry and consistent help need manual review. Ask for both kinds of evidence.
Does this apply to mobile apps?
WCAG is written for web content, but its principles are widely applied to native apps, and the DSS control catalogue includes mobile-app recommendations for several controls. Name the platforms in your SOW so there is no doubt. See mobile app development in Singapore.
Next step
Before you sign the SOW, paste the acceptance matrix and the eight-line SOW checklist into the vendor’s draft and ask them to answer each row in writing. Then add the six new criteria as test cases in UAT. If you want a team that designs and tests to WCAG 2.2 AA from day one, see UI/UX design and web application development in Singapore, or contact WC1 to review your current SOW.