The Path to Accessibility: Six AODA Questions to Ask Your Web Developer

(Updated January 2018)
In an effort to simplify the process of making a website accessible, the W3 Consortium (W3C) set out to provide a set of recommendations to make Web content more usable by everyone in its Web Content Accessibility Guidelines.

An accessible site should work with normal browsers and assistive software like screenreaders and talking browsers, which make the Web more accessible for those hard of hearing. There are also keyboard and mouse-replacement solutions that help users overcome physical limitations, allowing people to access websites using hands-free software that tracks use movement with a webcam.

The Ontarians with Disabilities Act (AODA) is a law in force in Ontario, Canada that enforces these standards and makes them regulatory standards. The broader reference is the WCAG or The Web Content Accessibility Guidelines web accessibility guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C).

Specifications for accessibility will often range from WCAG 2.0 (A) to (AAA) with triple-A being the most intensive requirements on the structure and capabilities of websites to accommodate different web view experiences. A good starting point is this summary on Wikipedia.

Without getting into too much of the nitty-gritty technical bits, we’ve put together a few questions to ask your Web developer to will help make your website more compatible with browsers and assistive software so that everyone can access your online content.

1. Are there text alternatives for all non-text content?

Any multimedia on your site should have a text-only substitute. This means that images should have text descriptions have text descriptions, and audio and video should have alternative ways to get the same information such as transcripts. The resulting text can be changed into other forms such as large print, braille, speech, symbols or simpler language.

A great thing to do to boost accessibility is to add closed captioning to videos for the hard of hearing. Aside from making a site’s content more accessible, having the spoken content of a video written out can improve your video’s search visibility, and subtitles can be translated to multiple languages, making your video watchable by more people around the world.

2. Can my site be navigated using just a keyboard?

Because not everyone uses a mouse to browse the Web, all clickable elements and forms should be accessible with only a keyboard. Many keyboard users navigate through links by pressing the “tab” key, and “click” using “enter”.

These users require your page to make it clear what page element is selected or “in focus”. By default, webpages show an outline around the element the user is focused on, but some designers disable this function because they think it makes the page less attractive. Quite the contrary, this is an opportunity to add style, and make it much clearer for keyboard-only users where their focus is.

3. Is my site tagged appropriately?

Writing clearly is not enough to make your site accessible. Certain elements have to be tagged correctly within the underlying code. For instance, there should be a descriptive site title (using the <title> tag), and major headings should be tagged (using the <h1> tag), as well as subheaders (tagged with <h2> to <h6>). Screenreader software often lets users skip between them, simplifying navigation and letting visitors who cannot scroll scan a site.

4. Can users skip repetitive navigation links?

A consistent list of navigation links at the beginning of each page can be helpful, but they can be frustrating for those who are browsing with a keyboard or have software read out loud the links over and over again. To make this less irritating, there should be a way around having to go though them on every page.

A hidden “Skip to Content” or “Skip Navigation” link, for instance, can be included before the site’s main navigation so they can get straight to the page’s content. To ensure these links don’t disrupt the browsing experience of conventional browsers, they can appear invisible to all users until they come into focus when they’re selected using a keyboard or other input device. This criteria is now a requirement in WCAG 2.0 AA and above in AODA accessibility requirements.

5. Is my site laid out and formatted using CSS?

With its advanced capabilities and consistency, Cascading Style Sheets (or CSS) are more powerful than the old layout tables and inline HTML code we used to use to style websites.

While the difference in terms of accessibility between using CSS and tables for layout and formatting is minimal, according to Penn State’s statement on accessibility, CSS’s main advantage is that maintenance is much easier because it usually requires less code to make site-wide changes.

Another downside to using HTML tables for laying out page content is that tables are typically read by screenreader software starting from left to right and top to bottom, which may not be the order you want the page to be read.

If a browser doesn’t support CSS, the content of each page will lose its formatting but still be readable and usable. CSS elements can be placed in a logical order so that the text is coherent when CSS is disabled.

6. Is my text as visible as it can be?

For greater visability, you should ensure that the site has good contrast between the text and background colour. Black text on a white background is usually a safe bet, but the Microsoft Developer Network offers some advice on using the colour wheel to pick high-contrast color combinations. While not always the case, warm and/or dark colors work best for text, and cool and/or light color work best for the background as a rule of thumb.

Various browsers let users enlarge page text, but it’s often up to the designer to make sure that enlarged text doesn’t cause truncated or overlapping elements that ruin the site’s layout and make the text illegible. To avoid this, you can use what’s called “fluid” styling techniques to specify styles in percentages rather than in rigid pixels, and fonts in “ems”, a relative size that’s the font equivalent of percentage.

This guide is meant to help you and your Web developer on the path to creating a more AODA accessible website for everyone. Be sure to test your site with various browsers and assistive technologies, and seek feedback from users. Also, accessibility standards are constantly changing, so it’s important to reevaluate your site from time to time.

At Kobayashi Online, we’re working to expand accessible Web design, and we’re eager to set you up with some of the accessibility practices discussed in this article. Need some help? Give us a shout!