Web Accessibility (WCAG): A Developer's Guide to Building Inclusive Apps

“

Meerako — We build 5.0★ applications that are accessible and inclusive for everyone.

Can someone using a screen reader navigate your forms? Can someone who's colorblind distinguish your buttons from your background? Can someone with a motor impairment complete checkout using only a keyboard? Web accessibility — often shortened to a11y — is the practice of building digital products that genuinely work for everyone, regardless of physical or cognitive ability, and in 2026 it's no longer a niche concern reserved for government contractors.

This isn't just an ethical consideration, though it is that. ADA-related digital accessibility lawsuits filed in U.S. federal court have grown substantially over the past several years, with plaintiffs' firms increasingly targeting mid-size e-commerce and SaaS companies rather than only large enterprises. Beyond legal risk, ignoring accessibility means excluding a meaningful share of potential customers — commonly cited estimates put people with disabilities at roughly one in four adults in the United States, according to CDC data, and that population controls significant real disposable income that inaccessible sites simply forfeit. The regulatory landscape has also tightened meaningfully: the DOJ's 2024 final rule under ADA Title II now sets explicit WCAG 2.1 Level AA compliance deadlines for state and local government websites and apps, and the European Accessibility Act, which took effect for covered private-sector products and services in June 2025, has pushed accessibility requirements into contracts and vendor-selection criteria well beyond the public sector.

At Meerako, accessibility is built into our design system and testing process from the start, not audited in afterward. This guide walks through what WCAG actually specifies, the practices that matter most in real code, and how accessibility becomes a durable part of a development process rather than a pre-launch scramble.

• What WCAG (Web Content Accessibility Guidelines) actually specifies, including what's new in WCAG 2.2.
• The four POUR principles that organize the entire standard.
• Five concrete, code-level practices every developer should apply by default.
• How accessibility gets built into a real development process, not bolted on before launch.
• The realistic cost and timeline of an accessibility remediation project.

WCAG is the global technical standard for web accessibility, maintained by the W3C's Web Accessibility Initiative and organized around four core principles — POUR.

Perceivable: information must be presentable in ways every user can actually perceive. Alt text on meaningful images, for instance, lets a screen reader describe visual content that would otherwise be invisible to that user entirely. Sufficient color contrast between text and background falls here too — WCAG AA requires a minimum 4.5:1 contrast ratio for normal text and 3:1 for large text.

Operable: interface elements must be usable without requiring an interaction a user physically can't perform. Full keyboard navigability — no mouse required anywhere on the site — is the clearest concrete example.

Understandable: both content and interface behavior need to be genuinely comprehensible, not just technically present. Clear language and helpful, specific error messages on forms are direct applications.

Robust: content needs to remain accessible as assistive technology evolves, which in practice means using correct, standard semantic HTML that screen readers and other tools can parse reliably, rather than custom markup that happens to work with today's specific tools.

WCAG defines conformance levels A, AA, and AAA — Level AA is the generally accepted target for most production websites, and the standard most commonly cited in legal proceedings and procurement contracts alike. WCAG 2.2, the current published version, added several new success criteria worth knowing specifically: a minimum target size for clickable/tappable elements (helping users with motor impairments avoid mis-taps), a requirement that focus indicators not be entirely obscured by sticky headers or other overlapping UI, and a requirement that any drag-based interaction (like a slider or reordering list) have a non-dragging alternative. These aren't abstract — they're the kind of criteria that get flagged in real audits of modern, JavaScript-heavy interfaces built with drag handles, floating action buttons, and sticky navigation.

1. Use Semantic HTML Correctly

The single highest-leverage practice. Don't build every interactive element as a styled <div> — use <button> for clickable actions, <a> for navigation links, <nav> for navigation regions, <main> for primary content, and <label> for form inputs. Screen readers depend on these elements to understand page structure; a div styled to look like a button conveys none of that structural meaning, no matter how convincing it looks visually. This one habit alone eliminates a large fraction of the accessibility bugs we find in code that wasn't built with a11y in mind from the start.

2. Provide Meaningful Alt Text

Every image conveying real information needs descriptive alt text. Purely decorative images should get an empty alt="" specifically so screen readers skip over them rather than announcing irrelevant visual noise. For complex images like charts or infographics, a short alt description paired with a longer text equivalent nearby (not just relying on the alt attribute to carry the whole burden) serves users far better.

3. Verify Full Keyboard Navigability

Test it directly: can every interactive element — links, buttons, form fields, modals, custom dropdowns — be reached via Tab in a logical order, and activated with Enter or Space? This single test, done by literally unplugging your mouse for ten minutes, catches a large share of common accessibility gaps immediately, often faster than running a full automated audit.

4. Manage Focus Deliberately

When a modal opens, keyboard focus needs to move into it explicitly and be trapped within it until closed; when it closes, focus should return to whatever triggered it. This requires deliberate JavaScript — it doesn't happen automatically — and its absence is one of the most common, disorienting accessibility failures in custom UI components, particularly in React and Vue apps where developers build modals from scratch rather than using a battle-tested accessible component library.

5. Use ARIA Sparingly, as a Last Resort

ARIA attributes (role="button", aria-label="Close", aria-expanded="true") patch accessibility gaps in genuinely complex custom components — a custom dropdown, a date picker, a tab interface. But the first rule of ARIA is not using it when semantic HTML would solve the same problem natively; overused or incorrectly applied ARIA introduces its own bugs when the implementation drifts from what the attribute promises, sometimes making a component less accessible than if no ARIA had been added at all.

Web accessibility standards don't stop at the browser. iOS and Android both ship robust built-in assistive technology — VoiceOver and TalkBack — and Apple's App Store and Google Play both surface accessibility as a review and discoverability factor in their own right. For teams building progressive web apps or native mobile apps, the same POUR principles apply, translated into platform-specific APIs: accessibility labels on custom controls, dynamic type support so text scales with a user's system font size preference, and sufficient touch target sizing — generally a minimum of 44x44 points on iOS and 48x48dp on Android — which maps directly onto WCAG 2.2's new target-size criterion for the web.

Tools like Axe, Lighthouse, and WAVE are genuinely useful and belong in every CI pipeline — they catch missing alt text, insufficient contrast ratios, missing form labels, and invalid ARIA usage automatically, on every pull request, without a human needing to remember to check. But it's worth being honest about their ceiling: automated tools reliably catch a meaningful but limited share of real accessibility issues, because things like logical focus order, whether an error message is genuinely understandable, or whether a screen reader user can actually complete a multi-step checkout flow require human judgment and real assistive-technology testing to verify. A mature accessibility process treats automated scanning as the floor, not the finish line, and pairs it with periodic manual testing using an actual screen reader (VoiceOver, NVDA, or JAWS) and real keyboard-only navigation.

Accessibility gets checked at every phase, not audited once before launch: design reviews color contrast and defines focus states from the first wireframe; development uses semantic HTML and builds keyboard navigation directly into shared design system components, so every feature inherits it automatically; and QA runs both automated accessibility scanning (tools like Axe) and manual keyboard and screen reader testing as a standard part of the release process, not an occasional special audit. This mirrors how we approach testing generally — accessibility checks are just another layer in the same pyramid, not a separate discipline bolted on afterward.

For an existing application that wasn't built with accessibility in mind, a genuine remediation project typically starts with a professional audit — either automated tooling paired with manual expert review, or in higher-stakes cases, testing with actual users of assistive technology — that produces a prioritized list of violations mapped to WCAG success criteria. Remediation work itself varies enormously with the size and complexity of the application, but the pattern we see consistently is that the first pass (fixing missing alt text, contrast issues, unlabeled form fields, and the most common semantic HTML gaps) resolves the majority of flagged issues relatively quickly, while the remaining fraction — complex custom components, focus management in dynamic interfaces, genuinely hard content restructuring — takes disproportionately longer per issue. Budgeting for an ongoing accessibility QA step in every future release cycle is far cheaper than treating remediation as a one-time project that then quietly decays as new features ship without the same rigor.

Web accessibility isn't a nice-to-have feature serving a small edge case — it's a fundamental requirement for a genuinely modern, ethical, and legally sound web application that actually works for everyone. Building it into your process from the first wireframe, not retrofitting it before a launch deadline, produces a better product for every user and meaningfully reduces real legal risk.

Ready to build an application that's beautiful, functional, and accessible to all?