Web Accessibility Guidelines Every UI/UX Designer Should Know

Accessibility is one of those things designers know they should care about and still find easy to deprioritize. It shows up late in the process — in QA, in an audit, or when a real user reports a problem — rather than being baked into the design decisions made on day one.

That's mostly a knowledge problem, not a motivation problem. Most designers who understand what accessible design actually requires find it straightforward to apply. It doesn't mean designing ugly, constrained, or "boring" interfaces. It means designing ones that work for more people.

This guide covers the practical guidelines every UI/UX designer should have internalized — not as a compliance checklist, but as design craft.

What is web accessibility?

Web accessibility is the practice of designing and building digital products so that people with visual, auditory, motor, or cognitive disabilities can use them fully and independently. The governing standard is the Web Content Accessibility Guidelines (WCAG), published by the W3C. WCAG 2.2 is the current widely-adopted version; WCAG 3.0 is in active development.

Accessibility is also a legal requirement in many jurisdictions. In the US, the ADA covers digital products. The EU has the European Accessibility Act (EAA), with enforcement beginning in June 2025. In practice, meeting WCAG 2.1 AA covers the legal baseline for most markets.

The POUR principles

WCAG is organized around four core principles, abbreviated POUR:

Perceivable — information and UI components must be presentable in ways users can perceive. Text alternatives for images, captions for video, content that doesn't rely only on color to convey meaning.

Operable — all functionality must be operable via keyboard, with enough time, without causing seizures or physical discomfort. No keyboard traps, no content that flashes more than three times per second.

Understandable — content must be readable, predictable, and provide input assistance. Labels on forms, consistent navigation, clear error messages.

Robust — content must be robust enough to be interpreted by assistive technologies — screen readers, braille displays, voice control. This is largely about semantic HTML and ARIA, which developers implement, but designers set the stage for it.

Color contrast

This is where most designs fail accessibility — and it's entirely within the designer's control.

WCAG 2.2 AA requires:

• 4.5:1 contrast ratio for normal text (below 18pt regular or 14pt bold)
• 3:1 for large text (18pt regular or 14pt bold and above)
• 3:1 for UI components and graphical elements (button outlines, form field borders, chart lines, icons that carry meaning)

Common mistakes:

• Light gray on white — popular in minimal design, often fails. #767676 on white is exactly 4.5:1; anything lighter fails.
• Color as the only status indicator — a red/green toggle that only uses color to show state fails for users with color blindness. Add a label, icon, or pattern.
• Disabled state over-dimming — WCAG exempts disabled elements from contrast requirements, but overly dim disabled states confuse users. Aim for 3:1 anyway.

Focus states

Focus states are the visual indicators that tell keyboard users where they are on the page. The single most common accessibility failure in polished UIs is the removed focus ring.

Designers often remove the browser's default focus outline because it looks inconsistent with the design. That's valid — but the fix is to replace it with a custom one, not remove it entirely.

WCAG 2.2 AA (Success Criterion 2.4.11) now requires a minimum focus indicator that:

• Has an area of at least the perimeter of the component multiplied by 2px
• Has a contrast ratio of at least 3:1 between focused and unfocused states

In practice, design a focus style for every interactive element:

• Buttons — a 2–3px offset outline, typically in your brand's primary color or a high-contrast offset ring
• Links — visible focus that doesn't rely solely on the underline
• Form inputs — a border color change plus an outer glow or ring
• Cards and panels — a prominent ring that matches the component's outer shape

Define these states as a component variant in Figma. Hand off explicitly — developers who don't see focus states in the design file will default to outline: none.

Semantic structure

Semantic structure is primarily a development concern, but designers create the information hierarchy that developers implement. When the hierarchy is wrong in the design, it ends up wrong in the code.

Heading levels — use one H1 per page (the page title). Use H2 for major sections, H3 for subsections inside those sections. Don't skip levels. Screen readers navigate by heading — a page with all H2s is a page with no discernible structure.

Reading order — the reading order of the page must make sense when CSS is stripped away. Multi-column layouts with content that should be read top-to-bottom across columns need careful markup planning. If your visual layout depends on a complex reading order, annotate it in the Figma file.

Landmarks — every page should have a header, main, and footer landmark. Navigation should be wrapped in a nav element. Designers don't write this HTML, but annotating "this is the main navigation" in the handoff file ensures the developer implements it semantically.

Alternative text for images

Every image that conveys information needs an alt text description. Images that are purely decorative should have empty alt text (alt="") so screen readers skip them.

As a designer, your job is to indicate intent:

In Figma, add alt text notes to the annotation layer or in the component description. Token Studio and some design handoff tools support alt text fields directly.

Accessible forms

Forms are among the most common accessibility failure points on the web. The checklist for designers:

• Every input needs a visible label. Placeholder text is not a label — it disappears when the user starts typing. A floating label pattern can work if the label remains visible during input.
• Error messages must be specific. "Invalid input" is useless. "Email address must include an @ symbol" is useful. Design the error state with real error messages, not placeholders.
• Required fields should be indicated visually and with more than just an asterisk. Use both an asterisk and the word "(required)" for new audiences.
• Group related fields. A date picker with three fields (day, month, year) should be grouped with a single label, not three separate floating labels.
• Success state. Design a confirmation state for every form submission. Users with cognitive disabilities and users on slow connections need explicit confirmation that their action succeeded.

Designing for keyboard and screen reader users

Most designers don't use screen readers regularly, which makes it easy to design interfaces that are visually polished but navigably broken.

Three principles to keep front of mind:

Don't trap keyboard users. Dialogs, dropdowns, and custom widgets must have a clear, keyboard-accessible way to open and close. Annotate expected keyboard behavior (Escape to close, Tab to move between options, Enter to select) in your handoff.

Avoid hover-only interactions. If something is only revealed on hover — a tooltip with critical information, a "delete" button that appears on hover over a card — it is inaccessible to keyboard and touch users. Design a persistent or focus-triggered equivalent.

Respect motion preferences. Some users have vestibular disorders that make animations nauseating. Design animations as an enhancement, not a requirement, and annotate that they should respect the prefers-reduced-motion media query.

A quick self-audit before handoff

Before you hand a design file to development, run through this list:

• All text meets 4.5:1 contrast (or 3:1 for large text)
• All UI components meet 3:1 contrast
• Color is never the only indicator of meaning
• Every interactive element has a designed focus state
• Heading levels are logical and not skipped
• Every image has an alt text annotation
• Every form field has a visible label
• Hover-only interactions have a keyboard-accessible equivalent
• Dialogs and modals have annotated keyboard behavior

The bottom line

Accessible design is good design. The constraints it imposes — sufficient contrast, visible focus states, clear structure, real labels — are the same constraints that make interfaces easier for everyone, including users in challenging lighting, users on their first visit, and users in a hurry.

None of these guidelines require sacrificing aesthetics. They require intentionality: knowing the rules, applying them from the start, and handing off files that make them easy for developers to implement correctly.

If you need a design built by a team that treats accessibility as a first-class requirement, not an afterthought, explore our services — or get a free quote and let's talk about your project.