Start or fix 

Ontario SMEs: 12 Website Accessibility Fixes Before Dec 31, 2026

CloudSprout team · October 2026 · 11 min read

If your Ontario organization is a designated public sector body or a private or nonprofit organization with 50 or more employees, your public website must meet AODA web rules: WCAG 2.0 Level AA, with two narrow exceptions. Your immediate next step is an accessibility audit or a start on the compliance report checklist, not a wait and see approach. Organizations that delay often discover the fixes needed are small, but the documentation gap is what gets flagged.

TL;DR:

  • Most organizations need to prioritize fixing heading structures, alt text, form labels, colour contrast, and keyboard navigation to meet WCAG 2.0 AA standards.
  • An accessibility audit should be conducted immediately to identify high-impact issues and document remediation efforts, rather than delaying action.
  • Web content published since January 1, 2012 must meet WCAG 2.0 AA, and organizations with 20 or more employees must file a compliance report by December 31, 2026.
  • Contracted third-party vendors do not absolve organizations from responsibility for accessibility compliance; control over content and user experience matters.
  • For content that cannot be fully accessible, providing an alternative format upon request remains a legal obligation.

Table of Contents

Who Must Comply and What the Law Requires

The Accessibility for Ontarians with Disabilities Act (AODA) sets accessibility obligations for organizations operating in Ontario, and the Integrated Accessibility Standards Regulation (IASR), O. Reg. 191/11, spells out exactly what “accessible” means for websites. Public sector organizations, and private or nonprofit organizations above certain size thresholds, fall under these rules. The regulation does not treat every business the same way: a five-person landscaping company and a 200-employee manufacturer sit in different compliance tiers.

Section 14 of the IASR requires designated public sector organizations and private or nonprofit organizations with 50 or more employees to make public websites and web content posted after January 1, 2012 conform to WCAG 2.0 Level AA, the technical standard built by the W3C. There are two named exceptions written into the regulation itself:

  • Success criterion 1.2.4, live captions, is not mandatory.
  • Success criterion 1.2.5, pre-recorded audio descriptions, is not mandatory.

Everything else in WCAG 2.0 AA applies: colour contrast ratios, keyboard operability, text alternatives for images, consistent navigation, readable form labels, and dozens of smaller rules that together make a site usable by someone with low vision, a motor impairment, or a screen reader.

Timelines matter here. The rule covers web content published on or after January 1, 2012; older content does not have to conform, although anything you update or republish counts as new content. Reporting cycles run on a separate clock from the technical deadline. Businesses and nonprofits with 20 or more employees must file an accessibility compliance report, and the portal lists a reporting deadline of December 31, 2026 for the next cycle.

Control matters too. If your organization contracts out web development or hosts a third-party booking widget, the obligation does not disappear. You are expected to build accessibility requirements into procurement and vendor contracts, because the law looks at who controls the content and the user experience, not who coded it. A restaurant using a third-party online ordering plugin is still responsible for making sure that plugin does not lock out a customer using a screen reader.

Who Must Comply and What the Law Requires — overview diagram

Your Website Accessibility Checklist: What to Fix First

Most Ontario organizations do not need a full rebuild to close their biggest accessibility gaps. They need a prioritized list and someone willing to work through it. Add accessibility checks to our website maintenance checklist so fixes do not slip.

  1. Headings and structure. Confirm every page uses one H1 and a logical H2/H3 order, not styled text pretending to be a heading.
  2. Alt text. Add descriptive alt text to every meaningful image; mark decorative images so screen readers skip them.
  3. Form labels. Make sure every input field has a programmatic label, not just placeholder text that disappears on click.
  4. Colour contrast. Check text against its background meets WCAG AA contrast ratios, especially on buttons and low-contrast grey-on-white designs.
  5. Link text. Replace vague links like “click here” with text that describes the destination on its own.
  6. Keyboard navigation. Tab through the entire site without a mouse and confirm every link, button, and form field is reachable in a logical order.
  7. Focus indicators. Make sure the browser’s focus outline is visible, not stripped out by a CSS reset.
  8. Media captions and transcripts. Add captions to video and transcripts to audio content, prioritizing anything tied to services or instructions.
  9. Accessible PDFs. Tag PDFs with proper heading structure and reading order, or convert high-traffic documents to HTML pages instead.
  10. Legacy content. Audit old blog posts, menus, and brochures for accessibility gaps and set a realistic remediation timeline rather than trying to fix everything at once.
  11. Skip links and language attributes. Add a “skip to main content” link and set the HTML lang attribute correctly for English or French pages.
  12. Semantic HTML and ARIA. Use native HTML elements (button, nav, table) before reaching for ARIA attributes, which should patch gaps, not replace proper markup.

Pro Tip: Keep a simple remediation log with columns for the WCAG success criterion, who owns the fix, estimated effort, date resolved, and a before and after screenshot. That log becomes your evidence if the Ministry ever asks for proof.

Record-keeping is not optional paperwork. An issue tracker that captures the specific criterion, severity, and resolution date turns a vague “we’re working on accessibility” into a documented program, which is exactly what reviewers and auditors want to see.

How to Actually Test If Your Website Is Accessible

Testing accessibility well means layering four different methods, because no single one catches everything.

Start with an automated scan using a tool like WAVE, axe, or Lighthouse’s accessibility audit. These catch missing alt text, contrast failures, and empty form labels in minutes. Automated checkers are a useful first pass but cannot verify many WCAG requirements on their own, since they cannot judge whether a page reads logically or whether alt text actually describes the image.

From there, move to manual checks:

  • Navigate the entire site using only the keyboard, tabbing through menus, forms, and modals.
  • Zoom the browser to 200% and confirm text does not overlap or get cut off.
  • Read the page source order out loud and compare it to the visual order; mismatches confuse screen reader users.
  • Submit every form with missing or incorrect data and confirm error messages are clear and announced.

Next, test with assistive technology directly. Run the homepage and one key conversion page (a booking form or contact page) through NVDA on Windows or VoiceOver on Mac, using basic navigation commands like heading jumps and link lists. Check the mobile experience separately, since touch gestures and screen magnification behave differently than desktop screen readers.

Finally, plan a small round of user testing with people with disabilities, not just staff pretending to be users. A fair approach includes real recruitment and paid participation rather than relying on a single internal volunteer.

Pro Tip: Script at least six realistic tasks, like finding a service page, completing a contact form, or downloading a document, and measure both task success and the participant’s own feedback.

Organize every defect you find by severity: blocking (a user cannot complete a task at all), serious (the task is possible but confusing or slow), and minor (cosmetic or low-impact). Attach a screenshot and the exact steps to reproduce each issue so whoever fixes it does not have to guess.

When You Can’t Make Something Fully Accessible

Some content genuinely resists full accessibility. A complex architectural diagram, an interactive map, or a scanned historical document may not translate cleanly into WCAG-compliant markup no matter how much time you spend on it.

When content truly cannot be made accessible, the law still expects you to provide the same information in an alternative accessible format on request, such as a plain-text description, a phone-based explanation, or a reformatted document. This is not a loophole, it is a documented obligation.

A clear alternative-format response should include:

  • A direct acknowledgment of the request and expected turnaround time.
  • The information delivered in a format the requester can actually use (large print, plain text, audio description over the phone).
  • Contact information for follow-up if the alternative still falls short.

For procurement, build accessibility clauses into contracts before work starts rather than after a vendor delivers something inaccessible. Require WCAG 2.0 AA conformance in writing, ask for a sample of prior accessible work, and reserve the right to request fixes at no extra cost if the delivered site fails basic testing.

Short-term remediation often beats a full rebuild: swapping a broken PDF for an HTML page, or adding a text alternative to an interactive chart, can close a gap in days rather than months.

Documenting Your Compliance: Statements, Plans and Filing Reports

Three documents carry most of the weight here: an accessibility statement, a multi-year plan, and the compliance report itself. Keep compliance documents together, including privacy policy requirements in Canada.

  1. Publish an accessibility statement. State your commitment to WCAG 2.0 AA, list any known limitations, and give a contact method for feedback. Put it in the website footer so it is reachable from every page.
  2. Write a multi-year plan. Cover scope (which sites and systems), concrete goals, realistic timelines, and the name of the person accountable for progress. Review and update it on a regular cycle, not once and forgotten.
  3. File through the Accessibility Compliance Reporting Portal. Businesses and nonprofits with 20 or more employees must submit a compliance report by the stated deadline, currently December 31, 2026 for the next cycle. A senior officer typically certifies the report before submission.
  4. Keep your records audit-ready. The Ministry’s Compliance Assurance Branch audits organizations and enforces requirements where non-compliance persists, so retain your remediation log, test results, and prior statements for at least a few reporting cycles.

The 2023 Legislative Review of the AODA frames the law as a floor, not a ceiling, and recommends organizations treat accessibility as an ongoing strategy rather than a once-off checklist. Auditors tend to look less for perfection and more for evidence that your organization actually has a working process.

How CloudSprout Helps Ontario Organizations Meet AODA Rules

Closing accessibility gaps touches code, content, and documentation at the same time, which is why many Ontario organizations hand the technical side to a team that handles it daily. We run website development projects, remediation work, and ongoing maintenance entirely in-house, with no outsourcing, so the same people who audit a site are the ones fixing it.

Our free digital presence audit reviews a site’s structure, markup, and content against WCAG 2.0 AA criteria, flags the highest-impact fixes first, and hands back a plain-language list your team can act on immediately. For organizations without a developer on staff, a short-term agency engagement often closes a compliance gap faster than trying to train someone internally from scratch. For organizations that already have technical staff, the audit itself can still be worth running, since outside eyes tend to catch issues an internal team has stopped noticing.

Once fixes are scoped, remediation can run alongside a broader rebuild or as a focused patch to an existing site, with reporting support available for the documentation side too.

Why Accessibility Is Risk Management, Not Just Compliance

Most Ontario business owners treat AODA as a legal chore to survive, not a decision that affects revenue. That framing misses the point. A site that fails keyboard navigation or buries its contact form behind unlabeled fields loses customers who never file a complaint, they just leave.

Accessibility work and conversion work overlap more than people expect: clearer link text, better contrast, and simpler forms tend to help every visitor, not just the ones using assistive technology. The practical move is to fix what blocks a transaction first (the booking form, the quote request, the menu) before polishing lower-traffic pages.

Treat the compliance report deadline as a forcing function, not the whole goal. Schedule an audit this quarter, not after the next complaint or inspection letter arrives.

— Cristo

Get Your Site Audited Before the Next Reporting Deadline

We handle accessibility remediation the same way we handle everything else: in-house, with no long-term contract locking you in and no outsourced developer disappearing halfway through a fix. Every engagement starts with a free full digital audit, so you know exactly what needs attention before you spend a dollar.

CloudSprout

  • A free audit reviewing your site’s WCAG 2.0 AA gaps, structure, and content.
  • Website builds and remediation done by our own in-house team.
  • Transparent month-to-month pricing through our Sprout, Grow, and Scale plans, with no lock-in contract.

Start with our free audit and get a clear, prioritized list of what your site needs.

FAQ

Does my small business in Ontario need to follow AODA website rules?

It depends on your organization’s size and type. Public sector bodies have obligations regardless of size, while private and nonprofit organizations must meet the website requirement once they have 50 or more employees, and businesses and nonprofits with 20 or more employees must also file a compliance report.

What is WCAG 2.0 Level AA and why does it matter in Ontario?

WCAG 2.0 Level AA is the technical accessibility standard that the IASR requires for public websites and web content, covering things like colour contrast, keyboard access, and text alternatives for images. Ontario’s regulation names two exceptions: live captions and pre-recorded audio descriptions are not mandatory.

When is the next Ontario accessibility compliance report due?

Businesses and nonprofits with 20 or more employees must file their accessibility compliance report by December 31, 2026 for the next reporting cycle. The report is submitted through the province’s online portal and typically requires certification by a senior officer.

What happens if my website content can’t be made fully accessible?

The organization is still expected to provide the same information through an accessible alternative format on request, such as a plain-text version or a verbal explanation by phone. This applies to content like complex diagrams or legacy documents that resist full WCAG conformance.

How much does it cost to fix website accessibility issues in Ontario?

Costs vary widely depending on how many pages and systems need remediation versus a full rebuild. We offer a free digital audit to scope the work first, with ongoing services priced through our Sprout, Grow, and Scale plans starting at 300 CAD per month.

Sources

Want a hand?

Tell us what is going on