WCAG 2.2 AA is not a nice-to-have. It is the conformance bar for Singapore government tenders, increasingly the bar for enterprise procurement, and the right bar for any brand that wants to be usable by the 15% of any audience that has some form of disability. The good news is most WCAG failures are easy and cheap to fix. If you know what to look for. This is the field guide we use on every SGBP accessibility audit.
-
01
Accessibility is engineering, not goodwill
WCAG conformance is a deliberate set of code patterns — semantic HTML, focus management, contrast, labels — not an afterthought or a plugin. Built in, it costs almost nothing extra.
-
02
15% of every audience is silently filtered
Roughly 15% of people have a disability that affects how they use the web. A site that fails WCAG fails them quietly, with no error message and no support ticket. They just leave.
-
03
Government and enterprise demand it
Singapore government and enterprise procurement increasingly require WCAG 2.1 or 2.2 AA. A site that cannot demonstrate conformance is out of the running before the pitch.
Why this matters for Singapore teams
Singapore has an aging population and a higher-than-average rate of visual impairment as adults move through their 60s and 70s. The same heartland shoppers who use PayNow at the hawker centre also need a site that respects their preferred font size, their lower contrast vision, or their occasional reliance on screen magnification. WCAG conformance is not a tax. It is how you build a site that serves your actual audience.
The procurement reality is the more immediate trigger. GovTech, the Digital Service Standards Office and most statutory boards require WCAG 2.1 AA conformance on any web service procurement. WCAG 2.2 AA is being phased in. A vendor without a conformance statement and an audit history is at a disadvantage before the bid is read. For enterprise tenders. Banks, telcos, listed companies. The picture is similar. Procurement teams ask for VPATs (Voluntary Product Accessibility Templates) and conformance reports as standard.
Beyond compliance, accessibility is good engineering hygiene. The patterns that pass WCAG. Semantic HTML, proper heading hierarchy, labelled inputs, visible focus, sufficient contrast. Also produce sites that load faster, rank better in search, and convert better on mobile. The Venn diagram between WCAG and SEO is uncomfortably large. Sites built for screen readers also tend to be sites that Googlebot understands clearly.
The legal dimension in Singapore is currently lighter than in the US, where ADA Title III lawsuits have driven web accessibility for two decades, but it is moving. The Singapore High Court has heard cases referencing the Code on Accessibility in the Built Environment, and digital equivalents are being discussed. A site that fails WCAG today may be a defensible position in 2026 but is unlikely to be in 2029.
The WCAG 2.2 AA checklist that matters
WCAG 2.2 has 50+ success criteria at AA. The good news is the same 12 issues account for roughly 80% of failures we see in Singapore audits. Get these right and you have done most of the work.
Issue 1. Colour contrast
Body text needs 4.5:1 contrast against its background. Large text (18pt or 14pt bold) needs 3:1. Non-text UI elements (buttons, icons, borders) need 3:1. Use a tool like WebAIM Contrast Checker or Stark in Figma during design. Common failures: light grey body text on white, low-contrast button hover states, branded colour palettes with insufficient AA pairings.
Issue 2. Keyboard navigation
Every interactive element. Links, buttons, form fields, dropdowns, modals. Must be reachable and operable with a keyboard alone. Tab order has to be logical. Focus has to be visible. WCAG 2.2 strengthened this with 2.4.11 Focus Not Obscured and 2.5.7 Dragging Movements requiring drag alternatives.
Issue 3. Alt text on images
Every meaningful image needs descriptive alt text. Decorative images use alt="". Complex images (charts, diagrams) need a longer description elsewhere. Never use alt="image" or the filename.
Issue 4. Form labels
Every input needs a visible label associated with for and id. Placeholder text is not a label. Error messages need to be programmatically associated with their field via aria-describedby.
Issue 5. Semantic HTML
Use <button> for buttons, <a> for links, <h1> to <h6> for headings, <nav> for navigation, <main> for main content. Resist the temptation to use <div onclick>. It fails keyboard and screen reader testing instantly.
- Body text contrast 4.5:1, UI elements 3:1, validated with WebAIM checker
- Every interactive element reachable and operable by keyboard alone
- Visible focus indicator on every focusable element (do not remove outline)
- Heading hierarchy logical and unbroken (h1 -> h2 -> h3, no skips)
- Every image has appropriate alt text, decorative images use empty alt
- Every form input has a visible, associated label
- Error messages programmatically associated with the relevant field
- Modals trap focus, announce purpose, and return focus on close
Implementation walkthrough
A typical SGBP WCAG audit runs as a two-week sprint with a fixed scope. Here is the actual sequence.
Day one and two is automated scanning. We run axe-core, Pa11y or Lighthouse Accessibility against every unique template on the site. Automated tools catch about 30 to 40% of real failures. Contrast issues, missing alt text, missing form labels, invalid ARIA. The output goes into a tracking sheet with severity, location and example.
Days three to five is manual testing. We tab through every page with the keyboard, listening for trapped focus, illogical tab order, missing visible focus. We test with NVDA on Windows and VoiceOver on Mac, running through the major user journeys. Homepage, product, cart, checkout, contact form. We test at 200% zoom and 400% zoom for reflow. We test on a real mobile device with TalkBack or VoiceOver mobile.
<!-- Common WCAG fixes, before and after -->
<!-- Before: low contrast, missing label -->
<input type="email" placeholder="Email" style="color: #999">
<!-- After: 4.5:1 contrast, visible label, error association -->
<label for="email">Email</label>
<input id="email" type="email" aria-describedby="email-error">
<span id="email-error" role="alert">Please enter a valid email address</span>
Days six to ten is remediation. We fix the top failures in priority order: contrast, missing labels, broken keyboard nav, missing alt text, semantic HTML, focus management. Each fix is verified manually before being marked complete. We re-run axe-core after each major batch to confirm regressions are not creeping in.
The final two days are reporting and handover. We produce a written WCAG 2.2 AA conformance report. What was tested, what passed, what failed, what was fixed, what remains. And a VPAT-style summary that procurement teams can use directly. We also write a maintenance runbook so the team knows how to keep conformance as new pages and features deliver.
-
01
Automated scan
Run axe-core, Pa11y and Lighthouse Accessibility on every unique template. Catalogue findings.
Deliverable. Automated findings spreadsheet
-
02
Manual keyboard and screen reader
Tab-test every page, test with NVDA and VoiceOver, validate the major user journeys.
Deliverable. Manual findings report
-
03
Mobile and zoom testing
Test on real mobile with TalkBack or VoiceOver, validate 200% and 400% zoom reflow.
Deliverable. Mobile and zoom findings
-
04
Remediation sprint
Fix in priority order: contrast, labels, keyboard, semantic HTML, focus management.
Deliverable. Patched site with re-run automated scan
-
05
Report and handover
Write WCAG 2.2 AA conformance report, VPAT-style summary, and maintenance runbook.
Deliverable. Conformance report and runbook
Common mistakes
The first mistake is relying on automated tools alone. Axe-core, Lighthouse and Pa11y catch the easy 30 to 40%. The other 60%. Illogical tab order, unannounced live regions, modal focus traps, illogical heading hierarchy. Only manual testing finds. A site that passes automated checks but fails manual checks is not WCAG conformant.
The second mistake is buying an accessibility overlay. AccessiBe, UserWay, accessiBe and similar overlay tools claim to make any site conformant by injecting a JavaScript widget. The accessibility community has consistently shown these tools fail real screen reader users and have been the subject of US ADA lawsuits. They are a marketing solution to an engineering problem. Fix the source.
The third mistake is treating WCAG as a one-time pass. A conformant site degrades within months as new components, marketing pages, blog templates and integrations deliver without the accessibility check baked in. We always recommend a quarterly mini-audit and a CI gate (e.g., axe-core in Playwright) that fails the build on new violations.
The fourth mistake is removing the focus outline. Designers sometimes ask to remove outline: none because the default browser focus ring “does not match the brand.” The right answer is to design a brand-aligned focus style, not to remove focus entirely. A site without visible focus is keyboard-hostile and fails 2.4.7 Focus Visible.
- 15%Share of audience with a disability affecting web use
- 30–40%WCAG failures caught by automated tools alone
- 4.5:1Required contrast for body text at AA
- 50+WCAG 2.2 success criteria at AA level
Tools we deliver in
- axe-core
- Pa11y
- Lighthouse Accessibility
- NVDA
- VoiceOver
- WebAIM Contrast Checker
- Stark
- TalkBack
- Playwright Axe
- Wave
- Microsoft Accessibility Insights
What it costs in Singapore (and what SGBP charges)
A WCAG 2.2 AA audit on a typical 30 to 60 page Singapore SME site runs S$2,000 to S$5,000 standalone. Audit plus remediation runs S$6,000 to S$18,000 at most Singapore agencies. SGBP delivers audit plus remediation as a fixed two-week sprint at S$3,000 to S$9,000. Around half the typical local rate. With a written conformance report and a maintenance runbook.
Frequently asked questions
What does WCAG 2.2 AA mean?
WCAG 2.2 is the Web Content Accessibility Guidelines version 2.2, published by W3C in October 2023. AA is the middle conformance level. A is minimum, AA is the practical industry standard, AAA is aspirational. WCAG 2.2 added nine new criteria covering focus visibility, drag motion alternatives, target size and help mechanisms. AA conformance is the bar most Singapore government tenders and enterprise procurements require.
Is WCAG mandatory in Singapore?
For government websites, GovTech requires conformance with WCAG 2.1 AA (moving to 2.2 in phases) under the Digital Service Standards. For commercial sites, WCAG is not strictly mandatory but is increasingly required by enterprise procurement, large customers and listed company governance. A growing number of Singapore SMEs are also subject to WCAG via their international clients.
How long does a WCAG audit take?
A focused WCAG 2.2 AA audit on a 30-page site takes one to two weeks: automated scanning with axe-core or Pa11y, manual testing with keyboard and screen reader, colour contrast checks, mobile testing, and a prioritised remediation report. Larger sites or those with complex applications (configurators, account areas) take three to four weeks.
What does WCAG remediation cost in Singapore?
A WCAG 2.2 AA audit plus remediation for a typical 30 to 60 page Singapore SME site runs S$6,000 to S$18,000 at most agencies. The audit alone is S$2,000 to S$5,000. SGBP runs the audit-plus-remediation as a fixed-scope sprint at S$3,000 to S$9,000. Around half the typical local rate.
Will an accessibility overlay solve compliance?
No. Overlays like AccessiBe, UserWay and accessiBe are widely criticised by the accessibility community and have been the subject of US ADA lawsuits. They paper over poor underlying HTML rather than fixing it. The correct path is fixing the source. Semantic HTML, ARIA where appropriate, keyboard navigation, contrast. Not bolting an overlay on top.
If you have a government tender, an enterprise procurement, or simply a brand standard that demands real WCAG 2.2 AA conformance, message us on WhatsApp or book a call. We run audits and remediation as fixed-scope sprints with written reports your procurement team can use directly.
