Web Accessibility: A Designer’s Guide
Web accessibility is the practice of designing sites that everyone can use, including people who rely on screen readers, keyboards, magnification, or high contrast. It is not a separate track from good design; the choices that make a site accessible, clear contrast, visible focus, logical structure, are the same choices that make it usable for everyone. This guide gives designers the concrete specs and habits to build accessibility in from the start.
Accessibility is one of the most durable directions in our overview of web design trends for 2026 precisely because it never goes out of style. Below are the rules that matter most, grounded in WCAG 2.2 Level AA, the standard most teams and regulations target.
Why Accessibility Is a Design Responsibility
Roughly one in six people worldwide lives with a significant disability, and accessibility needs are far broader than permanent impairments. Situational and temporary limitations, bright sunlight, a broken arm, a noisy room, a slow connection, affect everyone at some point. Designing for the edges improves the experience at the center. There is also real legal exposure: accessibility lawsuits are common, and meeting WCAG 2.2 AA is the practical way to reduce that risk.
Crucially, accessibility decisions belong to designers, not just developers. Contrast, focus visibility, target size, label placement, and content order are set in the design, and they are far cheaper to get right there than to retrofit after launch.
Color and Contrast
Contrast is the most common failure and the easiest for designers to control. Meet these WCAG 2.2 AA minimums:
| Element | Minimum contrast |
|---|---|
| Normal body text | 4.5:1 |
| Large text (18.66px bold or 24px+) | 3:1 |
| UI components and graphical objects | 3:1 |
Beyond ratios, never rely on color alone to convey meaning. A required field marked only in red, or a chart distinguished only by hue, excludes users with color vision deficiency. Pair color with text, icons, patterns, or labels. Check every combination with a contrast tool against the actual background, including any overlay or image behind the text.
Keyboard Navigation and Focus
Many users navigate entirely by keyboard, and assistive technologies build on keyboard support. Every interactive element, links, buttons, form fields, custom widgets, must be reachable and operable with the keyboard alone, in a logical order that follows the visual flow. Do not trap focus, and provide a skip link so keyboard users can jump past repeated navigation to the main content.
The focus indicator must be clearly visible. Removing the default outline with outline: none and providing no replacement is one of the most damaging accessibility mistakes, because it leaves keyboard users with no idea where they are. WCAG 2.2 added specific focus-appearance criteria; design a focus style with strong contrast against both the component and its surroundings.
- Operable by keyboard: everything interactive works with Tab, Enter, Space, and arrow keys as appropriate.
- Logical order: focus moves in the order the content reads.
- Visible focus: a clear, high-contrast indicator on every focusable element.
- Skip link: a way to bypass repetitive navigation.
Structure, Headings, and Alt Text
Screen readers rely on correct structure. Use a single <h1> per page and a heading hierarchy that does not skip levels, since users navigate by jumping between headings. Use semantic HTML, real buttons and landmarks rather than styled <div> elements, so the meaning is exposed to assistive technology without extra effort.
Every meaningful image needs descriptive alt text that conveys its purpose; purely decorative images should carry an empty alt="" so screen readers skip them. Write link text that makes sense out of context, “read the form design guide” rather than “click here”, because screen reader users often browse a list of links stripped of surrounding text.
Accessible Forms
Forms are where accessibility and usability meet most visibly. Every field needs a persistent, programmatically associated <label>; placeholder text alone is not a label, because it disappears on input and often fails contrast. Group related fields with fieldsets and legends, mark required fields with both text and an attribute rather than color alone, and write error messages that name the field and the fix in plain language.
Inline validation should announce errors to assistive technology, not just show them visually. These patterns overlap heavily with general form usability, so read this together with our form design best practices.
Touch Targets and Pointer Accessibility
WCAG 2.2 added a Target Size criterion, and it reinforces what mobile usability already demands: interactive elements should be large enough to activate reliably. Practically, design tappable controls to meet the platform minimums of 44 by 44px (Apple) or 48dp (Material), with enough spacing between adjacent targets that a user with limited dexterity, or anyone on a moving train, does not trigger the wrong one. Small, tightly packed icon buttons are a frequent failure.
Pointer accessibility goes beyond size. Avoid actions that require precise dragging or complex gestures without a simple alternative, and never make a critical action depend on hover, which does not exist on touch devices and is unreliable for many users. Anything you can do with a mouse should have a straightforward keyboard and touch equivalent.
How to Test Accessibility
Accessibility is verified, not assumed. Combine automated and manual checks, because automated tools catch only a fraction of issues. A practical workflow looks like this:
- Run an automated audit with a tool such as Lighthouse or axe to catch contrast, missing labels, and structural errors quickly.
- Navigate with the keyboard only. Tab through the whole page; confirm focus is visible, the order is logical, and nothing is unreachable or traps you.
- Test with a screen reader. Use VoiceOver, NVDA, or TalkBack to hear how headings, links, images, and forms are announced.
- Check zoom and reflow. Zoom to 200 percent and confirm content reflows without horizontal scrolling or clipped text.
- Verify color independence. Confirm no information is conveyed by color alone.
Automated tools are a starting point, not a verdict; a page can pass an automated scan and still be unusable with a keyboard. Manual testing with real assistive technology is where genuine accessibility is confirmed.
Motion and Responsive Behavior
Movement can cause discomfort or disorientation. Respect the prefers-reduced-motion setting by reducing or removing non-essential animation for users who request it, and avoid content that flashes more than three times per second, which can trigger seizures. Accessibility also depends on responsive behavior: text must reflow and remain readable when zoomed to 200 percent without horizontal scrolling, which ties directly to a solid mobile-first design foundation.
Frequently Asked Questions
What is WCAG 2.2 AA?
WCAG 2.2 is the current Web Content Accessibility Guidelines, organized into three conformance levels: A, AA, and AAA. Level AA is the practical target most organizations and regulations require. It covers contrast, keyboard operability, focus visibility, labels, and more, balancing meaningful accessibility against achievable implementation.
What contrast ratio do I need for accessibility?
Under WCAG 2.2 AA, normal body text needs at least 4.5:1 contrast against its background, while large text (about 24px or 18.66px bold) and UI components need at least 3:1. Always test against the actual background color, including overlays and images, using a dedicated contrast checker.
Why is keyboard navigation important?
Many people cannot use a mouse and navigate entirely by keyboard, and assistive technologies build on keyboard support. Every interactive element must be reachable and operable by keyboard in a logical order, with a clearly visible focus indicator. Removing focus outlines without a replacement is a serious, common accessibility failure.
Is accessibility a developer or designer job?
Both, but many critical decisions are made in design. Contrast, focus styling, touch target size, heading hierarchy, label placement, and content order are all set before code. Building accessibility into the design is far cheaper and more reliable than retrofitting it, so designers carry real responsibility for it.
