Web Accessibility in 2026: Meeting Edmonton's Standards
PublishedSAT, JAN 13, 2024
AuthorSalim Aden / Claude
Read Time13 min
Tags#Accessibility
Active Document
Web Accessibility in 2026: Meeting Edmonton's Standards
The 2026 web accessibility playbook for Edmonton businesses — WCAG 2.2 AA, the Accessible Canada Act, real screen-reader testing, new success criteria, and the specific patterns that actually ship.
Agency7's full architectural guide — from AI lead generation to autonomous financial operations.
Web Accessibility in 2026: Meeting Edmonton's Standards
Accessibility in 2026 is no longer a nice-to-have or a best-effort checklist. Under the Accessible Canada Act (ACA), regulated sector digital services must meet defined standards. Edmonton's public-sector RFPs increasingly require WCAG 2.2 AA compliance as a minimum bid criterion. And the practical reality — users who need accessibility features are a measurable portion of your audience regardless of law.
This is a working 2026 guide for Edmonton businesses and web developers: what the standards actually require, what real compliance looks like in code, and the patterns that hold up under testing.
The regulatory landscape — what applies to Edmonton in 2026
The most relevant frameworks in order of impact:
WCAG 2.2 Level AA — the de facto global standard. W3C's Web Content Accessibility Guidelines 2.2 (published October 2023) is what auditors, procurement officers, and lawsuits reference. Includes 13 success criteria beyond WCAG 2.1, most notably around target size, dragging, and focus visibility.
Accessible Canada Act (ACA) — federal law (2019) applying to federally regulated entities: banks, telecoms, transportation, federal government agencies. Enforceable standards reference WCAG 2.1 AA minimum, with 2.2 expected as the update lands.
AODA (Ontario) — applies to Ontario-based businesses with 50+ employees. Referenced as a signal of what Canadian accessibility maturity looks like even outside Ontario.
City of Edmonton Web Accessibility Standards — aligned with WCAG, explicitly required for City procurement and some public-sector contracts.
Alberta Human Rights Act — human rights complaints around inaccessible digital services have been successful. Legal risk is real even without an Alberta-specific digital-accessibility act.
Practical takeaway: design to WCAG 2.2 AA. It covers the Canadian, Edmonton, and most international obligations with one standard.
What WCAG 2.2 AA actually requires
WCAG 2.2 organizes 50+ success criteria under four principles: Perceivable, Operable, Understandable, Robust (POUR). The AA level covers most real-world accessibility concerns. Key requirements:
Perceivable
Text alternatives for all non-text content (alt text on images, transcripts for audio, captions for video)
Color contrast 4.5:1 for body text, 3:1 for large text (over 18pt or 14pt bold)
Resize text up to 200% without loss of content or functionality
Images of text avoided unless essential (logos excluded)
Reflow — content must work at 320 CSS pixels wide without horizontal scrolling (mobile-first underpinning)
Non-text contrast 3:1 for UI components and meaningful graphics
Operable
Keyboard accessible — every interaction must work with keyboard alone
No keyboard trap — users can tab into and out of every element
Focus visible — the element with keyboard focus must be visually distinct (WCAG 2.2 strengthened this)
Target size 24×24 CSS pixels minimum for pointer inputs (new in WCAG 2.2). Real-world target: 48×48.
Dragging movements — any dragging interaction must have a non-dragging alternative (new in WCAG 2.2)
No seizure-inducing flashes (3 flashes per second max)
Consistent navigation across pages
Understandable
Language of page declared (<html lang="en">)
Error identification and suggestion on forms
Labels or instructions on all form inputs
Consistent identification — the same function is labeled the same way across pages
Redundant entry avoided (new in WCAG 2.2) — don't ask for the same info twice in a flow
Accessible authentication — cognitive function tests (like "type the characters in this image") need an accessible alternative (new in WCAG 2.2)
3.2.6 Consistent Help (A) — help mechanisms in the same location across pages
3.3.7 Redundant Entry (A) — don't require re-entering info in a flow
3.3.8 Accessible Authentication (Minimum) (AA) — no cognitive function tests without alternative
3.3.9 Accessible Authentication (Enhanced) (AAA) — stricter version
If you were audited to 2.1 AA in 2022 and haven't revisited, you likely fail several of these today.
What this looks like in code
Concrete patterns that pass WCAG 2.2 AA in a modern React/Next.js stack:
Semantic HTML, not ARIA-everywhere
// Good — native semantics, zero ARIA needed
<button type="submit">Request quote</button>
// Bad — ARIA pasted onto a div
<div role="button" tabIndex={0} onClick={...} aria-label="Request quote">
Request quote
</div>
Native HTML elements have built-in keyboard handling, focus management, and screen reader announcement. ARIA is a patch for when no native element fits. Default to native.
Skip links
<a href="#main-content" className="skip-link">Skip to main content</a>
<header>...</header>
<main id="main-content">...</main>
Invisible until focused via Tab. Essential for keyboard users navigating past repetitive headers.
Use :focus-visible (not :focus) so focus rings show for keyboard users but not mouse clickers. WCAG 2.2 strengthened focus-visibility requirements — do not remove focus outlines without replacement.
Labels associated with inputs, error messages connected via aria-describedby, status-message announcements via role="alert" — all baseline AA requirements.
Color contrast
Body text against background must hit 4.5:1. Large text (18pt+, or 14pt+ bold) needs 3:1. UI components and meaningful graphics need 3:1. Tools that make this easy:
axe DevTools browser extension — live contrast checking
Contrast Checker (WebAIM) — pair colors, see ratios
Figma contrast plugins (A11y, Able) — check at design time
The most common failure: stone-400 text on stone-50 backgrounds ("soft and modern" look) fails by a wide margin. Bump body text to stone-700 or darker.
Or at the component level — disable parallax, autoplay, and complex transitions when the user has set the OS-level preference.
Modal dialogs
Focus trapped inside the modal while open, focus returned to the trigger when closed, Escape key closes. Use a tested library like Radix or React Aria — do not hand-roll.
Testing — what actually catches issues
Automated tools catch about 20–30% of accessibility issues. The remaining 70%+ need human testing.
Automated testing (first pass)
axe-core — integrated into Jest, Cypress, Playwright; also browser extension. Catches contrast, missing alt, invalid ARIA, form-label issues.
Lighthouse accessibility audit — 100 score is the baseline, not the finish line
WAVE — visual overlay that highlights structural and contrast issues
pa11y — CI-integrated accessibility testing
ESLint jsx-a11y plugin — catches obvious issues at code-review time
Set axe-core thresholds in CI so regressions block merges. 20 minutes of setup saves months of debt.
Manual testing (what actually works)
Keyboard-only navigation — unplug the mouse, try to complete every core flow using Tab, Shift+Tab, Enter, Space, arrow keys. Most bugs surface in 10 minutes.
Screen reader walkthrough — VoiceOver on macOS (Cmd+F5) or NVDA on Windows (free). Navigate the homepage, a product page, and the main conversion flow. Does everything announce sensibly?
Mobile screen reader — VoiceOver on iOS, TalkBack on Android. Mobile accessibility is genuinely different and frequently worse than desktop.
200% zoom test — set browser zoom to 200%. Is the layout usable? Does content reflow?
High contrast mode — Windows High Contrast or macOS Increase Contrast. Are borders visible? Do focus rings show?
Color-only state test — convert a screenshot to greyscale. Can you tell which elements are interactive? Which are errors? Which are selected?
User testing with assistive tech users
The gold standard, often skipped because it feels expensive. Fable Tech Labs, AccessibilityOz, and some Edmonton accessibility consultants offer paid user testing with disabled participants. Even one round catches issues no automated tool ever will.
Edmonton-specific accessibility context
Concerns that show up in Edmonton client work specifically:
Public-sector RFPs — City of Edmonton, Government of Alberta, federal department contracts increasingly require WCAG 2.2 AA certification. Some require VPAT (Voluntary Product Accessibility Template) documentation.
Indigenous language support — some public-sector sites now require Cree or Michif content. Test that your components handle syllabic characters and extended Unicode correctly.
French-language obligations — any federal-contracted or Quebec-facing site must meet parallel French accessibility (screen readers in French, etc.).
Winter-related accessibility — temporary disability from frostbite, winter medication effects, or cold-weather motor difficulty are more common Nov-March. Forgiving interactions (larger tap targets, drag alternatives, voice input) help in ways that don't show up in standard persona modeling.
Health region considerations — any site touching Alberta Health Services workflows must meet ACA-equivalent standards plus HIA privacy requirements.
Education sector — Edmonton Public Schools, Catholic Schools, and post-secondary institutions (U of A, MacEwan, NAIT) have internal accessibility requirements that often exceed WCAG 2.2 AA.
Business case for accessibility beyond compliance
The honest arguments — not just the moral ones:
Market size — ~22% of Canadian adults identify as having one or more disabilities (StatCan, 2022). Edmonton mirrors this. Inaccessible sites exclude roughly 1 in 5 customers.
SEO overlap — semantic HTML, alt text, proper headings, mobile-responsive design are both accessibility wins and ranking signals. See SEO Strategies for Edmonton Websites.
AI search visibility — accessible, well-structured content is what AI crawlers (GPTBot, ClaudeBot, PerplexityBot) extract most reliably. See E-E-A-T Signals for AI Search Engines.
Risk mitigation — Canadian accessibility lawsuits have been filed (Donna Jodhan v. Canada, 2012 onward). US ADA lawsuits against Canadian companies with US customers are rising.
Conversion lift — accessible forms, clear focus states, and readable typography consistently test better in conversion rate optimization studies. "Accessibility is UX" is more literal than marketing makes it sound.
Common accessibility failures in Edmonton sites
Issues we see weekly in audits:
Low-contrast marketing copy — grey on grey body text failing 4.5:1
Click-only carousels — no keyboard or reduced-motion alternative
Cookie consent modals that trap keyboard focus — can't tab past them
Missing or bad alt text — "image1.jpg" or empty alt on meaningful images
Form errors announced only visually — no role="alert" or aria-live
Icon buttons with no accessible name — <button><svg>...</svg></button> with no aria-label
Links styled as buttons (and vice versa) — screen reader users hear the wrong thing
Autoplay video with no pause control — fails AA
PDFs embedded as "documents" — often not accessible; prefer HTML
"Click here" links — no context for screen readers listing links out of order
What to budget for an Edmonton accessibility audit + remediation
Is WCAG 2.2 AA legally required for Edmonton businesses?
Federally regulated businesses (banks, telecoms, airlines, federal agencies) must meet ACA standards referencing WCAG 2.1 AA, with 2.2 adoption underway. Provincially regulated businesses in Alberta have no specific digital accessibility law as of 2026, but Alberta Human Rights complaints have succeeded, and public-sector procurement often requires WCAG 2.2 AA. For private-sector small businesses, it is not strictly required — but risk, market, and ethics all point toward compliance.
What is the difference between WCAG A, AA, and AAA?
Level A is the minimum (blocker-level issues); AA is the common legal and procurement standard (covers most real accessibility needs); AAA is the strictest (rarely required wholesale — some criteria like sign language for all prerecorded video are impractical for most sites). Target AA for all production sites.
How do I test my Edmonton site for accessibility right now?
Install axe DevTools (free browser extension), run it on your homepage, and read the results. Then unplug your mouse and try to reach your main conversion CTA using keyboard only. These two tests surface most issues in 15 minutes.
Does my site need an accessibility statement?
Yes. Every compliant site should have a page stating what level is targeted (e.g., "WCAG 2.2 AA"), known limitations, how to report issues, and contact info. It's both a WCAG best practice and a legal risk mitigator.
Are automated accessibility tools enough?
No. Tools like axe, Lighthouse, and WAVE catch 20–30% of issues — usually contrast, missing alt, invalid ARIA. They cannot catch misused labels, illogical focus order, poor language choices, or interactions that make sense visually but not via screen reader. Manual keyboard and screen reader testing is mandatory.
What is the most common accessibility mistake on Edmonton sites?
Low-contrast body text. "Soft grey" copy against white or light backgrounds. It looks modern but fails WCAG 4.5:1 contrast, which is the baseline AA requirement. It's also the easiest to fix.
Do I need a VPAT for my business?
Only if you sell to government, education, or enterprise clients who require it. VPAT (Voluntary Product Accessibility Template) is a standardized document describing your product's accessibility. For consumer-facing Edmonton SMBs, a public accessibility statement is sufficient.
How does accessibility affect SEO?
Strongly positively. Semantic HTML, alt text, proper heading hierarchy, keyboard accessibility, and mobile-first design are accessibility requirements that overlap directly with SEO best practices. Accessible sites rank better on average.
Will AI help with accessibility auditing in 2026?
Partially. AI can generate decent alt-text drafts, identify contrast issues, and flag obvious keyboard problems. But AI currently cannot reliably audit screen reader logic, focus order, cognitive load, or lived-experience issues. Use AI as a first pass, not a replacement for real testing.
How long does it take to bring an existing Edmonton site to WCAG 2.2 AA?
For a well-built 2022+ site with good semantic HTML, 2–6 weeks of focused work (audit, remediation, retest). For a legacy site with heavy DIV-soup markup and custom controls, expect 2–6 months or a ground-up rebuild. Most small Edmonton businesses fall in the first category.
Is PDF accessibility different from web accessibility?
Yes. PDFs have their own accessibility requirements (tagged PDFs, reading order, alt text on embedded images). Accessible PDFs are expensive to produce and maintain. Where possible, publish content as HTML instead — it is always more accessible than PDF.
What about AI-generated images and accessibility?
AI-generated images still need human-authored alt text. Auto-generated alt from Midjourney, Firefly, or DALL-E outputs tends to be generic ("an image showing a person") and fails real screen-reader utility. Write alt text by hand that describes the image's role and meaning in context.
If your Edmonton site has never been audited for WCAG 2.2 AA, book a free 30-minute accessibility review — we'll identify the top three issues likely blocking compliance and give you a specific remediation scope.
