Frequently Asked Questions

No. Accessibility improvements benefit a far wider population than people with permanent disabilities.

In Canada, approximately 22% of adults report a disability. But the same design solutions also serve:

• Users with temporary disabilities (broken arm, post-surgery recovery)
• Users with situational constraints (one hand occupied, bright sunlight, noisy environment)
• Older adults with age-related changes to vision, hearing, and motor control
• Users on slow mobile connections
• Users in challenging physical environments (gloves, outdoor screens)
• Non-native language speakers who benefit from plain language
• Users on low-end devices or older browsers

When you add captions to a video, you serve Deaf users, hard-of-hearing users, users in a quiet office without headphones, and users in a noisy café. The same file, the same feature, serving all of them.

An estimated 100% of people will experience some form of disability at some point in their lives — through aging alone if nothing else. Accessibility is designing for the full range of human variation, not a small niche.

The most impactful accessibility improvements are low cost:

• Adding alt text to images: writing time only — no development cost
• Using correct heading styles: writing habit change — no development cost
• Writing descriptive link text: writing habit change — no development cost
• Adding <label> elements to form fields: 30 minutes of development time per form
• Increasing colour contrast: one design token change — 1 hour of work
• Adding captions to video: 1–2 hours per video using corrected auto-captions

The WebAIM Million annual study consistently finds that the most common accessibility failures — missing alt text, poor contrast, missing form labels, empty links — are also the fastest and cheapest to fix. These are not architectural problems; they are execution habits.

The expensive option is not building accessibly from the start and then remediating later. Retrofitting accessibility into a completed website or application costs 5–10× more than including it during design and development. For small organizations, the cost-effective approach is to build habits, not to remediate.

For organizations under AODA, non-compliance carries penalties up to $100,000 per day for corporations. The cost of a day’s penalty exceeds the cost of most accessibility programs.

No. WCAG specifies outcomes (minimum contrast ratios, keyboard operability, text alternatives) — not aesthetics. Within those outcomes, you have complete creative freedom.

Some concrete examples:

• Contrast: WCAG requires a 4.5:1 ratio for normal text. This includes every colour in the spectrum — deep teal, warm amber, forest green, charcoal — as long as the ratio is met. It does not require black text on white backgrounds.
• Animation: WCAG requires that animations can be paused and that motion respects the user’s preference. It does not prohibit animation — it requires that animation be a choice, not an imposed experience.
• Layout: WCAG requires that content reflows at 320px and that focus order is logical. Grid layouts, asymmetric compositions, and complex visual hierarchies are all compatible with these requirements.
• Typography: WCAG requires readable font sizes and adequate line height. It does not specify which fonts to use.

Many highly regarded design systems — including the Government of Canada design system, GOV.UK Design System, and Australia’s Digital Design System — meet WCAG AAA while maintaining strong design identity. The constraint is a forcing function toward clarity and legibility, which improves design for all users.

Passing an automated scan means you have addressed the issues that automated tools can detect. This is approximately 30–40% of all WCAG failures.

Automated tools check for machine-verifiable conditions: an image has an alt attribute (but cannot assess whether the alt text is meaningful), a form field has a label (but cannot assess whether the label is accurate), contrast ratios meet thresholds.

Automated tools cannot check:

• Whether alt text describes the image correctly
• Whether heading levels reflect the document structure logically
• Whether a custom interactive component is keyboard accessible
• Whether focus order is logical
• Whether form error messages are specific and actionable
• Whether a screen reader user can complete the primary task
• Whether a keyboard-only user can navigate without getting trapped
• Whether link text makes sense out of context

Passing an automated scan is a necessary but not sufficient condition for accessibility. Full WCAG conformance requires manual testing: keyboard walkthrough, screen reader testing, and ideally user testing with people with disabilities.

Under Canadian law (AODA, ACA), the obligation is conformance — not passing a scan. An organization that passes an automated scan but has a keyboard trap on its primary checkout flow is non-compliant.

It depends on whether employees or customers use it — and under which law.

Internal tools used by employees: If any employee has a disability that requires accessible software, you have a duty to accommodate under the Canadian Human Rights Act (federal employees) or provincial human rights codes. An internal HR system, a project management tool, or an internal portal that is inaccessible to an employee with a disability is a potential human rights violation.

B2B websites: Even if you only sell to businesses, the people at those businesses who use your site include people with disabilities. The AODA applies to organizations with one or more employees in Ontario, regardless of whether their customers are individuals or other organizations.

Intranets and internal portals: The AODA’s web accessibility requirements apply to websites, web applications, and web content made available to the public or to employees. An inaccessible intranet in an Ontario organization is an AODA violation.

The practical answer: Any digital interface used by employees or customers may need to be accessible. The key question is whether it is used by people who may have disabilities — which is effectively everyone.

An accessibility audit addresses the state of your site at the moment the audit was conducted. Accessibility degrades continuously as:

• New content is published (images without alt text, videos without captions)
• New features are added (custom components without keyboard support)
• Third-party scripts are loaded (analytics widgets, chat tools, video embeds that may not be accessible)
• Templates are modified (a redesigned header that removes the skip link)
• The underlying framework or CMS is updated

Organizations that treat accessibility as a one-time project consistently report that issues return within months of remediation. Accessibility requires:

1. Ongoing testing: automated scans in the CI/CD pipeline, periodic manual audits
2. Training: content authors, designers, and developers need skills to maintain accessibility, not just fix it once
3. Process integration: accessibility review in the definition of done for every feature and content update
4. Monitoring: scheduled screen reader walkthroughs of key user flows at least quarterly

The audit is the starting point, not the finish line.

You can — but it is significantly more expensive and time-consuming than building accessibly from the start.

Industry data consistently shows that fixing accessibility issues in production costs 5–10 times more than fixing them during design and development. Specific reasons:

• Design decisions (colour palette, component patterns, navigation structure) may need to be revisited and the changes cascaded through the entire design system
• Development changes to fundamental components (form patterns, modal dialogs, navigation) require regression testing across the full site
• Content remediation (alt text, captions, accessible PDFs) requires time proportional to the volume of content — a site with 3,000 pages of untagged content requires significant manual effort

The most cost-effective approach is the “shift left” principle from software development: address accessibility requirements at the requirements stage, evaluate accessibility during design review, test during development, and verify before launch.

Post-launch remediation is sometimes unavoidable — legacy sites, acquired products, and inherited content all require it. When it is necessary, prioritize by impact: fix the barriers on the highest-traffic pages and primary user flows first.

For Canadian compliance:

• The AODA references WCAG 2.0 Level AA — technically, meeting 2.0 satisfies the AODA’s minimum web standard
• The Accessible Canada Act references EN 301 549, which incorporates WCAG 2.1 AA — federal organizations should target WCAG 2.1
• The Canadian Human Rights Act and provincial codes do not specify a WCAG version — conformance is assessed in context

However, WCAG 2.0 is from 2008. Targeting only WCAG 2.0 AA means missing 17 success criteria added in WCAG 2.1 that address:

• Mobile accessibility (touch gestures, orientation, reflow)
• Low vision (non-text contrast, text spacing, content on hover)
• Cognitive disabilities (timeouts, AAC support)

For any new development, WCAG 2.1 AA is the practical minimum that reflects current best practice. For organizations under AODA, targeting WCAG 2.1 AA provides a meaningful margin above the minimum and reduces the risk of non-compliance under the CHRA or ACA if your organization spans jurisdictions.

WCAG 2.2 (2023) adds 9 more criteria, primarily for cognitive and motor accessibility. Organizations building new products should review these criteria even if not yet required.

Yes, if those PDFs contain information required to access your services or understand your organization.

Under the AODA, organizations must make their websites and web content accessible. Content published on a website — including PDFs — is covered. The AODA does not create a blanket exception for PDFs.

Under human rights law, if a person with a disability cannot access a PDF containing essential information (a form they must complete, a policy they must read, instructions they must follow), the organization has a duty to provide an accessible alternative.

Practical guidance:

• PDFs that are purely decorative (a photo PDF, a branded one-pager with no content) may not require full accessibility treatment
• PDFs containing essential information (applications, policies, instructions, reports) should be either made accessible (tagged, structured) or provided as accessible HTML alongside the PDF
• PDFs that are scanned images (common for older documents) require OCR and manual tagging to become accessible
• Going forward, publishing essential content as HTML first (with a PDF version optional) is the most sustainable approach

See Plain Language Writing — Accessible PDFs for implementation guidance.

Your organization’s social media activity should follow accessibility best practices, though enforcement is less direct than for your own website.

What you can control on social media:

• Alt text on images: most major platforms (Twitter/X, LinkedIn, Facebook, Instagram) support alt text on images — use it
• Captions on video: upload caption files or use the platform’s built-in captioning tools, then review for accuracy
• Plain language: accessible writing benefits all followers
• Hashtag formatting: use CamelCase hashtags (#AccessibleCanada not #accessiblecanada) — screen readers read CamelCase word by word instead of as one run-on word
• Emoji use: use emoji sparingly at the end of content — screen readers announce emoji descriptions; a string of 10 emojis creates a terrible listening experience
• Link text: when sharing URLs, ensure the surrounding text describes the destination

What the platform controls: The platform’s own interface accessibility is outside your control. If a platform is inaccessible, that is the platform’s issue — though organizations may want to consider whether a given platform is accessible to their audience.

The AODA does not apply to third-party platforms — it applies to your website and web content you publish and control.

No. Screen reader testing is one important testing method among several, and it is not the right starting point.

Recommended testing order:

1. Automated scan (axe DevTools) — fast, catches ~30–40% of issues, free
2. Keyboard walkthrough — complete the primary user flow by keyboard only; catches interaction and focus issues no tool finds; takes 1–2 hours for a medium site
3. Colour contrast check — Colour Contrast Analyser or WebAIM Contrast Checker; catches contrast failures in non-standard states
4. Screen reader testing — NVDA+Chrome or VoiceOver+Safari; catches semantic HTML and ARIA issues; takes 2–4 hours for a medium site
5. User testing with disabled users — Fable or direct recruitment; catches usability issues that technical testing misses; most valuable, most time-intensive

Each method catches different issues. An organization doing only screen reader testing will miss keyboard traps (visible in keyboard testing), contrast failures (visible in contrast tools), and cognitive usability issues (visible only in user testing).

See Testing and Evaluation for a complete testing methodology.

Well-implemented accessibility improves or does not affect performance. Poorly implemented accessibility can occasionally add minor weight — but this is not an inherent trade-off.

How accessibility improves performance:

• Semantic HTML loads before JavaScript and CSS — a page built on semantic HTML renders meaningfully before scripts load
• Text content loads before images — alt text appears when images have not yet loaded or fail to load
• Progressive enhancement (the underlying principle of accessibility) means basic content is available immediately
• Avoiding heavy JavaScript for interactive components (using native HTML instead) reduces bundle size

Where accessibility might add weight:

• Verbose ARIA attributes add minimal HTML size
• Caption tracks are separate files loaded by the player on demand — not on page load

The real performance–accessibility trade-off is opposite to what people assume: JavaScript-heavy, framework-dependent, visually complex sites are both less accessible and slower. Semantic, progressively enhanced sites are both more accessible and faster.

Organizations that improve accessibility in parallel with performance tend to find they are complementary goals.

Everyone involved in creating or publishing content, designing interfaces, writing code, making procurement decisions, or setting organizational policy has accessibility responsibilities.

A brief summary by role:

• Executive / Leadership: budget, policy, accountability structure, procurement standards
• Product Manager: requirements, prioritization, definition of done
• Designer: contrast, focus states, touch targets, information architecture, motion
• Developer: semantic HTML, keyboard interactions, ARIA, focus management
• Content Author: alt text, headings, link text, captions, plain language
• QA: automated scans, keyboard testing, screen reader testing in release pipeline
• Procurement: RFP requirements, vendor evaluation, contract language

The most common failure is treating accessibility as exclusively a developer concern. Developers can only implement what is designed and specified. Designers can only specify within the creative brief they are given. Content authors can only maintain what they are trained to maintain.

See Roles and Responsibilities for detailed accountability by role.

Accessibility and usability are related but distinct:

Accessibility: Can people with disabilities access and use the interface at all? Assessed against WCAG criteria. A screen reader user who can technically navigate every element on a form — but must Tab through 40 fields to find the one they need — has an accessible (technically) but unusable interface.

Usability: Can people complete their goals efficiently, effectively, and with satisfaction? Assessed through user research, task success rates, and satisfaction measures.

The overlap is significant: accessible interfaces tend to be more usable for all users. Plain language, consistent navigation, clear error messages, and logical structure benefit everyone. But a WCAG-conformant site can still be highly unusable, and a usable site for non-disabled users may be completely inaccessible to users with disabilities.

The goal is both: accessible and usable. WCAG compliance is the floor, not the ceiling.

WCAG Level AA is the standard most Canadian organizations must meet and is the internationally recognized professional standard for web accessibility.

Meeting Level AA means:

• Users who are blind can access all content and complete all tasks using a screen reader
• Users who are Deaf can access all audio content through captions and transcripts
• Users with motor disabilities can navigate the entire site by keyboard without a mouse
• Users with low vision can resize text to 200% without losing content or functionality; text meets 4.5:1 minimum contrast
• Users with cognitive disabilities can navigate consistently, understand error messages, and complete forms with labels and instructions
• Users with vestibular disorders and photosensitive conditions are not exposed to dangerous motion or flash

It does NOT mean:

• The site is perfectly usable by all users with all disabilities (AAA criteria and usability improvements go beyond AA)
• Users will never encounter any difficulty (there is always room to improve)
• The site has been tested with actual users with disabilities (WCAG is testable without user testing)

Level AA represents approximately 50 success criteria across the four POUR principles. It is achievable with standard development and design practices, and it is the legal minimum for most Canadian organizations.

An accessibility statement demonstrates that you have considered accessibility and made commitments about it. It is generally a positive factor in legal and regulatory contexts, but it does not provide legal immunity.

What an accessibility statement does:

• Demonstrates good faith engagement with accessibility requirements
• Provides a channel for users to report accessibility barriers — which you are then expected to address
• Is required under the AODA for organizations of certain sizes
• Demonstrates organizational accountability

What an accessibility statement does not do:

• Make an inaccessible site compliant
• Protect against human rights complaints if your site creates actual barriers for users with disabilities
• Substitute for technical conformance with WCAG

A statement saying “we are committed to accessibility” on a site that fails basic WCAG criteria is not a legal shield — it may actually draw attention to the gap between commitment and reality.

The most legally protective approach is: have an honest accessibility statement that accurately describes your current conformance level, lists known limitations, and provides a responsive feedback mechanism — and back it up with actual conformance work.

See Accessibility Statement for this site’s own statement and a template for yours.