Web Accessibility Beyond Screen Readers: The Overlooked Needs of Real Users

When developers think "accessibility," they think: screen readers, alt text, ARIA labels. These matter. But they address a tiny fraction of accessibility needs. Screen reader users represent roughly 1-2% of users with disabilities. The much larger population has: low vision (need larger text, high contrast), color blindness (8% of men — cannot distinguish certain colors), motor impairments (cannot use a mouse, limited fine motor control), cognitive disabilities (difficulty processing complex information), and temporary disabilities (broken arm, migraine, holding a baby).

Addressing all these needs is accessibility done properly. Here is what most developers miss.

Low Vision: Not Blind, But Cannot Read Your 14px Text

Low vision users: can see the screen but struggle with small text, low contrast, and dense layouts. They might use zoom (200-400%), high contrast mode, or large font settings.

What breaks for them: fixed-width layouts that require horizontal scrolling when zoomed, text in images (cannot be resized independently), low contrast text (light gray on white — fails WCAG AA at 4.5:1 ratio), and hover-only information (tooltips invisible on touch devices used with magnification).

What helps: responsive layouts that reflow at high zoom (no horizontal scrolling), sufficient contrast ratios (AA minimum: 4.5:1 for normal text, 3:1 for large text), resizable text (use rem/em, not px for font sizes), and clear visual hierarchy (headings, spacing, and grouping help scanning).

Testing: zoom your page to 200%. Can you still use it without horizontal scrolling? Is all content accessible? This catches most low-vision issues.

Color Blindness: 8% of Men Cannot See Your Red Error

Color blindness affects roughly 8% of males and 0.5% of females. The most common type (red-green deficiency) means: red error messages look identical to surrounding text, green "success" indicators are invisible, and red/green status indicators are indistinguishable.

Never communicate meaning through color alone. Every color-coded element should also have: text labels (not just a red dot — add "Error" text), icons or shapes (checkmark for success, X for error — distinct shapes regardless of color), and patterns or textures (in charts, use patterns in addition to colors).

Our approach: error messages use red color AND the word "Error" AND an icon. Success uses green AND "Success" AND a checkmark. Remove the color, and the meaning is still clear.

Motor Impairments: Not Everyone Uses a Mouse

Motor impairments range from: permanent conditions (paralysis, cerebral palsy, muscular dystrophy), temporary conditions (broken arm, RSI), and situational limitations (holding a child, one hand occupied).

These users navigate with: keyboard only (Tab, Enter, Arrow keys), voice control (Dragon NaturallySpeaking, Voice Control), switch devices (single button that cycles through interactive elements), and eye tracking (gaze-based control).

What breaks for them: click targets smaller than 44x44px (too small for imprecise motor control), functionality accessible only through hover (keyboard users cannot hover), drag-and-drop without keyboard alternatives, custom components without keyboard support, and time-limited interactions (cannot click fast enough).

What helps: all functionality accessible via keyboard, visible focus indicators (users must see where they are), logical tab order (follows visual reading order), adequate click target sizes (minimum 44x44px), and no time constraints (or the ability to extend time limits).

Testing: unplug your mouse. Navigate your entire application with only the keyboard. Can you reach every interactive element? Can you activate every button and link? Can you see where focus currently is?

Cognitive Accessibility: The Largest Underserved Group

Cognitive disabilities include: ADHD (difficulty maintaining focus on complex tasks), dyslexia (difficulty reading dense text), autism (sensitivity to sensory overload, preference for predictable patterns), learning disabilities (difficulty processing new information quickly), and memory impairments (forgetting steps in multi-step processes).

These affect far more people than blindness or motor impairments. And they are the most overlooked in accessibility discussions.

What helps: clear, simple language (avoid jargon, use short sentences), consistent navigation (same elements in same positions across pages), progress indicators (where am I in this process? what is next?), error prevention (confirm destructive actions, allow undo), reduced cognitive load (do not show everything at once — progressive disclosure), and predictable behavior (elements behave consistently, no surprises).

Implementing Keyboard Navigation Properly

Every interactive element must be: reachable via Tab (or Shift+Tab for reverse), activatable via Enter or Space, and visibly focused (clear focus ring/outline).

Custom components (dropdowns, modals, tabs, accordions) need: proper ARIA roles and states, keyboard interaction patterns matching WAI-ARIA Authoring Practices (Arrow keys for tabs, Escape for modals), and focus management (when a modal opens, focus moves into it; when it closes, focus returns to the trigger).

The tab order must be logical: follow the visual reading order. If your CSS reorders elements visually but the DOM order is different: keyboard users navigate in a confusing sequence.

Focus Management in Single-Page Applications

SPAs have a unique accessibility challenge: when content changes without a page reload (navigation, loading new content), screen readers and keyboard users are not informed.

Solutions: announce route changes (set focus to the new page heading after navigation), manage focus after content updates (when a search result loads, move focus to the results region), and use live regions (aria-live="polite") for dynamic content updates that should be announced.

Without focus management: a screen reader user clicks a link, the URL changes, new content appears, but they have no indication anything happened. They are still focused on the link they clicked.

Automated Testing Catches 30% of Issues

Automated tools (axe-core, Lighthouse accessibility audit, eslint-plugin-jsx-a11y) catch: missing alt text, insufficient color contrast, missing form labels, invalid ARIA usage, and missing document language.

These tools cannot catch: whether alt text is meaningful (alt="image" passes automation but helps nobody), whether keyboard navigation is logical, whether the reading order makes sense, whether focus management works in SPAs, and whether the experience is usable by a real person with a disability.

You need both: automated testing (catches the easy, measurable issues) and manual testing (catches the usability issues). Run axe-core in CI to prevent regressions. Manually test with keyboard and screen reader quarterly.

The Business Case

Accessibility is not charity. It is: a legal requirement (ADA, EU Accessibility Directive — lawsuits are increasing), a larger market (15-20% of the global population has some disability), better UX for everyone (captions help in noisy environments, high contrast helps in sunlight, keyboard shortcuts help power users), and SEO benefit (accessible sites have better structure, better semantics, better search ranking).

The cost of accessibility after-the-fact is 10x the cost of building it in from the start. An accessibility retrofit of an existing application takes months. Building accessible from day one adds maybe 10-15% to initial development time.

Our Approach at AIDToolStack

We follow progressive enhancement: semantic HTML first (proper headings, lists, buttons, links — not divs with click handlers), keyboard navigation verified for all interactive components, color contrast verified (using automated checks in CI), ARIA labels where semantics are insufficient (custom widgets, dynamic content), and quarterly screen reader testing (VoiceOver on macOS, NVDA on Windows).

We are not perfect. But we are improving continuously. Every new component is built with accessibility from the start. Existing components are improved when we touch them for other reasons.