Web Accessibility in 2026: Why WCAG Compliance Is Now a Must

In January 2026, Solaris Home Goods — a Singapore-headquartered home furnishings retailer shipping to the US, UK, and Australia with roughly 92,000 monthly visitors — received a demand letter from a law firm representing a blind customer in California who had tried three separate times to complete a checkout using JAWS screen-reading software. The shipping-address form had no programmatically associated labels, the "Add to Cart" button read aloud only as "button," and a promotional pop-up could not be dismissed with the Escape key, trapping keyboard-only users inside it indefinitely. The letter cited Title III of the Americans with Disabilities Act and gave the company 30 days to remediate before litigation would proceed.

Solaris is far from an outlier. The company's legal team ultimately settled for $38,000 in damages and attorney's fees, on top of an emergency audit and remediation sprint that cost another $52,000 — a bill that would have been a fraction of that size had accessibility been built in from day one. Worse, when the product team dug into analytics during the audit, they discovered that 15% of users who abandoned checkout without completing a purchase were landing on pages with critical keyboard traps or missing form labels — a segment worth an estimated $1.4 million in annual revenue that had simply been locked out by preventable code-level mistakes.

What web accessibility and WCAG compliance actually mean

Web accessibility is the practice of designing and building websites, apps, and digital products so that everyone can use them — including people with visual, auditory, motor, or cognitive disabilities. The reference standard worldwide is the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, published by the World Wide Web Consortium (W3C). WCAG 2.2 AA is the technical backbone cited by the Americans with Disabilities Act (ADA) in the US, the European Accessibility Act (EAA) in the EU, the Accessibility for Ontarians with Disabilities Act in Canada, and equivalent regulations in the UK, Australia, and increasingly across Asia.

WCAG 2.2 rests on four principles known as POUR: Perceivable (content must be presentable in more than one sensory channel — visually and through screen readers or braille displays), Operable (every function must work via keyboard alone, not just mouse or touch), Understandable (navigation and language stay consistent and predictable across the site), and Robust (the code works reliably across assistive technologies, from JAWS and NVDA screen readers to switch devices and voice-control software).

Compare that to a typical "normal" website built without accessibility in mind: product images with no alt text, light-gray text on white backgrounds that's unreadable in direct sunlight, forms that only respond to mouse clicks, tutorial videos with no captions, and promotional modals that trap keyboard users with no visible way out. For most visitors, that's mildly annoying. For the roughly 1.3 billion people living with a disability worldwide, it means the site simply doesn't work — the digital equivalent of a storefront that locks its door the moment they approach.

The real cost of an inaccessible website

• Legal exposure keeps climbing: ADA Title III website lawsuits filed in US federal courts have exceeded 4,500 per year in recent years, and plaintiffs' firms increasingly target mid-market e-commerce sites, not just Fortune 500 companies. The EU's European Accessibility Act became fully enforceable on June 28, 2025, requiring e-commerce, banking, and other digital services operating across the 27 member states to meet EN 301 549 (equivalent to WCAG 2.1 AA), with penalties that vary by country. Any company selling into the US or EU — including Southeast Asian exporters and SaaS vendors — now carries the same legal exposure as a domestic business.
• Losing customers at scale: Per World Health Organization data, roughly 15-16% of the world's population — more than 1.3 billion people — lives with some form of disability. That's not a niche market; it's larger than the population of most countries combined. An inaccessible website closes the door on this entire segment, plus the family members and caregivers who influence their purchasing decisions.
• SEO and AI-search penalties: The same semantic HTML that makes a site accessible — structured headings, descriptive alt text, explicit form labels — is exactly what Google's crawler and AI-driven search engines like ChatGPT Search and Perplexity rely on to parse and summarize content. Sites with messy, non-semantic markup are harder to crawl and harder for AI systems to cite, costing visibility in both traditional and generative search simultaneously.
• Reputational damage that's hard to reverse: A viral social post showing a disabled customer unable to complete checkout, tagged with the brand's handle, can spread faster than any official marketing campaign, and it can take years of sustained effort to undo the "we don't care about accessibility" label once it sticks.
• Retrofitting costs far more than building accessible from day one: Industry research consistently shows that fixing accessibility defects after launch costs 6 to 10 times more than designing for accessibility from the start, because teams must retroactively rebuild component structures, design systems, and QA workflows that were never architected with assistive technology in mind.

Core features a truly accessible website or app must have

• Semantic HTML and correct ARIA landmarks: Proper use of tags like <nav>, <main>, and <header>, plus ARIA landmark roles, lets screen reader users understand page structure at a glance and jump directly to relevant sections instead of listening to the entire page top to bottom.
• Full keyboard navigation with no focus traps: Every interactive element — buttons, links, forms, dropdown menus, modals — must be reachable and operable using only Tab, Enter, Space, and arrow keys, with a clearly visible focus indicator, and without trapping users inside a single component.
• Minimum 4.5:1 color contrast: Body text against its background must meet at least a 4.5:1 contrast ratio (3:1 for large text) per WCAG 2.2 AA, so it stays legible for users with low vision, color blindness, or anyone reading a phone screen in bright sunlight.
• Screen-reader-compatible forms and alt text: Every form input needs an explicitly, programmatically associated label, helper text that gets announced by assistive technology, and every informative image needs descriptive alt text — not a filename like "IMG_2044.jpg."
• Captions and transcripts for video and audio content: All video needs synchronized captions and ideally a full text transcript — essential for deaf and hard-of-hearing users, and useful for anyone watching on mute in a public space.
• Text that resizes up to 200% without breaking layout: Low-vision users frequently zoom browser text to 200%; a well-built responsive layout must stay legible and not clip content or overlap elements when text scales up significantly.
• Clear error messages and proper focus management: When a form submission fails, focus should move directly to the error message, the message should describe the specific problem (not just "An error occurred"), and the fix should be clearly explained in a way screen readers can announce.

Retrofitting an old site vs. building accessible from scratch

Many business owners are tempted by "one line of JavaScript" accessibility overlays and widgets that promise instant, automated WCAG compliance. In practice, these tools typically patch surface-level symptoms without fixing the underlying HTML structure, and in recent years overlays have become the target of their own wave of lawsuits in the US — disability advocates argue overlays can actively interfere with a user's own pre-configured assistive technology, making the experience worse rather than better. Several companies have been sued specifically after installing an overlay, on the grounds that it constituted fake compliance rather than a genuine fix.

A full manual retrofit — a certified auditor's manual review, component-level code fixes, and usability testing with actual disabled users — still makes sense for a site whose foundation is generally sound but needs targeted work on a handful of critical flows, like checkout or account registration. But for older sites built on outdated frameworks, without a consistent design system, or carrying years of accumulated technical debt, rebuilding from scratch with accessibility as a first-class design principle from day one is usually cheaper and faster in the long run — and it doubles as a natural opportunity to modernize the underlying technology stack at the same time.

Cost and timeline ranges

For the Indonesian market, an accessibility audit and remediation project for a mid-size business website — say, an online store with a product catalog, checkout flow, and customer account portal — typically runs Rp 40 million to Rp 90 million for a full audit plus fixes to core components, over a 2-3 month timeline. A full rebuild of a more complex web application or portal — multi-role dashboards, payment integrations, multilingual support, reporting modules — runs Rp 120 million to Rp 250 million over 3-5 months, depending on page count, transaction-flow complexity, and target conformance level (AA for most sectors, AAA for sensitive sectors like banking and healthcare).

For international context, businesses operating primarily in the US, UK, or EU should expect broadly comparable indicative ranges: a targeted audit and remediation for a mid-size site commonly falls between $8,000 and $25,000, while a full accessible rebuild of a more complex application can run $40,000 to $150,000 or more, with agencies in London, New York, or Berlin often pricing at the higher end of that band due to labor costs — which is precisely why many international companies now work with software houses like AFSS in Indonesia to get equivalent WCAG 2.2 AA-conformant work at a materially lower cost without compromising quality.

Case study: Solaris Home Goods

Following its settlement, Solaris Home Goods commissioned a full four-month accessibility remediation covering a WCAG 2.2 AA audit, a rebuild of its checkout and account-registration components, full site-wide keyboard support, and a content-team training program on writing meaningful alt text and accessible product descriptions. The results were substantial: checkout page bounce rate dropped 24%, accessibility-related support tickets fell 58% within the first quarter after launch, the original legal complaint closed with no further litigation, and overall conversion rate rose 11% — driven largely by older users and low-vision customers who previously couldn't complete a purchase at all. The company also began appearing more frequently in AI-generated shopping summaries after cleaning up its semantic HTML, an unplanned but welcome SEO side effect.

Key metrics to track after implementation

• Automated WCAG audit score, using tools like axe DevTools or Lighthouse Accessibility, tracked as a quantitative baseline on every release.
• Keyboard-only task completion rate, measured through periodic usability testing to confirm critical flows like checkout and signup can be completed without a mouse.
• Screen reader user session duration, benchmarked against average users — unusually long sessions or high exit rates signal unresolved navigation barriers.
• Accessibility-related support ticket volume, the most honest direct signal of real problems users are encountering in the field each month.
• Organic search visibility change, since cleaning up semantic HTML structure frequently correlates with improved rankings and increased citations in AI search summaries.

Implementation challenges and how to handle them

The most common obstacle is a legacy design system built without adequate color contrast or sufficiently large touch targets. The fix isn't a full brand overhaul — it's auditing the existing color palette and core components, then centralizing changes through design tokens so updates propagate consistently across the entire product without manually touching every single page.

The second major obstacle is third-party embedded widgets — live chat plugins, embedded survey forms, map embeds, external video players — that are frequently built without accessibility in mind and sit outside a development team's direct control. The practical fix is evaluating third-party vendors explicitly on accessibility conformance before integrating them, and providing an equivalent alternative path — a phone number or email address, for instance — for any feature that isn't yet fully accessible.

The third challenge is sustainability: accessibility isn't a one-time project that ends at launch, it's an ongoing discipline that content, design, and engineering teams need to maintain continuously. Every new blog post, seasonal promotional banner, or product feature can reintroduce accessibility problems if teams aren't properly trained and there's no QA process that treats an accessibility check as a standard release gate rather than an afterthought.

Your website might look perfectly fine on your own screen — but the real question is whether it actually works for the 1.3 billion people worldwide living with a disability, including potential customers who may have already quietly switched to a competitor. Rather than waiting for the first demand letter to land on your legal team's desk, start with a full accessibility audit of your current site or app. AFSS can help you design and build digital products that are genuinely inclusive from the ground up — check our pricing for accessibility audit and remediation packages, or go ahead and submit your project for an initial consultation with our team.