AODA Compliance Requirements: Understanding WCAG 2.0 Level AA Standards

Meeting AODA compliance for your website means conforming to WCAG 2.0 Level AA standards—but what does that actually mean in practical terms? This guide breaks down the technical requirements, helping you understand exactly what your organization needs to implement to achieve and maintain AODA compliance.

The Foundation: WCAG 2.0 Level AA

The Web Content Accessibility Guidelines (WCAG) 2.0 are international standards developed by the World Wide Web Consortium (W3C). AODA specifically mandates WCAG 2.0 Level AA compliance for websites and web content, representing the middle tier of three conformance levels: A (minimum), AA (mid-range), and AAA (highest).

Level AA was chosen as the AODA standard because it addresses the most common and significant barriers faced by people with disabilities without imposing technically impossible requirements that Level AAA sometimes demands.

The Four Principles of WCAG 2.0

WCAG 2.0 organizes accessibility requirements around four fundamental principles, often remembered by the acronym POUR:

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive. This means:

Text alternatives: Every non-text element (images, icons, graphs) needs descriptive alternative text
Time-based media: Audio and video content requires captions, transcripts, or audio descriptions
Adaptable content: Information and structure must be separable from presentation
Distinguishable content: Users must be able to see and hear content, including sufficient color contrast

2. Operable

User interface components and navigation must be operable by all users:

Keyboard accessible: All functionality must be available via keyboard alone
Enough time: Users need sufficient time to read and interact with content
Seizure prevention: Content must not contain elements that flash more than three times per second
Navigable: Users need clear ways to navigate, find content, and determine their location

3. Understandable

Information and operation of the user interface must be understandable:

Readable text: Content should be readable and understandable
Predictable behavior: Web pages should appear and operate in predictable ways
Input assistance: Users should receive help avoiding and correcting errors in forms

4. Robust

Content must be robust enough to work with current and future assistive technologies:

Compatible: Content should maximize compatibility with assistive technologies like screen readers
Valid code: HTML and CSS should follow standards and specifications

Key AODA WCAG 2.0 Level AA Requirements

Let's examine the most critical Level AA requirements that trip up organizations:

Color Contrast (Success Criterion 1.4.3)

Normal text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold and larger) needs at least 3:1 contrast.

Common violations:

Light gray text on white backgrounds
Subtle colored text that looks stylish but fails contrast requirements
Text overlaid on background images without sufficient contrast

How to fix: Use color contrast checking tools during design, and ensure brand guidelines include accessible color combinations.

Captions for Videos (Success Criterion 1.2.4)

All prerecorded video content must include synchronized captions. This helps deaf and hard-of-hearing users but also benefits anyone watching videos in sound-sensitive environments.

Common violations:

Auto-generated captions without review (often inaccurate)
Marketing videos without any captions
Webinar recordings without synchronized captions

How to fix: Budget time and resources for professional captioning or caption review in your video production workflow.

Keyboard Navigation (Success Criterion 2.1.1 & 2.1.2)

Every interactive element must be reachable and operable using only a keyboard. Users must also be able to move focus away from any component using only the keyboard (no keyboard traps).

Common violations:

Custom dropdown menus that don't support arrow key navigation
Modal dialogs that trap keyboard focus
"Click here" elements built with <div> instead of semantic buttons

How to fix: Use semantic HTML elements (<button>, <a>, <input>) and test all interactions with keyboard only—no mouse.

Focus Visibility (Success Criterion 2.4.7)

Any keyboard-operable interface must have a visible focus indicator when elements receive keyboard focus.

Common violations:

CSS that removes the default focus outline without providing an alternative
Focus indicators with insufficient contrast
Focus indicators that are too subtle to notice

How to fix: Never use outline: none without providing a clear alternative focus style. Ensure focus indicators have at least 3:1 contrast.

Headings and Labels (Success Criterion 2.4.6)

Headings and labels must describe the topic or purpose of content.

Common violations:

Generic labels like "Click here" or "Read more" without context
Heading structures that skip levels (H1 to H3, skipping H2)
Using bold text instead of semantic heading tags

How to fix: Use descriptive labels, maintain proper heading hierarchy, and use semantic HTML heading elements.

Form Labels and Error Identification (Success Criteria 3.3.1 & 3.3.2)

Form inputs must have clearly associated labels, and errors must be clearly identified with suggestions for correction.

Common violations:

Placeholder text used instead of proper labels
Error messages that only use color to indicate problems
Generic error messages like "Invalid input" without specifics

How to fix: Always use <label> elements properly associated with inputs, and provide specific, helpful error messages.

Link Purpose (Success Criterion 2.4.4)

The purpose of each link must be determined from the link text alone or from the link text with its programmatically determined context.

Common violations:

Multiple "Click here" or "Read more" links without context
Icon links without descriptive text or labels
Ambiguous link text that doesn't indicate destination

How to fix: Use descriptive link text like "Read our AODA compliance guide" instead of "Click here."

Level AA vs Level A: What's the Difference?

AODA requires Level AA, which includes all Level A requirements plus additional criteria. Some organizations mistakenly believe meeting Level A is sufficient—it's not.

Level A addresses the most basic accessibility barriers. Without Level A compliance, some users with disabilities will find your content completely inaccessible.

Level AA addresses the most common barriers for people with disabilities. This level is considered the standard for most websites and is legally required under AODA.

Key requirements that are Level AA only (not Level A):

4.5:1 color contrast for normal text
Captions for live audio content
Audio descriptions for video content
Multiple navigation mechanisms
Focus visibility
Consistent navigation across pages

Technical Implementation Strategies

Meeting WCAG 2.0 Level AA requires both technical and organizational approaches:

1. Semantic HTML First

Use proper HTML elements for their intended purpose:

<button> for buttons, not <div> with click handlers
<nav> for navigation regions
<main> for main content
<h1> through <h6> for headings in proper hierarchy

2. ARIA When Necessary

ARIA (Accessible Rich Internet Applications) attributes enhance accessibility when semantic HTML isn't sufficient:

aria-label for elements without visible text labels
aria-live for dynamic content updates
aria-expanded for disclosure widgets
role attributes for custom components

Important: Incorrect ARIA is worse than no ARIA. Use sparingly and test thoroughly.

3. Progressive Enhancement

Build your website in layers:

Semantic HTML (works for everyone)
CSS for visual presentation
JavaScript for enhanced interactions

This ensures core functionality works even if CSS or JavaScript fails to load.

4. Automated Testing Integration

Incorporate accessibility testing into your development workflow:

Run automated scans during development
Include accessibility checks in CI/CD pipelines
Use browser extensions during QA
Monitor production sites continuously

Tools catch approximately 30-40% of accessibility issues—the rest requires manual testing with keyboard navigation and screen readers.

Common AODA Compliance Misconceptions

Misconception 1: "Automated tools ensure full compliance"

Reality: Automated tools catch only about 30-40% of accessibility issues. Manual testing with assistive technologies and real users is essential.

Misconception 2: "Accessibility overlays make us compliant"

Reality: Browser overlays and widgets claiming to make sites accessible have been widely criticized by accessibility experts and don't ensure AODA compliance. Real fixes require addressing code-level issues.

Misconception 3: "We're compliant once we fix all issues"

Reality: Accessibility is ongoing. Every new feature, content update, or design change can introduce new barriers. Continuous monitoring is essential.

Misconception 4: "Only public sector needs to comply"

Reality: AODA applies to private businesses with 50+ employees in Ontario, and increasingly, accessibility is expected by customers regardless of legal requirements.

Documentation and Reporting Requirements

AODA requires organizations to document their compliance efforts:

Accessibility policies: Written statements outlining your commitment to accessibility
Training records: Documentation that staff have received accessibility training
Feedback processes: Accessible methods for receiving and responding to accessibility feedback
Compliance reports: Regular assessments of compliance status

Maintaining detailed records demonstrates good-faith compliance efforts and helps track progress over time.

The Path Forward

Understanding WCAG 2.0 Level AA requirements is essential, but knowledge alone doesn't create accessible experiences. Implementation requires:

Executive buy-in and resource allocation
Designer and developer training
Integration into existing workflows
Ongoing testing and monitoring
Regular audits and remediation

Organizations that treat accessibility as a quality characteristic—not a compliance checkbox—build better products that serve all users effectively.

Ready to assess your current AODA compliance status? The next step is conducting a thorough accessibility audit to identify exactly where your website stands against WCAG 2.0 Level AA requirements. With a clear baseline, you can create a remediation roadmap that prioritizes the most impactful fixes first.

Continuous monitoring solutions like BrowseCheck help maintain compliance by alerting teams immediately when new accessibility issues are introduced, ensuring your site remains compliant as it evolves.