Types of Accessibility Issues: Understanding Different Digital Barriers
This article explains common types of accessibility issues across visual, hearing, motor, cognitive and technical domains. It maps problems to WCAG, gives a prioritisation matrix, a booking-form remediation walkthrough and a one-page triage checklist.
Types of Accessibility Issues appear across content, interface and code. This article lists the common barriers people meet online, shows how they map to WCAG, and gives practical steps for triage and repair.
What is an accessibility issue?
An accessibility issue is anything that prevents a person with a disability from using a digital product the way others can. Issues can be technical, visual, interactional or content related. Some block access entirely. Others make tasks slow or error-prone.
Types by user need
Group problems by the difficulty they create for a person. That helps choose tests and fixes.
Visual
- Poor contrast that makes text or UI elements unreadable
- Images without meaningful alt text or decorative images treated as content
- Non-scalable layouts that break when text size increases
- Reliance on colour alone to convey meaning
Hearing
- Videos without captions or transcripts
- Audio-only instructions with no text alternative
Motor
- Interactive controls that need precise pointing
- Elements not reachable by keyboard or with keyboard traps
- Time limits that prevent completion without assistance
Cognitive and learning
- Complex navigation or inconsistent layouts
- Unclear labels and instructions for forms and controls
- Pages with excessive animation or distracting content
Seizure and vestibular
- Flashing or strobing content that can trigger seizures
- Excessive motion that causes dizziness or nausea
Speech and language
- Voice-only input requirements or speech-based navigation without alternatives
- Content that assumes a high reading level with no simpler option
Common technical issues on websites and how they map to WCAG
Use these labels to explain each problem to designers and developers. I list the typical symptom, why it blocks users and the WCAG success criterion name most relevant.
- Missing alt text — screen reader users miss image meaning. See WCAG 1.1.1 Non-text Content.
- Poor colour contrast — low contrast hides text and controls. See WCAG 1.4.3 Contrast (Minimum).
- No keyboard access — users who can only use a keyboard cannot navigate. See WCAG 2.1.1 Keyboard.
- Invisible focus or wrong focus order — users lose context when tabbing. See WCAG 2.4.7 Focus Visible and 2.4.3 Focus Order.
- Unlabelled form fields — assistive tech cannot identify input purpose. See WCAG 3.3.2 Labels or Instructions and 1.3.1 Info and Relationships.
- CAPTCHAs without accessible alternatives — prevent form completion by people who cannot use the challenge.
- Multimedia without captions or transcripts — deaf users miss content. See WCAG 1.2.2 Captions for prerecorded audio.
- Flashing content — can trigger seizures. See WCAG 2.3.1 Three Flashes or an Effect Limit.
- PDFs and uploaded documents — may lack headings, text alternatives and reading order.
- Incorrect or missing ARIA — can confuse assistive tech if roles, names or states are wrong. See WCAG 4.1.2 Name, Role, Value.
- Timed forms or sessions — users may not complete tasks within forced time. See WCAG 2.2.1 Timing Adjustable.
- Dynamic content not announced — live updates fail to reach users of screen readers unless ARIA live regions are used correctly.
Why automated tests miss many issues
Automated tools can flag roughly 20 to 50 percent of common failures. They are fast and helpful. They cannot assess meaning, cognitive load, captions quality or keyboard flow. Always add manual checks and testing with assistive technologies such as screen readers and keyboard-only navigation. Include people with disabilities for the most reliable results.
Prioritise fixes: an impact versus effort matrix
Use a simple grid to decide what to fix first. I use three bands for each axis: low, medium, high. Examples follow.
| High impact, low effort | High impact, medium effort | High impact, high effort |
|---|---|---|
| Alt text for informative images; add skip links | Add accurate captions to new videos; fix contrast for key buttons | Remediate large, complex PDFs; redesign inaccessible checkout flow |
| Medium impact, low effort | Medium impact, medium effort | Medium impact, high effort |
| Ensure form inputs have labels | Improve heading structure sitewide | Rework deeply nested navigation patterns |
| Low impact, low effort | Low impact, medium effort | Low impact, high effort |
| Add visible focus styles | Replace low-use third-party widgets that lack accessibility support | Full CMS overhaul to support accessible content authoring |
Real-world scenario: inaccessible booking form and step-by-step fixes
Situation: a time-limited booking form requires mouse clicks, uses colour-only error indicators and embeds an image-driven CAPTCHA.
- Test and list faults: keyboard only fails, no visible focus, errors not announced, CAPTCHA blocks screen readers.
- Fix keyboard access: ensure all controls are focusable and follow a logical tab order. Map to WCAG 2.1.1.
- Make errors accessible: add aria-invalid and link error messages to fields with aria-describedby. Use clear text labels. Map to WCAG 3.3.2.
- Replace or supplement CAPTCHA with an accessible alternative such as email verification or an invisible risk-based check.
- Remove hard time limits or provide a clear option to extend. Map to WCAG 2.2.1.
- Retest with screen reader, keyboard, and a user with relevant lived experience.
Quick triage checklist for a single page
- Can you tab through all controls and see a visible focus?
- Do images that convey meaning have alt text?
- Is important text readable at 200 percent zoom and with increased text size?
- Are interactive controls labelled so a screen reader announces their purpose?
- Are videos accompanied by captions or transcripts?
- Is colour the only method used to indicate state or errors?
- Are there flashing elements or large animations?
- Do dynamic updates get announced to assistive tech?
Where to go next
Start with WCAG 2.1 and consult WCAG 2.2 where timing and interactions are updated. Learn WAI-ARIA for dynamic widgets. Run an automated scan, follow it with manual tests and recruit people with disabilities for real-world testing. Use the prioritisation matrix above to focus limited resources on changes that deliver the greatest access improvement fast.
If you want, I can produce a one-page audit checklist tailored to a specific page or app. Tell me your platform and the most-used user flows.