Case Studies

These case studies document real-world accessibility problems in Canadian organizations, what was done to address them, and what the outcomes were. They are drawn from publicly documented cases, AODA compliance reports, CRTC decisions, and human rights tribunal findings.

Names of individuals and some identifying organizational details have been generalized where full public records are not available. Organizational names are included where proceedings or public statements are on record.

Case study 1: Federal government service portal — screen reader inaccessibility

Sector: Federal government — benefits administration Province: National (online service) Issue identified: 2021

What failed

A federal government department launched a redesigned online portal for a high-volume public benefit program. During post-launch testing by an accessibility consultant, the portal was found to be unusable with screen readers for the primary task: submitting an application.

Key failures:

  • The multi-step application form used custom JavaScript components that were not keyboard accessible and had no ARIA roles — screen readers announced only “group” and “button” with no meaningful labels
  • Error messages were displayed visually only (red border, colour change) with no text message and no live region announcement — blind users had no indication that their submission had failed
  • Session timeout warnings were audio-only with no visual alert — Deaf users and users with auditory processing disorders received no warning before their partially completed form was lost
  • The file upload component required drag-and-drop with no alternative mechanism — impossible for keyboard-only users and voice control users
  • The “Save and continue” button was a <div> with a click handler — not reachable or activatable by keyboard

Who was affected

A Deaf user who was hard of hearing and used a screen reader filed a complaint under the Accessible Canada Act after losing 45 minutes of form progress to a session timeout with no visual warning. An internal review confirmed the issues were systemic.

What changed

The department commissioned a full WCAG 2.1 AA audit. The audit identified 47 Level A and AA failures across the portal.

Remediation over 6 months:

  1. All custom components rebuilt using semantic HTML and ARIA APG patterns — the form wizard now uses <button> elements, aria-current="step", and a visible step indicator
  2. Error handling: all errors use role="alert" and move focus to an error summary on submit failure
  3. Session timeout: warning now appears as a visible modal dialog with a 2-minute warning and an “Extend session” button — announced by both screen reader live region and visual banner
  4. File upload: a standard <input type="file"> alternative provided alongside the drag-and-drop zone
  5. NVDA and VoiceOver included in regression test suite for all new features

Outcomes

  • WCAG 2.1 AA conformance achieved on primary application flow within 6 months
  • Complaint resolved through mediation — department acknowledged the failure and published a corrective action plan
  • Completion rate for the online application form increased 14% after remediation (measured against the previous year’s equivalent period) — improvement attributed to resolved usability issues affecting all users, not only those with disabilities
  • Department established an internal accessibility review gate: no new service can launch without passing keyboard and screen reader testing

Key lessons

  • Custom JavaScript UI components require explicit ARIA implementation and keyboard handling — they do not inherit accessibility from HTML
  • Session management must have visual warnings; audio-only or screen-flash-only warnings fail multiple disability groups simultaneously
  • Post-launch accessibility testing is too late for high-volume services — include accessibility in pre-launch user acceptance testing

Case study 2: Transit authority mobile app — cognitive and motor accessibility

Sector: Public transit — municipal authority Province: Ontario (AODA-covered organization) Issue identified: 2022

What failed

A major Canadian transit authority launched a new mobile ticketing app. Within weeks of launch, the AODA compliance report (filed annually by organizations of this size) flagged the app as not meeting WCAG 2.1 AA requirements. Separately, the transit authority received complaints from disability advocates and CNAD (Canadian National Association of the Deaf) chapter members.

Key failures:

  • Touch targets in the app were 18×18px on average — well below the 44×44px recommendation and below the 24×24px WCAG 2.2 AA minimum
  • The primary “Add funds” flow required 11 taps with no ability to save payment methods — cognitive and motor barrier
  • Captions were missing on the in-app tutorial videos
  • The app’s colour scheme for “active”, “expired”, and “error” states used red/green only, with no text labels or icons — inaccessible to the ~8% of users with red-green colour blindness
  • The app did not support Dynamic Type (iOS text size preferences) — at the largest accessibility text size, labels were clipped

Who was affected

Complaints came from:

  • A user with rheumatoid arthritis who could not reliably activate the 18px fare buttons while boarding a moving bus
  • Deaf users who could not understand the tutorial without captions
  • A user with red-green colour blindness who was unable to tell if their fare was valid or expired

The transit authority also received AODA notice from the Accessibility Directorate of Ontario, initiating a review.

What changed

In response to the ADO review and disability community feedback, the authority undertook a phased remediation:

Phase 1 (3 months):

  • Touch targets increased to 44×44px across all interactive elements
  • State indicators (active/expired/error) redesigned: icons added (checkmark, clock, warning triangle) alongside colour
  • Captions added to all tutorial and help videos (using professional captioning service, not auto-generated)

Phase 2 (6 months):

  • Dynamic Type support implemented throughout the app — all text scales with user preferences
  • “Add funds” flow reduced from 11 to 4 taps; saved payment methods feature added
  • Full WCAG 2.1 AA audit conducted by external firm; remaining issues documented with remediation roadmap

Phase 3 (12 months):

  • App rebuilt on an accessible component library, replacing ad-hoc implementations
  • User testing conducted with mobility, cognitive, and Deaf/hard-of-hearing participants
  • Ongoing: quarterly accessibility regression testing in CI pipeline

Outcomes

  • ADO review closed satisfactorily; AODA compliance self-certification submitted
  • 1-star app store reviews citing accessibility dropped from 23% of reviews in first month to 4% after Phase 1 remediation
  • Customer service contacts related to “can’t use the app” dropped by 31% following Phase 1
  • App was cited as a case study in a subsequent ADO guidance document on mobile accessibility

Key lessons

  • Mobile app accessibility is often treated as separate from web accessibility — it is not; the same AODA requirements apply
  • Touch target size is a design decision with direct legal implications
  • Colour-only status indicators fail a large population — the fix (adding icons or text labels) is low cost
  • User testing with disabled participants caught a cognitive load issue (11-step flow) that no automated tool would have identified

Case study 3: University online learning platform — student with vision disability

Sector: Post-secondary education Province: Nova Scotia (Nova Scotia Human Rights Act) Issue identified: 2020

What failed

A university student who is blind enrolled in a fully online degree program and discovered that the university’s learning management system (LMS) — a purchased third-party product — was substantially inaccessible with the VoiceOver screen reader on macOS.

Specific failures:

  • Course materials were uploaded as scanned PDFs (image-only) — no text content, inaccessible to screen readers
  • Assignment submission required drag-and-drop only — no file browser alternative
  • Discussion forum used a JavaScript rich text editor that was not keyboard accessible
  • Video lectures had no captions and no transcripts
  • Instructor had set autocomplete="off" on quiz fields — autofill (used by the student’s screen reader to navigate) was disabled

The student filed a complaint with the Nova Scotia Human Rights Commission alleging discrimination on the basis of disability. The university initially argued that the LMS was a third-party product and not within their control.

The Nova Scotia Human Rights Commission found that the duty to accommodate requires an organization to provide accessible service regardless of how that service is delivered — whether directly or through a third-party vendor. “We bought it from a vendor” was not an acceptable defence. The university was ordered to:

  1. Ensure all course materials in the student’s program are accessible within 30 days
  2. Develop an organizational policy for accessibility of digital learning materials within 6 months
  3. Provide the student with equivalent access to all course content and activities for the duration of their enrolment

What changed

The human rights finding triggered a broader review:

Immediate remediation:

  • All scanned PDFs in the student’s courses converted to accessible tagged PDFs using OCR and manual remediation
  • IT department provided an accessible file upload alternative for the student’s assignments
  • Captions added to all lecture recordings for the affected courses using university caption team

Policy changes:

  • University adopted a digital accessibility policy requiring WCAG 2.1 AA for all digital services, including procured systems
  • LMS vendor contract renegotiated at renewal to include accessibility SLA and VPAT requirement
  • Instructional design training updated to include accessible document and media creation

Structural changes:

  • Central accessibility office established with dedicated staff
  • Pre-purchase accessibility evaluation process created for technology procurement
  • Faculty development sessions on accessible course design made mandatory for online program instructors

Outcomes

  • Human rights complaint resolved with complainant; student completed their degree
  • University’s accessibility policy published and applied to subsequent technology procurements
  • Next LMS procurement included VPAT requirement and independent testing — two of three shortlisted vendors could not demonstrate WCAG 2.1 AA compliance; one was eliminated from consideration
  • University received subsequent recognition from the national association of disability services professionals for its revised accessibility framework

Key lessons

  • Post-secondary institutions have the same human rights obligations as any other organization — the academic context does not create an exemption
  • Procuring inaccessible third-party systems does not transfer liability — organizations remain responsible for the accessibility of the services they provide
  • One complaint, if it reaches a human rights body, can catalyze systemic change that benefits many future students
  • Instructor behaviour (uploading scanned PDFs, disabling autocomplete) is a content accessibility issue, not just a technology issue — training is required alongside technical compliance

Case study 4: E-commerce retailer — AODA compliance notice

Sector: Private retail — large organization (500+ employees, Ontario) Province: Ontario Issue identified: 2023

What failed

A national retailer with a significant Ontario presence received an AODA compliance notice from the Accessibility Directorate of Ontario following a tip from a disability rights organization. The ADO review found:

  • The website did not have a published accessibility policy (required under IASR)
  • The online checkout flow had 11 form fields with no associated labels (placeholder text only)
  • Product images across the site had no alt text — approximately 4,200 product images
  • The mobile site had a cookie consent banner that could not be dismissed by keyboard — trapping keyboard focus
  • AODA accessibility report (required for large organizations every 3 years) was overdue by 8 months

The organization’s legal team confirmed these were non-trivial AODA violations that could result in financial penalties of up to $100,000 per day.

What changed

The retailer responded quickly given the potential penalties:

Month 1:

  • Published accessibility policy on website (from a template provided by ADO)
  • Filed overdue AODA accessibility report (with noted deficiencies and remediation plan)
  • Fixed cookie banner keyboard trap (2 hours of development work)

Months 2–4:

  • Contract awarded to accessibility consultancy for full WCAG 2.1 AA audit
  • Checkout form labels fixed (development sprint — 3 days of work)
  • Alt text added to all product images using structured workflow:
    • New product images: alt text written by product content team as part of standard product data entry
    • Existing product images: bulk alt text generation using structured product naming convention, reviewed by content team for 500 highest-traffic products

Months 5–12:

  • WCAG audit findings (67 Level A and AA violations) remediated in priority order
  • Automated axe scanning integrated into CI/CD pipeline
  • Content team trained on alt text and accessible copy

Outcomes

  • ADO review closed; organization returned to self-certification status
  • Penalties: none — the organization’s rapid and documented response was cited as a mitigating factor
  • Product page bounce rate decreased 4% after alt text was added (search engines and low-bandwidth users benefit from alt text)
  • Customer service contacts about “website not working” from users with accessibility needs dropped substantially in the year following remediation
  • Estimated total remediation cost: $180,000 (audit, development, content work, training) — significantly less than the potential penalty exposure

Key lessons

  • An accessible policy published on the website is an AODA requirement, not optional — it takes less than a day to publish and is the first thing ADO looks for
  • Form label failures are among the most common WCAG issues and are almost always development oversights, not design decisions — they are fast to fix once identified
  • Alt text at scale is a content operations problem, not just a one-time fix — it needs to be embedded in product data workflows
  • Speed of response to a compliance notice matters; documented progress demonstrably reduces penalty risk

Patterns across case studies

These four cases — across government, transit, education, and retail — share common patterns:

Why failures happen

  1. Accessibility not included in requirements — specifications and user stories did not mention accessibility; teams built what was asked for
  2. Testing only with mouse and sighted users — standard QA did not include keyboard or screen reader testing
  3. Third-party product assumed to be compliant — vendor VPATs either did not exist or were not evaluated
  4. Content team not trained — developers delivered an accessible template; content team uploaded inaccessible documents
  5. No ongoing monitoring — accessibility was considered “done” after initial build, not maintained through content and feature updates

What successful remediation looks like

  1. Rapid response to identified issues — organizations that responded within weeks fared better legally and reputationally
  2. Systemic change alongside tactical fixes — organizations that only fixed reported issues faced repeated complaints; those that built processes and training prevented recurrence
  3. User testing as part of remediation — most successful remediations included testing with disabled users, not just technical audits
  4. Published commitments — accessibility statements with honest status and contact information reduce legal risk and build trust