Establish which website requirements apply
Under Ontario’s Integrated Accessibility Standards Regulation, designated public sector organizations and businesses or non-profits with 50 or more employees must make their public websites and web content posted after January 1, 2012 conform to WCAG 2.0 Level AA, with specified exceptions. That requirement took effect on January 1, 2021. Ontario’s guidance assigns responsibility to the organization controlling the website, directly or through a contractual relationship.
Businesses and non-profits with fewer than 50 employees are not required to follow these particular website accessibility requirements under the regulation, although Ontario encourages them to do so. Keep that distinction narrow: this guide addresses website requirements, not every obligation an organization might have.
Before commissioning work, record your organization type, employee count, public websites and who controls each site. If your structure or employee count makes coverage unclear, have a legal adviser resolve that question. A developer can investigate the website, but should not decide an uncertain legal classification from a contact form.
| Organization | Website requirement described by Ontario | Practical next step |
|---|---|---|
| Designated public sector organization | WCAG 2.0 Level AA for covered public websites and content, subject to exceptions | Define the website and content inventory. |
| Business or non-profit with 50 or more employees | The same website standard applies to covered websites and content. | Confirm control, then commission a scoped review. |
| Business or non-profit with fewer than 50 employees | These IASR website requirements do not apply; following them is encouraged. | Choose an accessibility target for the project. |
Read the exceptions precisely
For the designated public-sector bodies and businesses discussed here, Ontario lists exceptions for intranet or extranet sites and content published before January 1, 2012. The specified exceptions also include live captions and pre-recorded audio descriptions. Ontario Government and Legislative Assembly requirements have a different scope; do not apply this summary to every public body. Confirm uncertain coverage before agreeing the technical review.
Ontario also describes limited circumstances where conformance is not practicable, including websites the organization does not control and cases where no commercial software exists to make the content conform. Do not assume that a purchased theme, embedded booking service or agency-built website automatically falls into an exception. The stated rule includes control through a contractual relationship.
Make a separate list of possible exceptions and the questions requiring advice. Keep technical findings alongside it: what fails, what can be changed and what depends on a supplier. This prevents an unresolved scope question from disappearing inside a general label such as ‘third-party issue’.
Define the review before ordering an audit
Write the target explicitly: WCAG 2.0 Level AA, with the Ontario website exceptions identified separately. In WCAG, Level AA conformance includes the applicable Level A and Level AA success criteria. A contract that just says ‘accessible’ leaves too much room for disagreement about what will be evaluated.
Build an inventory around page types and tasks. Include the homepage, service pages, search, contact forms, landing pages, downloadable documents, media and any purchase or booking flow. Record shared components such as navigation, cookie controls and dialogs. For each item, name the person who can approve changes and the person who can implement them.
W3C’s WCAG Evaluation Methodology describes defining scope, exploring the website, selecting a representative sample, evaluating it and reporting findings. Ask an evaluator to explain the sample and include complete processes. Reviewing a checkout’s opening screen tells you little about the address errors or confirmation step.
Agree on deliverables before work begins. Request reproducible findings, the relevant success criteria, affected pages or components, user impact and suggested repairs. Also request the evaluation limits, including untested documents or supplier systems. Those limits belong in the report, where the next person can find them.
Use this checklist for an initial review
Start with an important visitor task, such as finding a service and submitting an enquiry. Work through it yourself and write down where progress becomes difficult. W3C’s Easy Checks are an introduction to evaluation; passing a short checklist does not establish conformance. Use these checks to gather useful evidence for a fuller review.
| Area | What to try | What to record |
|---|---|---|
| Keyboard navigation | Put the mouse aside. Use Tab and Shift+Tab to move through controls, then operate links, buttons and menus with the keyboard. | Unreachable controls, missing visible focus or places where you cannot move away. |
| Dialogs | Open a dialog, move through its controls, close it and continue the task. | Whether focus enters the dialog, stays within it while open and returns to a sensible place after closing. |
| Headings and structure | Review the heading outline and the labels for navigation regions. | Sections with unclear headings or visual headings that lack heading markup. |
| Forms | Submit an empty form, then enter an invalid value and correct it. | Missing labels, unclear instructions, errors without explanations or an unclear submission result. |
| Text resizing | Increase text size to 200% and repeat the task. | Clipped text, overlapping content or controls that stop working. |
| Text contrast | Measure foreground and background colours with a contrast checker. | The colour pair, text size and measured ratio for each failure. |
| Images | Review each image in its page context. | Missing information in text alternatives or decorative images announced unnecessarily. |
| Recorded video | Watch with sound off and inspect the captions. | Missing speech, speaker identification or meaningful sounds needed to understand the content. |
Turn visual and content findings into specific repairs
For text contrast, WCAG 2.0 Level AA generally requires at least 4.5:1 for ordinary text and 3:1 for large text. Large text means at least 18 point, or 14 point when bold. There are exceptions, including logos and incidental text. Check the actual foreground and background combination; a colour swatch alone cannot tell you whether a paragraph passes. W3C’s Understanding Contrast (Minimum) explains the criterion.
WCAG 2.0’s resize-text criterion calls for text to resize up to 200% without losing content or functionality, except for captions and images of text. Treat overlapping navigation or a clipped submit button as a reproducible issue. Record the browser and the resizing method so the developer can repeat your check.
Use W3C’s Images Tutorial to choose text alternatives by purpose. Describe the information conveyed by an informative image. For an image used as a control, communicate its action. Decorative images should be ignored by assistive technology. A chart may need a fuller explanation than a short image description can provide.
For forms, associate labels with their controls and keep instructions available while someone enters information. W3C’s forms tutorials explain why placeholder text is not a substitute for a label. Give errors in text, explain how to correct them and make the submission result clear. Test the failed submission as carefully as the successful one.
Have someone experienced with screen readers test the important journeys. Review names, roles, reading order and feedback during interaction. For recorded media, check caption accuracy yourself; automatic captions need review. Ontario’s live-caption exception should not be used as a reason to skip evaluating captions on recorded video.
Combine tools with manual testing
Automated evaluation tools are useful for identifying some accessibility problems and checking repeated patterns. W3C states that no tool alone can determine whether a website meets accessibility standards. A clean scan therefore cannot stand in for a complete evaluation.
Ask which checks were automated, which were manual and which assistive technologies were used. An image can have a text alternative that still describes the wrong thing. A form can have labels and still leave someone unable to understand why submission failed. Those questions need human judgement.
Consider involving people with disabilities in task-based testing. Give participants a goal, such as finding an eligibility detail or sending an enquiry, and observe where the interface gets in the way. Use the findings alongside the technical evaluation. Keep the distinction clear between a tested task, an evaluated sample and a claim about the whole website.
Prioritise repairs and make the handoff usable
Organise the repair queue by what prevents people from completing tasks, then by how widely a defect occurs. A broken shared menu deserves attention across the site. An inaccessible form deserves attention through its complete submission flow. This is a practical sequencing method, not permission to leave other applicable criteria unresolved.
Give each issue a clear owner and a retest condition. ‘Improve accessibility’ is difficult to close. ‘The enquiry form announces the missing email field, explains the error and allows correction with the keyboard’ gives the implementer and reviewer something concrete to test.
For supplier-controlled components, send the supplier a short reproduction and ask what changes are available. Keep that dependency visible in your plan. After repairs, repeat the original checks and test related states. A menu fix can affect both desktop and mobile navigation; a form change can affect both error and success messages.
- Keep the evaluated page or component, browser, assistive technology and reproduction steps with each finding.
- Record the expected behaviour, actual behaviour and relevant success criterion.
- Assign implementation and verification separately where practical.
- Store retest evidence and unresolved limitations with the final handoff.
Keep accessibility in the publishing workflow
Set a lightweight review routine for new content and interface changes. Give editors guidance on headings, descriptive link text, image alternatives and media. Give developers repeatable checks for shared components. Put an owner against downloadable documents instead of letting them fall between the content and development teams.
When commissioning a redesign, ask for accessibility checks during design, implementation and final review. Before replacing a booking tool or adding a promotional dialog, include the affected visitor task in acceptance testing. Keep a record of what changed and what was checked.
Start by choosing a task, running the initial checklist and turning the findings into tickets. Then commission a fuller evaluation with a written scope. You will have a clearer brief, more useful evidence and fewer vague conversations about whether the site ‘looks accessible’.
How hehe.software can help
hehe.software is a small, independent web and app studio based in Vancouver, British Columbia, working remotely with businesses across Canada and the United States. We help implement the technical side of accessibility through website fixes, UI/UX changes and maintenance; we do not certify legal compliance. We also take fix-it jobs on websites we did not build and sub-projects for agencies. Email mwe@hehe.software or use the contact form with your website, any existing findings and the tasks visitors need to complete. We scope the work and provide a fixed quote or an hourly estimate.