How to Design for Web Accessibility

Designing for web accessibility means making interfaces that anyone can perceive, operate, and understand — including the roughly 1.3 billion people worldwide living with a significant disability and the 1 in 4 U.S. adults the CDC reports as having a disability that affects major life activities. Inclusive design is also the law in a growing list of jurisdictions: the U.S. DOJ’s April 2024 Title II rule (with its April 2026 Interim Final Rule extending deadlines to April 26, 2027 for state and local governments serving 50,000+ residents and April 26, 2028 for smaller jurisdictions), the European Accessibility Act (enforcement since June 28, 2025), and Canada’s Accessible Canada Act all reference WCAG 2.1 or 2.2 Level AA as the technical baseline.

This guide focuses on what designers control: the visual and interaction decisions that get baked into mockups long before a developer touches code. Each section maps a design pattern to the specific WCAG 2.2 success criteria it satisfies, with current tool recommendations and 2026 legal context where relevant.

Provide sufficient contrast between foreground and background

Contrast is the single most cited accessibility issue on the web. WebAIM’s 2024 Million analysis found that 81% of home pages had low-contrast text, making it the most common WCAG failure year after year. Insufficient contrast hurts users with low vision, color blindness, aging eyes, and anyone reading on a phone in sunlight.

WCAG 2.2 sets two key thresholds:

• 1.4.3 Contrast (Minimum) — AA: 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold and above).
• 1.4.11 Non-text Contrast — AA: 3:1 for UI components and meaningful graphics, including form input borders, button outlines, and icon-only controls.

Test contrast at design time, not after handoff. The WebAIM Contrast Checker, the Stark plugin (Figma, Sketch, Adobe XD), Figma’s built-in Able plugin, and Adee all flag failing pairs as you work. For brand colors that fail at small sizes, increase weight, increase size, or pair them with a darker accessible neighbor for body copy.

Don’t use color alone to convey meaning

Roughly 1 in 12 men and 1 in 200 women have some form of color-vision deficiency. A red “error” outline that looks identical to the gray default for a deuteranope, or a green “success” checkmark that disappears for a protanope, is functionally invisible. WCAG 2.2 Success Criterion 1.4.1 Use of Color (A) requires that color never be the only means of communicating information, indicating an action, prompting a response, or distinguishing a visual element.

Pair color with a second cue:

• Form errors: red border plus an icon and a text message.
• Required fields: an asterisk plus “required” text or an explicit label.
• Charts: distinct shapes, patterns, or direct labels in addition to color.
• Links inside body text: underline by default, not just a color change.

Simulate color blindness with the Stark simulator, Sim Daltonism (macOS), or Chrome DevTools’ Rendering panel (“Emulate vision deficiencies”) before shipping any design that leans on color.

Make interactive elements obvious and easy to identify

Buttons that look like text and links that look like body copy force users to hunt for what’s clickable. That hunting is exhausting for users with cognitive disabilities, slow for screen-magnifier users, and impossible for users who can’t see hover states.

Use consistent visual treatment across the site so users learn your interaction language once. Buttons should look like buttons, links should look like links, and both should have clearly distinguishable focus, hover, and active states. Two WCAG 2.2 criteria are particularly relevant here:

• 2.4.7 Focus Visible (AA): the keyboard focus indicator must be visible.
• 2.4.11 Focus Not Obscured (Minimum) — AA (new in WCAG 2.2): when a component receives focus, it can’t be entirely hidden by sticky headers, cookie banners, chat widgets, or other overlapping content. Audit every fixed/sticky element in your design system against this rule.

Touch targets get their own rule. WCAG 2.5.8 Target Size (Minimum) — AA (new in WCAG 2.2) requires interactive targets to be at least 24×24 CSS pixels, with exceptions for inline links and equivalents. The earlier AAA-level 2.5.5 still recommends 44×44 pixels, which Apple’s HIG and Google’s Material guidelines both endorse — use 44×44 as your default and treat 24×24 as the absolute floor.

Provide clear and consistent navigation options

Predictable navigation helps everyone, especially users with cognitive disabilities or those navigating with assistive technology. WCAG 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification require menus, search boxes, and repeated components to appear in the same place and be labeled consistently across pages.

WCAG 2.2 added 3.2.6 Consistent Help (A): if you offer help mechanisms (contact info, a help link, a self-service chatbot, or human-support contact details), they have to appear in the same relative order on every page where they exist. A “Need help?” link that lives in the header on one page and the footer on the next is now a Level A failure.

Other essentials:

• Provide multiple ways to find content (search, sitemap, structured navigation) — 2.4.5 Multiple Ways (AA).
• Use clear, descriptive page titles and headings — 2.4.2 and 2.4.6.
• Make link text describe its destination on its own. “Click here” and “Read more” fail this when read out of context — 2.4.4 Link Purpose (In Context).

Design forms with explicit labels and helpful instructions

Forms are where many users with disabilities give up. The fixes are well-known and entirely under the designer’s control:

• Visible, persistent labels for every field — never placeholder-only. Placeholder text disappears on input, fails contrast more often than not, and is invisible to many screen readers.
• Position labels close to their fields and group related fields with fieldset + legend — 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions.
• Use the right input types and the autocomplete attribute so password managers and assistive tech can fill fields automatically — 1.3.5 Identify Input Purpose (AA).
• Don’t make users re-enter the same information across a multi-step form. WCAG 3.3.7 Redundant Entry — A (new in WCAG 2.2) requires previously entered information to be either auto-populated or available for the user to select.

For login and account flows, 3.3.8 Accessible Authentication (Minimum) — AA (new in WCAG 2.2) deserves attention: cognitive function tests like memorizing a password, transcribing a code, or solving a puzzle can’t be the only way to authenticate. Provide alternatives such as password manager autofill, copy-paste support, biometric login, or magic-link email.

Provide easily identifiable feedback

When something happens — a form submits, a record saves, an error blocks a step — users need to know. Sighted users may catch a small toast in the corner of the screen; screen-reader users won’t unless you build for them.

Design feedback that is:

• Visible: high-contrast, near the trigger, persistent long enough to read.
• Programmatically announced: use ARIA live regions or properly associated error messages so assistive tech speaks the change. WCAG 4.1.3 Status Messages (AA) codifies this.
• Specific: “Email is required” beats “Please complete the form.” 3.3.1 Error Identification and 3.3.3 Error Suggestion require errors to be identified in text and, where possible, suggest a correction.
• Recoverable: for legal commitments, financial transactions, and data deletions, give users a way to review, confirm, or reverse — 3.3.4 Error Prevention.

Use headings and spacing to group related content

A clear visual hierarchy helps every user scan the page and helps screen-reader users navigate by heading (“H” key in JAWS/NVDA, rotor in VoiceOver). Designers control this through both visible structure and the underlying semantic markup they instruct developers to ship:

• Use one H1 per page, then nest H2 → H3 → H4 in logical order. Don’t skip levels for visual styling — restyle the heading rather than picking a level by size.
• Use enough white space to separate sections. 1.4.12 Text Spacing (AA) sets minimums for line height, paragraph spacing, letter spacing, and word spacing that designs must accommodate without breaking.
• Group related controls visually and in code — fieldset/legend for forms, regions and landmarks for page structure (main, nav, aside, footer).

Design for different viewport sizes and zoom levels

Responsive design is accessibility. A user with low vision who relies on 200% browser zoom shouldn’t have to scroll horizontally to read body text, and a user on a small screen shouldn’t lose access to navigation or controls.

WCAG criteria to design against:

• 1.4.4 Resize Text (AA): text scales up to 200% without loss of content or functionality.
• 1.4.10 Reflow (AA): content reflows in a single column at 320 CSS pixels wide (equivalent to 400% zoom on a 1280-pixel-wide screen) without horizontal scrolling, except for content that genuinely requires two-dimensional layout (maps, complex tables, code blocks).
• 1.3.4 Orientation (AA): don’t lock content to a single orientation unless essential. A user with a wheelchair-mounted tablet may not be able to rotate the device.

Build mockups in fluid containers, not fixed widths. Test at 320px, at 200% zoom, and at common breakpoints. Figma’s auto-layout and variables features make responsive intent explicit at design time so it doesn’t have to be reverse-engineered in code.

Provide alternatives and controls for non-text and time-based content

Images, audio, and video need text equivalents:

• Images: meaningful images need alt text that conveys the same information; decorative images get alt="" so screen readers skip them — 1.1.1 Non-text Content (A).
• Video: synchronized captions for prerecorded video — 1.2.2 Captions (A); audio descriptions for visual information not conveyed in the soundtrack — 1.2.5 Audio Description (AA).
• Audio: a transcript for podcasts and audio-only content — 1.2.1 Audio-only and Video-only (Prerecorded).
• Live media: live captions for live-streamed video — 1.2.4 Captions (Live) (AA).

Caption tools have improved dramatically: YouTube’s auto-captions, Otter.ai, Rev, 3Play Media, and Descript all produce solid first drafts, but a human review pass is still required for accuracy, especially for technical terminology and proper nouns.

Give users control over auto-starting and animated content

Auto-playing video, parallax animations, looping carousels, and motion-heavy hero sections cause real harm to users with vestibular disorders, attention-related disabilities, and photosensitivity. The relevant criteria:

• 2.2.2 Pause, Stop, Hide (A): for moving, blinking, scrolling, or auto-updating content lasting more than 5 seconds, give users a way to pause it.
• 1.4.2 Audio Control (A): if audio plays automatically for more than 3 seconds, provide a way to pause, stop, or control the volume.
• 2.3.1 Three Flashes or Below Threshold (A): nothing flashes more than three times per second.
• 2.3.3 Animation from Interactions (AAA): respect the prefers-reduced-motion media query. Many design systems now treat this as a baseline, not an aspirational AAA target.

Default to not autoplaying anything. If the design calls for motion, provide an obvious pause control and honor reduced-motion preferences in code.

Replace traditional CAPTCHAs with accessible alternatives

Image- and audio-based CAPTCHAs have been an accessibility failure for two decades. They’re hard for users with visual or hearing impairments, exhausting for users with cognitive disabilities, and increasingly unreliable as bots have gotten better at solving them than humans.

WCAG 2.2’s new 3.3.8 Accessible Authentication (Minimum) — AA applies here. While it’s framed around login, the principle — don’t require a cognitive function test as the only path forward — extends to bot-detection challenges. Modern alternatives:

• Invisible/risk-based detection: Cloudflare Turnstile, hCaptcha’s no-interaction mode, Google’s reCAPTCHA Enterprise risk scoring — these analyze behavior and device signals without challenging the user at all.
• Honeypot fields: hidden form fields that bots fill in but humans don’t see.
• Email or phone verification: a one-time code delivered to a verified address.
• Passkeys / biometric: modern device-bound authentication that’s both more accessible and more secure than passwords plus CAPTCHAs.

If you must use a visible challenge, always offer at least two alternative formats (image and audio and a logic question, for example) and never rely on a single sensory or cognitive test.

Tools that help designers build accessibly

Modern design tooling has caught up with accessibility expectations. Useful additions to any designer’s toolkit:

• Stark (Figma, Sketch, Adobe XD): contrast checking, color-blindness simulation, focus-order annotations, alt-text fields.
• Able (Figma): contrast and color-blindness checks built into the design surface.
• A11y Annotation Kit (Figma): standardized markup for design specs so engineers receive accessibility intent, not just visuals.
• Adee (Figma): contrast, touch-target size, and color-blindness checking in one plugin.
• Include — Inclusive Design Library: pattern library focused on inclusive UX components.
• Polypane: a development browser that simultaneously renders multiple breakpoints, contrast modes, and assistive-tech overlays.

Frequently asked questions

Do I have to design to WCAG 2.2 now, or is 2.1 still acceptable?

Most current laws still cite WCAG 2.1 Level AA — the U.S. DOJ Title II rule, EN 301 549 v3.2.1, and the EAA all reference 2.1. WCAG 2.2 was published October 5, 2023 and is a strict superset of 2.1, so designing to 2.2 satisfies any 2.1 requirement plus the nine new criteria. Use 2.2 as your design target; it’s the safer floor.

Do I really need separate focus and hover states?

Yes. Hover only fires for mouse users; focus is what keyboard users see. They can share visual treatment, but the focus state must be present and meet 1.4.11 Non-text Contrast (3:1 against the adjacent background).

What’s the minimum touch target size in 2026?

WCAG 2.5.8 sets the AA minimum at 24×24 CSS pixels. Apple’s HIG and Google’s Material guidelines both recommend 44×44. Design to 44×44 wherever possible.

Are accessibility overlays a substitute for accessible design?

No. The FTC’s January 2025 consent order against accessiBe ($1 million fine and a ban on deceptive performance claims) and a long line of lawsuits make clear that overlays don’t make a non-accessible site compliant. Build accessibility into the design; don’t bolt it on at runtime.

How do I get stakeholders to invest in accessibility design work?

Lead with three things: legal exposure (DOJ Title II 2027/2028 deadlines, EAA enforcement, ADA Title III lawsuit volume), audience size (1.3B globally; 1-in-4 U.S. adults), and the cost differential between fixing accessibility in design (cheap) vs. retrofitting after launch (expensive). The business case is now clear enough that accessibility belongs in design system specs and acceptance criteria, not in a post-launch audit.

The bottom line

Accessible design isn’t a separate practice — it’s the practice of designing for the actual range of people who will use what you build. WCAG 2.2 gives you a checklist; tools like Stark, Able, and Polypane make it cheap to verify; and 2026’s legal landscape (DOJ Title II, EAA, ACA) makes the cost of skipping it real. Bake the criteria above into your design system, your component library, and your design-review rubric, and accessibility stops being an afterthought and starts being the default.