Web Accessibility (WCAG) for Real Products: A Practical Guide
What WCAG 2.2 AA actually requires, the defects that break real products, and how to build accessibility in without slowing delivery.
A customer opens your checkout page on their phone, taps the "Pay now" button, and nothing happens — because they navigate with a screen reader and the button was built as a styled <div> with no role and no label. They abandon the cart. You never see why, because analytics only records that another session bounced.
This is what inaccessible software costs in practice: lost revenue, support tickets, and in a growing number of markets, legal exposure. Web accessibility is not a charity feature you bolt on at the end. It is a quality attribute of the product, the same way performance and security are. This article explains what WCAG actually asks for, where teams trip up, and how to build accessibility into real products without slowing delivery to a crawl.
What WCAG actually means
WCAG stands for the Web Content Accessibility Guidelines, maintained by the W3C. It is the reference standard that almost every accessibility law and procurement requirement points to, from the European Accessibility Act to US Section 508 to Saudi Arabia's digital government standards. When someone says "we need to be a11y compliant," WCAG is what they mean, whether they know it or not.
The guidelines are organized around four principles, often abbreviated POUR:
- Perceivable — users can perceive the content. Images have text alternatives, video has captions, contrast is high enough to read.
- Operable — users can operate the interface. Everything works with a keyboard, nothing flashes dangerously, targets are large enough to hit.
- Understandable — the interface behaves predictably and errors are explained in plain language.
- Robust — the markup is clean enough that assistive technology can interpret it reliably, now and in the future.
WCAG has three conformance levels: A (minimum), AA (the practical target almost everyone aims for), and AAA (aspirational, rarely required across a whole product). For most commercial products, WCAG 2.2 Level AA is the right benchmark. It is what regulators expect and what enterprise buyers put in their contracts.
The defects that actually break products
In real codebases, accessibility failures cluster around a handful of recurring mistakes. Fix these and you eliminate the majority of issues an audit will find.
Non-semantic markup
The single most common problem is interactive elements built from generic containers. A <div onclick> is invisible to a keyboard and to a screen reader. Use the real element — <button>, <a>, <input> — and you get focus handling, keyboard activation, and the correct role for free. Reach for ARIA roles only when no native element fits.
Missing or wrong labels
Form fields without a connected <label>, icon buttons with no accessible name, and images with empty or decorative-but-undeclared alt text all leave users guessing. A magnifying-glass icon needs aria-label="Search"; a hero photo that adds nothing semantically should have alt="" so screen readers skip it.
Low contrast
Light gray text on white looks elegant in a mockup and is unreadable for many users, including anyone outdoors in GCC sunlight. AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. This is the easiest defect to catch and the most common one shipped.
Keyboard traps and invisible focus
If a user can tab into a modal but not out of it, or if the focus indicator has been removed with outline: none for aesthetic reasons, the interface becomes unusable without a mouse. Keep a visible focus state and make sure focus moves logically.
Color as the only signal
"Required fields are red" or "errors are highlighted in red" fails anyone with color blindness. Pair color with an icon, text, or pattern so the meaning survives without it.
Accessibility for Arabic and bilingual products
Teams building for the GCC and Egypt carry an extra responsibility that most generic accessibility advice ignores: right-to-left support and bilingual interfaces.
- Set the language and direction on the document:
<html lang="ar" dir="rtl">, and switch both when the user changes language. Screen readers uselangto choose the correct voice and pronunciation. - Use logical CSS properties (
margin-inline-start,padding-inline-end) instead of hard-coded left/right so layouts mirror correctly in RTL. - Test the actual Arabic experience with a screen reader, not just the English one. Mixed-direction content — an English brand name inside an Arabic sentence, or a price with Latin digits — is where bugs hide.
Frameworks like Next.js and Flutter both support directionality and localization well, but the defaults rarely cover bilingual edge cases on their own. They have to be exercised deliberately.
How to build it in without slowing down
Accessibility fails when it is treated as a final QA gate. By then the architecture has baked in the problems and fixing them means rework. The teams that succeed move the work earlier and automate the boring parts.
- Start in design. Specify contrast ratios, focus states, and minimum target sizes in the design system. If the component library is accessible, every screen inherits it.
- Lint and test in CI. Tools like axe-core, Lighthouse, and pa11y catch a large share of issues automatically on every pull request. They will not find everything, but they stop regressions for free.
- Test with the keyboard and a screen reader. Automated tools cannot judge whether a flow makes sense. Spend ten minutes navigating a feature with only the keyboard and with VoiceOver, NVDA, or TalkBack. Most serious defects surface immediately.
- Write component-level acceptance criteria. "The button is reachable by keyboard and announces its label" belongs in the ticket, not in a separate audit six months later.
Automated checks typically catch only part of real-world barriers; the rest require human judgment. Budget for both. Inclusive design is cheapest when it is continuous and most expensive when it is a one-time scramble before a launch or a legal deadline.
Key takeaways
- WCAG 2.2 Level AA is the practical compliance target for commercial products and the standard regulators and enterprise buyers expect.
- Most accessibility defects come from a short list: non-semantic markup, missing labels, low contrast, broken keyboard support, and color-only signals.
- Bilingual GCC and Egyptian products need deliberate RTL and
lang/dirhandling — accessibility and Arabic support are the same problem. - Build accessibility into the design system and CI pipeline; automated tools catch the easy issues, human testing catches the rest.
- Inclusive design is a quality attribute, not a feature — it pays back in retained customers, fewer support costs, and reduced legal risk.
Accessibility done right is invisible: it just means more people can use what you built, on more devices, in more conditions. If you want a product that meets WCAG without sacrificing speed or polish, SummationWorks can help — from accessibility audits of an existing site to building it in from the first commit. Explore our services, see our work, or get in touch to talk through your product.
About the author
Mazen Salah
Founder & Lead Engineer
Mazen Salah founded SummationWorks in 2019 to help startups and growing businesses ship real software. He leads engineering across the company's web, mobile, and AI work, building products with Next.js, Flutter, Laravel, and Node.
More about usRelated Articles
engineeringBuilding Fast Web Apps in 2026
How we ship production-grade web apps that load instantly and scale — the stack, the trade-offs, and the habits behind it.
engineeringAPI Rate Limiting and Abuse Protection: A Practical Guide
How API rate limiting and abuse protection keep your backend stable: throttling strategies, layered defenses, and limits that don't punish real users.
engineeringApp Store and Play Store Submission: How to Avoid Rejections
Most app rejections are preventable. A practical guide to clearing App Store and Play Store review on the first try, from privacy to payments.