Accessibility Foundations (AODA/WCAG): What “Built In” Actually Means

Accessibility Foundations (AODA/WCAG): What “Built In” Actually Means

Accessibility gets discussed too late on most projects. Teams say, “We’ll handle it after,” then discover that “after” means redesigning components, rewriting interactions, and paying for retrofits.

The better approach is to build accessibility foundations into the product experience from day one. That does not automatically mean formal compliance certification. It means you reduce risk and future cost by making the UI structurally accessible before the product grows.

This post explains what “built in” should mean in plain terms.

AODA vs WCAG (simple context)

AODA is Ontario’s accessibility legislation. WCAG is the widely used standard for web accessibility guidelines. In practice, when teams talk about “building to AODA,” they usually mean building toward WCAG-aligned accessibility practices and meeting applicable requirements for the product or organization.

The important takeaway: accessibility is not a single toggle. It is a set of design and implementation decisions that must be reinforced with testing.

What “accessibility foundations” should include

Accessibility foundations are the patterns you bake into the interface so the product can be accessible without heroic effort later.

1) Semantic structure (the base layer)

• Headings are real headings and follow a logical order
• Buttons are real buttons, not clickable divs
• Forms use proper labels tied to inputs
• Landmarks exist (header, nav, main, footer)

If the structure is wrong, everything built on top becomes harder to fix.

2) Keyboard navigation and focus behavior

• You can navigate with Tab and Shift+Tab logically
• Focus states are visible and consistent
• Modals trap focus and return focus properly when closed
• Dropdowns, menus, and drawers are keyboard usable

If keyboard users can’t operate the product, accessibility is broken even if it “looks fine.”

3) Clear labels and accessible naming

• Every form control has a label
• Icon-only buttons have accessible names
• Error messages are associated with the correct field
• Instructions are clear and not only conveyed by placeholder text

4) Color contrast and non-color cues

• Text meets reasonable contrast against backgrounds
• Important information is not conveyed by color alone
• States like error/success include text and icon cues, not just color

5) Motion and animation safety

• Animations are subtle and do not cause discomfort
• Reduced motion preferences are respected where possible
• Transitions do not block interaction or hide focus

Motion can be part of a premium UI, but it needs to be respectful.

6) Accessible component patterns

If your UI uses a component library, accessibility should be enforced at the component level:

• Buttons
• Inputs and validation patterns
• Modals and dialogs
• Toasts and alerts
• Menus and dropdowns
• Tabs and accordions
• Tables and pagination

If components are accessible, every screen built from them inherits that strength.

What “built in” does not automatically include

This is where teams get tripped up.

1) Formal compliance certification

Accessibility foundations reduce risk, but certification-level confidence typically requires:

• Manual testing
• Assistive technology testing
• QA against specific WCAG success criteria
• Documentation of findings and fixes

If a vendor promises “fully compliant” without a testing plan, treat it cautiously.

2) Perfect accessibility for every edge case

Real accessibility is an ongoing practice. New features can introduce new barriers. That’s why foundations matter: they keep you from reintroducing the same problems repeatedly.

Why retrofits are expensive

Accessibility retrofits cost more because they often require:

• Redesigning components (especially forms and modals)
• Reworking navigation and keyboard behavior
• Untangling inconsistent UI patterns
• Rewriting markup and re-implementing interactions

When accessibility is built into the component system early, you avoid repeating the same fixes across dozens of screens.

A simple accessibility baseline checklist

If you want a “good foundations” bar, validate these:

• All interactive elements are keyboard reachable
• Focus is visible and logical
• Forms have labels and clear errors
• Modals trap focus and are dismissible
• Color contrast is reasonable
• Headings are structured logically
• No critical info is only shown via color
• Icon buttons have accessible names

If these basics are true, you’ve reduced major risk.

Where Protiva fits

Protiva’s goal is to bake accessibility foundations into the prototype and code foundations so you do not have to retrofit basics later. That typically includes:

• Semantic structure
• Keyboard and focus patterns
• Accessible component patterns
• Reasonable contrast and readable layouts

If deeper accessibility testing or formal compliance work is required, that should be scoped as an explicit add-on with a defined testing plan.

The bottom line

“Built in accessibility” should mean accessible foundations at the component and structure level, reinforced by predictable patterns across the product. It reduces risk and future retrofit cost.

If you need certification-level assurance, plan for testing and audits as a distinct scope, not a vague promise.