UI/UX Accessibility in Design
Approximately 15% of the world's population lives with some form of disability. That is over 1 billion people. When you design without considering accessibility, you are shutting the door on a significant portion of your potential users. Accessible design is not a special add-on or a compliance checkbox — it is fundamentally good design that benefits everyone.
This page teaches you the principles of accessible design, specific techniques to implement them, and how to test your designs for accessibility before users ever encounter a problem.
Understanding Disabilities in the Context of Design
Designers often think of disability as a permanent condition — someone who is always blind or always deaf. But disability is actually a spectrum with three categories that every designer should understand.
THE DISABILITY SPECTRUM:
PERMANENT TEMPORARY SITUATIONAL
─────────────────────────────────────────────────────────────
VISUAL: Blind Post-eye surgery Bright sunlight
Low vision Dilated pupils Glare on screen
MOTOR: One arm Broken arm Holding a baby
Tremors Sprained wrist One hand on wheel
HEARING: Deaf Ear infection Loud café
Hard of hearing Recovering from Headphones off
surgery
COGNITIVE: Dyslexia Concussion Distracted
ADHD Medication effect Multitasking
KEY INSIGHT:
Designing for permanent disabilities helps everyone in
situational or temporary situations too.
Example: Captions for deaf users also help the person
watching a video in a noisy metro with no headphones.
WCAG: The Standard for Accessibility
The Web Content Accessibility Guidelines (WCAG) is the internationally recognized standard for web and app accessibility. It is published by the W3C (World Wide Web Consortium). WCAG organizes its guidelines around four principles, remembered with the acronym POUR.
WCAG FOUR PRINCIPLES (POUR): P — PERCEIVABLE All content must be presentable in ways users can perceive. Blind users must be able to hear it. Deaf users must be able to read it. Users with low vision must be able to zoom in. O — OPERABLE All interactive elements must be operable by different methods. Keyboard-only navigation must work. Touch targets must be large enough. Users who need more time must be able to pause. U — UNDERSTANDABLE Content and interfaces must be clear and predictable. Error messages must make sense. Instructions must be readable. Forms must behave consistently with user expectations. R — ROBUST Content must work across a wide range of assistive technologies. Screen readers, voice control, switch devices must all work. WCAG LEVELS: Level A → Minimum accessibility (basic requirements) Level AA → Standard accessibility (most regulations require this) Level AAA → Highest accessibility (ideal, often not fully required)
Color and Contrast
Approximately 8% of men and 0.5% of women have some form of color vision deficiency (color blindness). Low contrast text is also a problem for elderly users and anyone reading in poor lighting conditions.
Contrast Ratio Requirements
WCAG CONTRAST RATIO REQUIREMENTS:
CONTRAST RATIO explained:
1:1 = No contrast (white text on white background)
21:1 = Maximum contrast (black text on white background)
WCAG AA REQUIREMENTS:
Normal text (below 18px bold, below 24px regular):
→ Minimum 4.5:1 contrast ratio required
Large text (18px bold or 24px regular and above):
→ Minimum 3:1 contrast ratio required
UI components and icons (buttons, inputs, icons):
→ Minimum 3:1 contrast ratio required
EXAMPLES:
White #FFFFFF on Blue #3B82F6 → 3.0:1 ← FAILS for small text
White #FFFFFF on Blue #1D4ED8 → 7.6:1 ← PASSES
Gray #9CA3AF on White #FFFFFF → 2.3:1 ← FAILS
Gray #374151 on White #FFFFFF → 10.7:1 ← PASSES
TOOL: Check contrast at webaim.org/resources/contrastchecker
Never Use Color Alone to Convey Information
COLOR-ONLY PROBLEM:
BAD (Color blind user cannot distinguish):
● In stock ← Green dot
● Out of stock ← Red dot
A user with red-green color blindness sees:
● In stock ← Brown/gray dot
● Out of stock ← Brown/gray dot (Identical!)
GOOD (Adds icon + text alongside color):
✓ In stock ← Green + checkmark + label
✕ Out of stock ← Red + X + label
MORE EXAMPLES:
Form errors: Red border ALONE → bad
Red border + ✕ icon + error text → good
Chart lines: Only color = bad for color blind
Color + line style (solid, dashed, dotted) = good
Status: Green = active, Red = inactive → bad alone
Green + dot + "Active" text → good
Keyboard Accessibility
Many users cannot use a mouse. This includes people with motor disabilities, users of voice control software, and power users who prefer keyboard shortcuts. Every interactive element in your design must be reachable and operable with a keyboard alone.
KEYBOARD NAVIGATION BASICS: Standard keyboard interactions: Tab → Move to the next interactive element Shift + Tab → Move to the previous element Enter → Activate links and buttons Space → Activate buttons and toggle checkboxes Arrow Keys → Navigate within a component (menus, tabs) Escape → Close modals, dropdowns, dialogs FOCUS INDICATOR: When a user navigates with a keyboard, the currently focused element must have a VISIBLE focus indicator. NO VISIBLE FOCUS (Terrible for keyboard users): [ Button ] ← No visual change when focused VISIBLE FOCUS (Good — shows which element is selected): [ Button ] ← Blue outline or ring around the button ┌──────────────┐ │ Button │ ← Outline visible └──────────────┘ FOCUS ORDER: The order that Tab key moves through elements must match the visual reading order (top-left to bottom-right). If Tab order jumps randomly across the page, keyboard users are completely disoriented.
Focus Traps
FOCUS TRAP — When It Is Bad and When It Is Good:
BAD FOCUS TRAP:
User is navigating a page with Tab.
They accidentally Tab into a modal's overlay background.
Tab key no longer moves them anywhere.
They are stuck and cannot reach any content.
GOOD FOCUS TRAP (Intentional):
A modal dialog opens.
Tab key cycles only within the modal:
Close button → Form field → Submit button → Close button (loops)
User CANNOT Tab outside the modal while it is open.
This is correct behavior — the user must dismiss the modal first.
When modal closes, focus returns to the element that opened it.
Screen Readers and Semantic HTML
Screen readers are assistive technologies that read the content of a screen out loud for blind or low-vision users. Popular screen readers include NVDA (Windows), JAWS (Windows), VoiceOver (Mac/iOS), and TalkBack (Android). Screen readers understand content based on HTML structure, not visual appearance.
SEMANTIC HTML FOR SCREEN READERS: BAD — Div soup (screen reader cannot interpret meaning):...GOOD — Semantic HTML (screen reader understands structure):... SEMANTIC ELEMENTS AND WHAT THEY ANNOUNCE:
Alternative Text for Images
ALT TEXT GUIDE:
WHAT IS ALT TEXT?
The text description of an image that screen readers read aloud.
Also shows if the image fails to load.
WRITING GOOD ALT TEXT:
Informative image:
The image: A line graph showing revenue growing from
₹10 lakh in Jan to ₹45 lakh in Dec.
Alt text: "Line chart showing monthly revenue growth
from ₹10 lakh in January to ₹45 lakh in December 2024"
Functional image (button or link with only an image):
The image: A search icon button
Alt text: "Search" (describes what it DOES, not what it LOOKS like)
Decorative image (no information, purely visual):
The image: A generic wavy background pattern
Alt text: alt="" (empty alt text — screen readers skip it entirely)
COMMON ALT TEXT MISTAKES:
✗ "image.jpg" — filename is not a description
✗ "Image of..." — never start with "image of" (screen reader
already announces it as an image)
✗ No alt attribute — screen readers read the file name instead
✗ Very long alt text — keep it under 125 characters when possible
ARIA: When HTML Alone Is Not Enough
ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that add accessibility information to elements that HTML alone cannot describe. Use ARIA when you create custom components that do not have a native HTML equivalent.
COMMON ARIA ATTRIBUTES: aria-label → Provides a text label for elements without visible text ← Screen reader says: "Close dialog, button" ← Without it, screen reader would say: "✕, button" aria-labelledby → Points to another element as the labelRecent Orders
... aria-describedby → Points to an element with additional descriptionPassword must be 8 characters minimum
aria-required → Marks a form field as required aria-expanded → Tells screen reader if a dropdown is open or closed ← When menu opens: aria-expanded="true" aria-current → Marks current page in navigation Dashboard aria-live → Announces dynamic content changes without page refreshYou have 3 new messages← Screen reader announces this text when it updates
An important rule with ARIA: "No ARIA is better than bad ARIA." Incorrect ARIA attributes make the experience worse for screen reader users than having no ARIA at all. Always test with an actual screen reader when adding ARIA.
Accessible Forms
ACCESSIBLE FORM CHECKLIST: LABELS: ✓ Every input has a visible label using
Cognitive Accessibility
Cognitive accessibility addresses users with learning disabilities, ADHD, dyslexia, memory difficulties, or anyone under significant mental load. These users benefit from clear language, predictable layouts, and forgiving interactions.
COGNITIVE ACCESSIBILITY GUIDELINES: CLEAR LANGUAGE: ✓ Use simple, common words (not "utilize" — use "use") ✓ Write short sentences (one idea per sentence) ✓ Avoid jargon and technical terms without explanation ✓ Put the most important information first PREDICTABLE BEHAVIOR: ✓ Navigation stays in the same place on every page ✓ Components behave the same way every time ✓ Never automatically submit a form or change a setting ✓ Give warnings before time limits expire DYSLEXIA-FRIENDLY DESIGN: ✓ Left-align text (never justified text) ✓ Use adequate line spacing (1.5 minimum for body text) ✓ Avoid italic text in body copy (hard to read with dyslexia) ✓ Use sans-serif fonts ✓ Adequate paragraph spacing (0.5em or more between paragraphs) MEMORY SUPPORT: ✓ Provide clear progress indicators in multi-step flows ✓ Show users where they are in a process ✓ Allow users to save progress and return later ✓ Confirm important actions before executing them ERROR PREVENTION: ✓ Ask for confirmation before destructive actions ✓ Allow undo wherever possible ✓ Use clear success messages so users know action was completed
Motion and Animation Accessibility
MOTION SENSITIVITY:
Some users experience nausea, dizziness, or seizures from
certain types of animation. Conditions include:
- Vestibular disorders (motion sensitivity)
- Epilepsy (risk of seizure from flashing)
- Migraines triggered by movement
CSS MEDIA QUERY SOLUTION:
@media (prefers-reduced-motion: reduce) {
← Detects if user has turned on "Reduce Motion" in OS settings
← In this block, remove or simplify animations
}
ANIMATION RULES:
✓ Never flash content more than 3 times per second
✓ Respect prefers-reduced-motion — disable or simplify animations
✓ Autoplay video: must not autoplay audio, or provide mute button
✓ Provide pause/stop controls for any continuously moving content
✓ Avoid large areas of flashing or rapidly changing colors
Testing for Accessibility
ACCESSIBILITY TESTING METHODS: 1. AUTOMATED TESTING TOOLS (Fast, finds ~30-40% of issues): axe DevTools (browser extension) — free WAVE (wave.webaim.org) — free Lighthouse in Chrome DevTools — free Run these on every page. Fix everything they flag. Note: Automated tools cannot catch all issues. 2. KEYBOARD TESTING (Manual — 15 minutes): Put your mouse away completely. Navigate your product using only Tab, Enter, Escape, and Arrow keys. Can you reach and activate every interactive element? Is the focus indicator always visible? 3. SCREEN READER TESTING (Manual — requires learning): VoiceOver (Mac): Cmd + F5 to activate NVDA (Windows): Free download from nvaccess.org Navigate your product. Does it make sense when heard? Are images described? Are errors announced? 4. COLOR CONTRAST TESTING: Chrome DevTools: CSS Overview → Contrast issues WebAIM Contrast Checker: webaim.org/resources/contrastchecker 5. ZOOM TESTING: Zoom browser to 200% and 400%. Does content still work? Can you still complete all tasks? Does any content overlap or become unusable? 6. COLOR BLINDNESS SIMULATION: Chrome DevTools → Rendering → Emulate vision deficiencies Check: Protanopia, Deuteranopia, Tritanopia, Achromatopsia Verify: Information is not lost when color is changed
Key Points
- Accessibility benefits everyone — designs built for disabilities also help people in situational constraints like bright sunlight or holding a baby.
- WCAG organizes accessibility into four principles: Perceivable, Operable, Understandable, and Robust (POUR).
- Normal body text requires a minimum 4.5:1 contrast ratio (WCAG AA); large text and UI components require 3:1.
- Never use color alone to convey information — always add an icon, pattern, or text label alongside color.
- All interactive elements must be reachable and operable with a keyboard only; focus indicators must always be visible.
- Write descriptive alt text for all informative images; use empty alt text (alt="") for purely decorative images.
- Use semantic HTML elements — nav, main, button, header — instead of generic div elements for everything.
- Respect the prefers-reduced-motion CSS media query to disable or reduce animations for motion-sensitive users.
- Run automated accessibility tools (axe, WAVE) on every page, then do manual keyboard testing and screen reader testing.