AODA – the Accessibility for Ontarians with Disabilities Act, aims to identify, remove, and prevent barriers for people with disabilities and in terms of websites.
It applies to private or a non-profit organization with more than 50 employees and public sector organizations.
Essentially it states that new public websites, significantly refreshed websites and any web content posted after January 1, 2012, must meet Web Content Accessibility Guidelines (WCAG) 2.0 Level A (https://www.w3.org/WAI/WCAG21/quickref/).
By 2021 the websites must meet WCAG 2.0 Level AA, with a few exceptions.
For the last few years, many of the sites we’ve created for clients have been AODA compliant at launch, however, on revisiting them after some time we have found that they have lost their compliance. Website editors need to be cognizant of AODA, as anytime they make a change to the site they can affect how accessible it is.
Here then is a list of 5 things you can do to keep your website AODA compliant. It’s not a comprehensive list, but it is 5 issues we see popping up often find on websites that prevent them from passing.
Looking for an automated solution to check and maintain your site’s
AODA compliance?
Check out Accessibe,
its what we use.
1. Missing alt tags in images
Alt tags are a place to specify the description of an image, and what they are used for is to describe the image to anybody viewing the website who may be visually impaired, or has images disabled in their web browser (not too common anymore, but back in the early days of the internet plenty of folks would have images off and only turned them on if they wanted to see something).
Alt tags can be added by code, or most systems these days have a handy place to enter them.
2. Header Issues
HTML has a structure, and the structure is used to help describe the page to assistive technologies. The H1 tag is the main headline on the page. Following that there is h2, h3, all the way down to h6, and then bold text and your body copy.
Ideally you shouldn’t jump from h1 to h3, without having an h2 first.
Using bold text as a heading will also cause a site to not pass compliance.
https://www.w3.org/WAI/tutorials/page-structure/headings/
3. Colour Contrast Issues (text colours and backgrounds)
If you’re putting coloured text on top of a coloured background, its important to make sure there is enough contrast between the two colours.
There is a contrast checker at https://webaim.org/resources/contrastchecker/ (and various others out there) where you can put in your two colours and it will tell you if there is sufficient contrast between them to check.
4. Multiple elements with the same ID
ID tags are often used for styling, and they’re also used by assistive technologies reading the page. An ID of a given name should only be used once on a page, lest it confuses things – both the look of the page as well as the accessibility.
Many elements won’t have ids, but we find this issue most often after to an editor has duplicated a content element and then not known, or forgot to change the id.
https://www.w3.org/TR/WCAG20-TECHS/H93.html
5. Broken Links
Links need to do what they say they are going to do, so if a link goes to a page that isn’t working anymore the site won’t pass the accessibility checks. Luckily there are plenty of link checkers out there that you can use to scan your site for broken links.
Contact us if you’d like us to check your site for AODA compliance.
So how can you check if your website is AODA compliant? There are a number of tools out there on the market to scan for AODA and/or WCAG compliance, a google search should turn up plenty. Alternatively we’d be happy to check and fix your site for you if necessary, we’ve done it for many clients.