Ontario businesses are approaching an important accessibility date. The Government of Ontario says businesses and non-profit organizations with 20 or more employees must file an accessibility compliance report by December 31, 2026. For an organization with a public website, that reporting process is a good reason to verify what rules apply and whether the site still works for people who navigate, read, hear, or interact with content differently.
For a growing company in Toronto, an accessibility problem can be as ordinary as a contact form with unclear errors, a navigation menu that cannot be operated by keyboard, pale text on a light background, or a service image with no useful alternative text. These barriers affect real customers. They can also expose gaps between what an organization reports and what its website actually delivers.
This guide explains the main Ontario thresholds, offers a practical website review, and shows how to turn findings into an accountable improvement plan. It is general operational information, not legal advice. Confirm your organization's obligations using Ontario's official resources or qualified counsel, especially if its employee count, sector, jurisdiction, or web properties are complex.
Start with the deadline and the correct employee threshold
Ontario's accessibility rules vary by organization type and size. The province says businesses and non-profits with 20 or more employees must submit an accessibility compliance report by December 31, 2026. Organizations with 1 to 19 employees must still comply with applicable AODA requirements but do not file that report. Public-sector reporting follows a different schedule, so those organizations should use the public-sector guidance instead.
For websites, Ontario says a business or non-profit with 50 or more employees must make its public websites and web content accessible. The stated standard is WCAG 2.0 Level AA, other than live captions and pre-recorded audio descriptions, and the guidance covers web content posted after January 1, 2012. The regulation and official guidance contain the authoritative wording and exceptions.
| Organization situation | What to investigate | Useful next action |
|---|---|---|
| 1–19 employees | Applicable AODA duties even though no 2026 compliance report is required | Use Ontario's self-assessment resources and remove high-impact customer barriers |
| 20–49 employees | December 31, 2026 reporting requirement; the 50-employee public-website rule may not apply | Review every report question and retain evidence supporting each response |
| 50 or more employees | Reporting requirement plus the public-website and web-content accessibility requirement | Perform a scoped WCAG review, remediate barriers, retest, and document the result |
| Public-sector or federally regulated organization | Different schedules or legal frameworks may apply | Confirm jurisdiction and use the correct official guidance before making compliance claims |
Inventory the website before testing individual pages
An audit can miss serious barriers if it checks only the homepage. Build an inventory of the public experience first. Include service and product pages, contact and quote forms, account sign-in, checkout, appointment booking, job applications, embedded maps, document downloads, videos, support widgets, cookie controls, and third-party portals reached from the main site.
- Record every domain, subdomain, campaign landing page, and customer-facing application owned or controlled by the organization.
- Identify repeated templates so one navigation or component fix can improve many pages.
- List PDFs, Word documents, slide decks, menus, catalogues, and downloadable forms that customers need.
- Map third-party services such as booking, payment, chat, careers, and email-signup tools to an internal owner and vendor contact.
- Prioritize essential journeys: contacting the business, requesting a quote, buying, paying, applying, signing in, and obtaining support.
- Note content age and publication date because Ontario's website guidance refers specifically to content posted after January 1, 2012.
1. Make content perceivable
Perceivable content can be presented in ways people can detect. A person who cannot see an image needs a meaningful text alternative when the image communicates information. A person with low vision needs sufficient contrast and content that remains usable when text is enlarged. A person who cannot hear a recorded explanation needs an appropriate text alternative, such as captions or a transcript.
- Give informative images concise alternative text that describes their purpose in context; use empty alt text for genuinely decorative images.
- Do not place essential instructions, prices, phone numbers, or calls to action only inside an image.
- Check text and meaningful interface controls for sufficient colour contrast, including hover, focus, disabled, and error states.
- Confirm text can resize and the page can zoom without hiding content or forcing unnecessary two-dimensional scrolling.
- Provide captions for recorded video with meaningful speech and sounds; provide transcripts when they improve access to audio information.
- Use headings, lists, tables, and landmarks according to meaning so assistive technology receives the same structure visible on screen.
2. Make every important action operable by keyboard
Put the mouse aside and navigate with Tab, Shift+Tab, Enter, Space, and the arrow keys. Every interactive control should be reachable, usable, and visibly focused in a logical order. The keyboard focus must not become trapped inside a menu, modal, calendar, carousel, chat widget, or cookie banner.
- Provide a working skip link so repeat visitors can move directly to main content.
- Keep the visible focus indicator easy to find against every background.
- Match keyboard order to the visual and reading order of the page.
- Use real buttons for actions and links for destinations instead of clickable non-semantic containers.
- Allow users to pause, stop, or control moving and automatically updating content where required.
- Avoid interactions that depend only on dragging, hovering, complex gestures, or precise pointer movement.
3. Fix forms, labels, instructions, and errors
Forms are where accessibility barriers become lost leads. A field needs a programmatically associated label, not only placeholder text. Required fields and accepted formats should be explained before submission. When validation fails, the message should identify the field, explain the problem in plain language, and help the person correct it without losing completed work.
| Common problem | Customer impact | Better implementation |
|---|---|---|
| Placeholder used as the only label | The instruction disappears and may not be announced reliably | Persistent visible label associated with the input |
| Error shown only with a red border | Colour alone does not explain what failed or how to fix it | Text message, error summary, field association, and visible indicator |
| Timeout without warning | A person who needs more time can lose the whole form | Advance warning and a way to extend or save progress where required |
| Inaccessible CAPTCHA | A customer may be unable to submit at all | Accessible anti-abuse approach with an equivalent alternative |
| Generic button text such as 'Click here' | Purpose is unclear outside the visual context | Specific action text such as 'Request a website assessment' |
4. Keep navigation and language understandable
Consistency reduces effort. Navigation labels, search, breadcrumbs, form instructions, and help should behave predictably across the site. Set the page language correctly, identify language changes where needed, use descriptive headings and link text, and write important instructions in plain language.
Bilingual or multilingual Canadian websites need separate attention for each language version. An English page can pass while its French equivalent has missing labels, an incorrect language declaration, or a different third-party component. Test the actual localized experience rather than assuming the template makes every translation accessible.
5. Use robust HTML before adding ARIA
Semantic HTML gives browsers and assistive technologies reliable information about headings, buttons, links, form controls, tables, and page regions. Native elements usually provide more correct behaviour than a generic element rebuilt with JavaScript and ARIA. Use ARIA only when necessary, keep names and states accurate, and test the final interaction with assistive technology.
- Keep heading levels meaningful and avoid choosing a heading only for its visual size.
- Give every page a specific title and every control an accessible name.
- Associate data-table headers with the cells they describe.
- Announce dynamic status, validation, and loading changes when users need that information.
- Prevent duplicate IDs and invalid relationships that can confuse assistive technology.
- Test menus, tabs, accordions, dialogs, autocomplete, and custom selects against established interaction patterns.
Use automated testing and human review together
Automated tools quickly detect certain missing labels, contrast failures, structural problems, and code issues. They are valuable in development, quality assurance, and continuous integration. W3C is equally clear that tools cannot check every accessibility aspect automatically and that human judgment is required. A perfect scanner score is not a declaration that a website conforms.
- Run an automated scan across representative templates and essential journeys.
- Review findings manually to remove false positives and understand the user impact.
- Complete keyboard-only testing from page entry through submission or purchase.
- Test zoom, reflow, focus visibility, colour independence, motion, and error recovery.
- Use at least one relevant screen reader and browser combination for important workflows.
- Include people with disabilities in usability testing when the scope permits.
- Retest corrected components and run regression checks after every release.
Prioritize fixes by impact, reach, and customer importance
Treat the audit as a remediation backlog, not a long undifferentiated defect list. Fix blockers in essential customer journeys first. Then correct shared components that affect many pages, followed by high-traffic templates and content-level issues. Assign an owner, target date, retest step, and acceptance evidence to every item.
| Priority | Example | Why it comes first |
|---|---|---|
| Critical | Checkout, quote, sign-in, or application cannot be completed by keyboard | The barrier prevents a core service or transaction |
| High | Site navigation, cookie controls, or form errors are inaccessible across templates | A shared component affects many pages and users |
| Medium | Important images, headings, documents, or videos need correction | Content remains available but is difficult or incomplete for some users |
| Ongoing | Editorial standards, component tests, and vendor reviews | Governance prevents the same barriers from returning |
Do not ignore third-party tools and vendors
A business may not control every line of a booking system, chatbot, payment page, map, or recruitment portal, but customers experience the full journey as one service. Ask vendors what accessibility standard and version they test against, request current evidence, document known gaps, confirm remediation commitments, and plan an accessible alternative when a barrier cannot be fixed immediately.
Accessibility requirements belong in procurement and renewal decisions. A generic statement that a product is 'accessible' is weaker than a dated conformance report, tested workflows, identified exceptions, and contract language describing support and remediation.
Prepare evidence before filing the compliance report
The Ontario reporting portal tailors questions to organization category and employee count, and the report must be certified by a person with authority to legally bind the organization. The website team should give that person clear, current evidence rather than a verbal assurance or an old scan.
- A current inventory of public websites, applications, documents, and important third-party services.
- The standard and scope used for each review, including exclusions and known limitations.
- Automated results plus keyboard, screen-reader, zoom, content, and task-based test records.
- A prioritized issue register showing ownership, remediation, retesting, and accepted residual risk.
- Accessibility policies, feedback process, training records, and a multi-year accessibility plan where required.
- Vendor accessibility evidence and documented alternatives for unresolved third-party barriers.
- Final approval records showing who reviewed the evidence supporting each report response.
A practical 30-day website accessibility plan
| Period | Work | Deliverable |
|---|---|---|
| Days 1–5 | Confirm jurisdiction, employee threshold, report owner, domains, applications, documents, and critical journeys | Scope, responsibility matrix, and evidence folder |
| Days 6–12 | Run automated scans and manual keyboard, zoom, form, content, and screen-reader checks | Validated issue register with user impact and affected templates |
| Days 13–22 | Fix blockers and shared components; correct priority content and vendor integrations | Remediation releases with review records |
| Days 23–27 | Retest essential journeys and representative templates | Results showing what passed, what remains, and why |
| Days 28–30 | Review reporting questions, supporting evidence, ownership, and ongoing controls | Management-ready compliance evidence and maintenance plan |
Keep accessibility in the publishing and development workflow
The strongest result is not a site that passes a review once. It is a team that prevents barriers from returning. Add accessible design requirements to the component library, include keyboard and focus behaviour in acceptance criteria, scan pull requests where practical, train content authors, review documents before publishing, and retest critical journeys after platform or vendor changes.
For an Ontario business planning a redesign, accessibility is easier to build into the information architecture, design system, content model, and reusable components from the beginning than to retrofit after launch. It also improves everyday usability for mobile customers, people using temporary or situational accommodations, and anyone trying to complete a task quickly.
The bottom line
The December 31, 2026 reporting deadline should start a structured review, not a rushed checkbox exercise. Confirm which Ontario requirements apply, inventory the complete public experience, combine automated and human testing, fix high-impact barriers, retain evidence, and make accessibility part of normal website ownership.
An accessible website is also a better business interface: more people can find information, understand services, submit forms, and become customers. Canadian organizations can use the same disciplined process even when a particular Ontario reporting threshold does not apply.