AODA Accessible Forms: A Practical Guide for Ontario Organisations

Why forms, and why now

Under the Accessibility for Ontarians with Disabilities Act (AODA), businesses and non-profits in Ontario with 20 or more employees file an accessibility compliance report every three years, and the next one is due December 31, 2026. Organisations with 50 or more employees must also keep their public websites and web content at WCAG 2.0 Level AA. Online forms are where many sites fail: a page of text can be read by anyone, but a form that a screen reader or keyboard user cannot complete locks that person out of a service entirely. This guide is general information, not legal advice; confirm your obligations on the Government of Ontario's AODA pages.

What WCAG 2.0 AA asks of a form

• Every field has a visible label that is programmatically tied to the input, not just placeholder text
• Required fields are announced as required, not signalled by colour or an asterisk alone
• Errors are described in text, identify the field, and suggest how to fix it
• The whole form can be completed with a keyboard, in a logical order, with a visible focus indicator
• Groups of choices (radio buttons, checkboxes) have a group label, and every option has its own label
• Text and controls meet a 4.5:1 contrast ratio against their background
• Content that appears or changes (conditional questions, status messages) is announced to assistive technology
• The page declares its language and has a meaningful title

The five failures we see most

• Placeholder-as-label: the hint disappears as soon as someone types, and screen readers may never read it
• Vague labels such as 'Field 1', 'Other' or 'Enter value' that make sense only next to the visual layout
• Duplicate labels: two fields both called 'Name' or 'Date', impossible to tell apart when read aloud
• Errors shown only in red, or only at the top of the page with no link to the field
• Upload and date widgets built from custom controls that a keyboard cannot reach

A checklist you can run this week

• Inventory every public form: contact, intake, request, registration and application forms
• Tab through each one with the mouse unplugged; note anywhere you get stuck or lose focus
• Turn on a screen reader (NVDA on Windows, VoiceOver on Mac) and complete the form once
• Submit with mistakes on purpose and check that each error is read out and tied to its field
• Run an automated checker such as axe to catch contrast and labelling issues, then fix by hand what it cannot judge
• Record what you tested, what you fixed and when; that record supports your compliance report

Prevent new failures, not just fix old ones

Audits catch problems after they ship. The cheaper approach is to stop inaccessible forms from being published at all. In Rubicon, every form is checked while you build it: missing, vague or duplicate labels, unlabelled options and empty headings are flagged in the builder, and blocking issues stop the form from being published until they are fixed. Published forms render with tied labels, announced required fields and spoken error messages, and we scan the platform's own screens with axe before release.

Practical takeaway

Treat accessibility as a publishing rule, not a yearly clean-up. Fix the forms people depend on first, keep a record of what you checked, and choose tools that will not let a new inaccessible form go live. If you want to see the publish check in action, start a free workspace or book a demo.