Building Accessible Websites From Day One: How We Approach AODA

By LaunchLen Web Solutions Team

Accessibility can be easier to build in than to bolt on. When it’s part of the plan from the first sketch, colour choices, headings, forms and content can all line up with it. When it’s left until the end, fixes can mean reworking templates and rewriting pages.

This post explains how LaunchLen Web Solutions Inc. approaches AODA website compliance with you: what Ontario’s rules say, how accessibility can fit into design, development and testing, and how to keep content accessible after launch. It isn’t legal advice. Please confirm your own obligations with the official source.

What AODA website compliance asks of business websites

Ontario’s guidance on how to make websites accessible sets out who must comply. In its words: “As of January 1, 2021, the AODA requires you to make all public websites accessible if you are either: a designated public sector organization or a business or non-profit organization with 50 or more employees.”

On the standard itself, the same page says your “public website and web content posted after January 1, 2012, must meet the WCAG 2.0 Level AA success criteria”, except for live captions and pre-recorded audio descriptions. It also notes that the organization that controls the website, “either directly or through a contractual relationship”, must meet the requirements.

WCAG is the Web Content Accessibility Guidelines from the World Wide Web Consortium (W3C). WCAG 2.0 is built on four principles: content should be perceivable, operable, understandable and robust. Under each guideline, success criteria describe what must be achieved at each level.

What AODA website compliance means for you depends on your organization, so check the ontario.ca page and the regulation it refers to before deciding what applies to you. Even if the rules don’t apply to you, an accessible site can be easier for everyone to use.

Accessibility in design: colour, type, layout

Accessible design starts before any code. Choices in this stage can include:

• Colour and contrast. WCAG says colour should not be “the only visual means of conveying information”, so an error message needs more than red text, and text needs enough contrast against its background.
• Type. Readable sizes and spacing, and text that can be resized without breaking the layout.
• Layout. A clear, consistent structure, with navigation in the same place on every page and headings that describe what follows.
• Images of text. Real text instead of text baked into images, so it can be read aloud and resized.

As an illustrative example, a service business might want a pale grey font on a white banner because it looks clean. In the design stage, we can show a higher-contrast version that keeps the look and is easier to read, before anything is built.

Accessibility in development: semantics, keyboard, forms

Development is where accessible design becomes something assistive technology can use. Work at this stage can include:

• Semantic structure. One main heading per page, headings in a logical order, and real lists, buttons and links. WCAG asks that “information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.”
• Keyboard access. WCAG requires that all functionality is “operable through a keyboard interface”, with no keyboard traps and a visible focus indicator so people can see where they are.
• Forms. Every field has a label, errors are identified and described in text, and suggestions are given where corrections are known.
• Text alternatives. Images that carry meaning get alt text; decorative images are marked so screen readers skip them.
• Components. Menus, tabs and pop-ups expose their name, role and state to assistive technology.

Our web and app development service page says we build with accessibility in mind and can work toward WCAG 2.0 Level AA. The same thinking applies to web apps and to native mobile apps, where each platform’s own accessibility features matter too.

Testing: automated checks plus manual review

Testing needs both machines and people. The W3C’s guidance on evaluation tools is clear that tools help but can’t do it all: “Tools cannot check all accessibility aspects automatically. Human judgement is required.” It adds that evaluation tools “can not determine accessibility, they can only assist in doing so.”

Ontario’s guidance describes a similar mix. Its testing tips include an automatic assessment, review with assistive technology such as a screen reader, and, if possible, asking people with disabilities to test your website before launch. It also suggests keeping a record of the accessibility issues that have been resolved.

A website accessibility audit with us can include:

• automated scans to flag likely issues across key templates
• keyboard-only checks of navigation, menus and forms
• screen reader checks of important pages and tasks
• a manual review of colour, headings, link text and alt text
• a written list of issues found and fixed, so you have a record

The service page recommends an accessibility review before launch if you’re legally required to comply. We can agree the scope, deliverables and reporting with you, including which pages and tasks are tested.

Keeping content accessible after launch

Accessibility doesn’t end at launch. New pages, images, documents and videos can add barriers if the people publishing them don’t know what to look for. Ontario’s tips for working with developers suggest a plan for how the site will be maintained, which could include training staff on how to create accessible content.

Support after launch can include:

• Content guidance: a short, plain-language guide for your team on headings, link text, alt text and colour
• Templates: page layouts and components that help keep structure accessible
• Media and documents: checking captions on new videos and accessibility of uploaded documents
• Spot checks: reviewing new or changed pages against the same checks used before launch

If your site adds AI features later, such as an assistant or smarter forms, the same accessibility checks can apply to those components. Our post on AI-powered web development covers how those features fit into a site.

FAQ

Does AODA apply to my business website?

Ontario’s guidance says the AODA requires you to make all public websites accessible if you are “a designated public sector organization or a business or non-profit organization with 50 or more employees.” Confirm your obligations with the official ontario.ca guidance and regulation, or with a qualified legal professional.

What standard do Ontario websites need to meet?

Ontario’s guidance says your “public website and web content posted after January 1, 2012, must meet the WCAG 2.0 Level AA success criteria”, except for live captions and pre-recorded audio descriptions. Check the ontario.ca page for the current wording.

Is an automated accessibility checker enough?

No. The W3C says tools cannot check all accessibility aspects automatically and that human judgement is required. Automated scans are a useful start, but keyboard, screen reader and manual review are needed too.

Working with LaunchLen

Based in Kitchener, serving Waterloo Region and businesses across Ontario.

If you’re planning a new website or app and want accessibility built in from day one, tell us what you’re building and who needs to use it. This post isn’t legal advice, so please confirm your obligations with the official source.

Book a free consultation