Vision Disabilities

Vision disabilities include a wide range of conditions — from complete blindness to varying degrees of low vision and colour perception differences. Each condition creates distinct barriers on the web and requires different design and development responses.

Approximately 1.5 million Canadians live with vision loss, and that number rises significantly with age. Vision disability is also one of the most common secondary effects of conditions like diabetes (diabetic retinopathy), multiple sclerosis, and stroke.

Types of vision disability

Type	Description	Prevalence
Blindness	Little or no functional vision	~150,000 Canadians
Low vision	Reduced visual acuity not correctable by standard lenses	~1.2 million Canadians
Colour blindness	Difficulty distinguishing certain colour combinations	~8% of men, ~0.5% of women
Contrast sensitivity loss	Difficulty perceiving contrast, common with aging and glaucoma	Increases with age
Field loss	Missing portions of visual field (tunnel vision, hemianopia)	Common with stroke, glaucoma
Photophobia	Extreme light sensitivity	MS, migraines, albinism

Assistive technologies

Developer Designer

Screen readers

Screen readers convert text and interface elements to synthesized speech or braille output. They are the primary tool for blind users. Common screen readers:

Screen reader	Platform	Common browser pairing
NVDA (NonVisual Desktop Access)	Windows (free)	Firefox, Chrome
JAWS (Job Access With Speech)	Windows (paid)	Chrome, Edge
VoiceOver	macOS, iOS (built-in)	Safari
TalkBack	Android (built-in)	Chrome
Narrator	Windows (built-in)	Edge

Screen reader users navigate primarily by headings, landmarks, links, and form controls — not by reading linearly through all text. They use keyboard shortcuts to jump between elements.

Screen magnification

Low vision users often use magnification software alongside partial visual ability:

• ZoomText / Fusion (Windows) — up to 60× magnification, colour enhancement
• macOS Zoom (built-in) — full-screen and picture-in-picture magnification
• Browser zoom — built into all browsers (Ctrl/Cmd +); most users with mild low vision rely only on this

Braille displays

Refreshable braille displays render text as tactile braille cells. They work alongside screen readers and are essential for deafblind users. They have a narrow viewport (40–80 characters wide), making responsive design critical.

High contrast mode

Both Windows and macOS offer system-level high contrast modes that override website colours with high-contrast system palettes. CSS forced-colors: active media query allows developers to adapt.

Barriers on the web

Images without alt text

Barrier

Images, icons, charts, and infographics have no text alternative — a screen reader announces 'image' or the filename with no useful information.

Assistive Technology

Screen readers (NVDA, JAWS, VoiceOver)

Design Consideration

Every meaningful image needs descriptive alt text. Decorative images need empty alt='' so screen readers skip them. Complex images (charts, diagrams) need extended descriptions.

Poor colour contrast

Barrier

Text or UI elements do not have sufficient contrast against their background — users with low vision or contrast sensitivity loss cannot read the content.

Assistive Technology

Screen magnification, high contrast mode

Design Consideration

Meet WCAG 2.1 AA (4.5:1 for text, 3:1 for large text and UI components). Target AAA (7:1) for body text where possible. Never rely on colour alone to convey information.

Content not reachable by keyboard

Barrier

Interactive elements (menus, modals, carousels) can only be activated with a mouse — screen reader users who navigate by keyboard cannot access them.

Assistive Technology

Screen readers (keyboard mode)

Design Consideration

All functionality must be operable by keyboard. Test by unplugging your mouse and tabbing through the page. Focus must be visible at all times (WCAG 2.4.7).

Missing or incorrect heading structure

Barrier

Pages lack headings or use headings for visual styling rather than semantic structure — screen reader users cannot navigate by heading and cannot understand the page hierarchy.

Assistive Technology

Screen readers (heading navigation)

Design Consideration

Use one h1 per page. Use h2 for major sections, h3 for subsections. Never skip heading levels. Never use a heading level just because you want a specific font size.

Non-descriptive link text

Barrier

Links say 'click here', 'read more', or 'learn more' — when screen readers list all links on a page, these provide no information about the destination.

Assistive Technology

Screen readers (links list)

Design Consideration

Link text must describe the destination or action. 'Download the AODA compliance checklist (PDF)' is good. 'Click here' is not. If link text must be short, use aria-label or aria-describedby to add context.

Content that doesn't reflow

Barrier

At 400% zoom (the WCAG 1.4.10 test), content overflows horizontally — users must scroll both vertically and horizontally, losing track of their position on the page.

Assistive Technology

Browser zoom, screen magnification

Design Consideration

Design responsively. At 320px viewport width (equivalent to 400% zoom on a 1280px screen), all content should be readable in a single column without horizontal scrolling.

Colour as the only indicator

Barrier

Forms show required fields only in red, charts use colour alone to distinguish data series, errors are shown only with a red border — users with colour blindness cannot distinguish these states.

Assistive Technology

High contrast mode, no assistive technology

Design Consideration

Always pair colour with a secondary indicator: icon, pattern, text label, or shape. Error states need both colour and a text description. Never rely on hue alone.

Design considerations

Designer

Contrast requirements

Text must meet minimum contrast ratios against its background. Here are the WCAG thresholds and how common design patterns fare:

Aa

Aa

Aa

Aa

Focus indicators

Keyboard focus must be clearly visible. The default browser focus ring is often suppressed by CSS resets. Provide a custom focus style with at least 3:1 contrast ratio and sufficient area (WCAG 2.4.11 in WCAG 2.2).

Text sizing

• Body text should be at least 16px (1rem)
• Avoid px units for text — use rem so users’ browser font size preferences are respected
• Line height of at least 1.5 for body text
• Avoid justified text (uneven word spacing disrupts reading for low vision users)

Layout

• Do not convey information purely through spatial position (“the button on the right”)
• Ensure form labels are visually adjacent to their fields — not separated by other content
• Avoid very long line lengths (max ~75 characters) which are harder to track for low-vision users

Development considerations

Developer

Semantic HTML first

Before adding ARIA, use semantic HTML. Most screen reader support comes for free with correct markup:

<!-- Do this -->
<nav aria-label="Main navigation">
  <ul>
    <li><a href="/about">About</a></li>
  </ul>
</nav>

<!-- Not this -->
<div class="nav">
  <div class="nav-item" onclick="go('/about')">About</div>
</div>

Alt text patterns

<!-- Meaningful image -->
<img src="wcag-levels.png" alt="Diagram showing WCAG A, AA, and AAA levels as nested circles" />

<!-- Decorative image -->
<img src="divider.png" alt="" role="presentation" />

<!-- Image with caption (alt can be brief) -->
<figure>
  <img src="chart.png" alt="Bar chart: AODA compliance rates by sector" />
  <figcaption>Figure 1: AODA compliance audit results, 2023. Finance sector leads at 74%; retail trails at 31%.</figcaption>
</figure>

<!-- Icon with adjacent text (alt empty — text provides the label) -->
<button>
  <svg aria-hidden="true">...</svg>
  Download report
</button>

ARIA landmarks

Landmarks help screen reader users navigate by page region:

<header role="banner">...</header>
<nav aria-label="Site navigation">...</nav>
<main id="main-content">...</main>
<aside aria-label="On this page">...</aside>
<footer role="contentinfo">...</footer>

Live regions

Use aria-live for dynamic content updates (search results loading, form validation errors, status messages):

<!-- Polite: announced at next pause in speech -->
<div aria-live="polite" aria-atomic="true">
  <p>5 results found for "WCAG contrast"</p>
</div>

<!-- Assertive: announced immediately (use sparingly) -->
<div role="alert">
  <p>Error: Please enter a valid email address.</p>
</div>

Testing with vision disabilities

Quick keyboard test

1. Unplug or disable your mouse
2. Use Tab to navigate forward, Shift+Tab to go back
3. Use Enter/Space to activate buttons and links
4. Verify every interactive element is reachable and has a visible focus ring

Screen reader basics (NVDA + Chrome)

1. Download NVDA free from nvaccess.org
2. Open Chrome, press Ctrl+Home to go to page top
3. Press H to jump between headings
4. Press K to jump between links
5. Press F to jump between form fields
6. Press Insert+F7 to open the links list — check all link text makes sense

Browser contrast check

• Chrome DevTools: Elements panel → Accessibility tab → colour contrast ratio displayed
• Firefox DevTools: Inspector → Accessibility → show contrast ratio

Automated tools

• axe DevTools (browser extension) — catches alt text, contrast, and label issues
• WAVE (WebAIM) — visual overlay of accessibility issues

Related pages

• WCAG Levels Explained — contrast requirements at AA and AAA
• Design Principles — colour contrast deep-dive and focus state design
• Development Practices — semantic HTML, ARIA, keyboard navigation code
• Testing and Evaluation — full testing workflow