How to Review Your Website to Meet Ontario’s Accessibility Laws (AODA)

As of January 2014, Ontario companies and organizations with more than 49 employees are required to make their website accessible to meet Ontario's multi-phase accessibility laws. Even if your company is smaller than 49, an accessible website can be good for business as one in seven Ontarians has a disability. So how do you know if your site is accessible?

Determining if your site is accessible can be challenging and implementing changes to make it accessible may be even more difficult. You may need the help of someone with knowledge in web accessibility and technology. 

From a high level, here are some things to look at when doing an accessibility audit of your website:

Test Your Site with a Screen Reader

Many people with visual impairments use a screen reader and keyboard to navigate the Internet. As you might imagine, the screen reader audibly reads the content found on the screen aloud. The way in which your site is programmed and content is created can help screen reading software better navigate and read it. 

If you use Google's Chrome web browser, you can install a free plugin called ChromeVox to experience what it's like to use your site with screen reading software. 

Try installing ChromeVox and visit your website. You'll probably be surprised at how difficult it is to navigate. Now try the same exercise with your eyes closed. 

Try Browsing with a Keyboard

Have you ever tried navigating a website without a mouse or touch screen? Non-sighted and people with other disabilities have to do this all the time. 
Without keyboard accessibility some content displayed on the screen may be impossible to access. A few key items to look at include:

• Visual cues need to be in place to show what has focus or is being interacted with. An example of this is the visual cue we get when mousing over a link. A keyboard user tabbing through the page will find it helpful to know where they are on the page. 

In the example above, the second upcoming event listed has a keyboard focus style that identifies where the user is on the page.

• For any interactions that rely upon JavaScript (mouse overs, clicks) you may need additional code to trigger on-key press events. These are often forgotten.
• Interactive components or widgets may need additional programming to make them work. A tab panel for instance will require programming to allow the user to navigate through the tabs, into the tab panel content and back out again. 

In the example above, a keyboard user can navigate to the tab panel using their tab key, switch between tabs with their arrow key and navigate into the current tab with the return button allowing them to access all content.

Check for Skip to Content Links

A screen reader will read everything on the screen including navigation. Imagine clicking through a site and having all of the navigation links read to you over and over on every page before getting to the content, you might also have to tab through them using your keyboard.

• Skip to content links can be hidden to sighted users but available for screen readers allowing people to skip right to the content.
• You can look for skip to content links on your existing site using a screen reader or by peeking at the source code (if you know what you're looking for) such as:

Review Primary Navigation

• Navigation should be keyboard accessible and include visual cues for active focus items.
• All users should be able to access all content on your site. A user that cannot access a drop down may not be able to get to all content. If it's not possible to provide access to the items in a drop down directly, an alternative is to make sure that the very top menu item (that everyone can access) goes to a page that includes the links that are in the drop down for that section. 

Add Context for Images

Non-sighted users should get an audio description of non-decorative visual content. This means that any logo, supporting image, diagram or infographic should have a text description. This can be accomplished in a two ways: 

1. An alt tag can be applied to images. This will describe the image to non-sighted users and search engines. 
2. Alternatively a text description can appear directly below the image with the alt tag marked in empty quotes "". The second approach is good when you plan to describe the image to sighted and non-sighted users as it prevents a screen reader from reading the exact same text twice. For the technically inclined, there are special figure and caption tags for this purpose. 

Make Audio & Video Accessible

• For users with a hearing impairment audio and videos can be inaccessible. Providing a transcript of any spoken content is a good way to provide accessibility and comes with the added benefit of helping search engines better understand the content as well. 
• Additionally the interface for playing an audio or video file must be keyboard accessible as well. 

Provide Enough Contrast for Visual Elements and Content

Users with low vision or colour blindness may not be able to see subtle shades of colour used in your design. In some cases this can make text content hard to read or invisible all together. Colour contrast tools found in Photoshop or freely available tools like Paciello Group's colour contrast analyzer can be used to check for issues. 

Some general tips:

• Make text large enough to read. 16px is a good minimum. This may seem large, but on modern high resolution monitors it's usually a good size. 
• Links and headings need to use a colour that has strong contrast otherwise they may be hard to distinguish from the text around them. If a suitable colour can't be found then ensuring the link has an underline is a good alternative. 

Use Tables Sparingly

Tables can be tricky. Just imagine someone reading the content of a spreadsheet out loud. First they'd read the columns across the top, then go to the next row and read the columns of data. That would be difficult to understand to say the least!  An important rule: tables should only be used for data. 

When used properly, tables should include header tags and captions that describe the content or purpose of the table. These tags also allow screen readers to better understand how the table should be read.   

In the past tables have been used to achieve layout, this is considered bad practice as the content will be read in order, making it difficult to understand. You may still be using tables in your CMS to achieve a desired layout. Stop unless you’re displaying tabular data!

Review PDF, Word Documents and More

PDF and Word documents are often used on company websites as an easy way to add new content. You may not realize that they have their own accessibility requirements.  PDF accessibility is outside of the focus of this article, but please be aware that any content shared on your website should be accessible. For more information take a look at these links:
http://www.pdf-accessibility.com/accessibility-document-pdf-accessible/
http://www.adobe.com/enterprise/accessibility/pdfs/acro6_pg_ue.pdf
http://www.adobe.com/content/dam/Adobe/en/accessibility/products/acrobat/pdfs/acrobat-x-accessibility-checker.pdf

Make Forms Useable

Filling out a long form is a chore for most people that can be even more difficult for people with disabilities. These suggestions may make your form easier to use:

• Provide proper instructions for the form and any fields that may be challenging.  Why are you collecting the information? What's it for? What are you expecting? Provide examples. Imagine trying to fill out the form with your eyes closed. What additional instructions or tips might make that experience better? Are required fields marked?
• Ensure that forms are programmed with labels and that each label tag is linked to its corresponding field. Labels provide context for fields and allow you to group instructions with the field. 
• Avoid using tables to layout forms. As mentioned above, tables are read in order by screen readers. This may mean that a user is read a row of form labels before arriving at the first field they need to fill out. They then have no idea what they're supposed to enter in the field.
• Make sure the form can be navigated and submitted using the keyboard alone. It's possible to use JavaScript to enhance a form but forget to test to make sure those enhancements are usable with a keyboard.  

In the example above, green labels are programmatically linked with the field below and those fields are positioned without the use of tables. Instructions are provided at the top of the form and placeholder text is present giving an example of the expected content for each field. /p>

Review Interactive Components

We've all seen cool effects, widget and components like slide shows, sliders, light box windows and drag and drop features. These can add a bit of flair and interactivity, but do need special consideration. The programmer that developed a popular new plugin might be happy just getting it working without much thought of accessibility. You may need to add accessibility to the plug-in yourself. 

Is the content inside the component accessible? Components can be complex which makes accessibility challenging. Technology called ARIA or Accessible Rich Internet Components provide a way for accessibility to be added to these components. 

Does the component make the rest of the page inaccessible? For example in the case of a slide show does the component automatically play, changing content on screen for a couple seconds before switching that content out for something else? That flash of content may take a screen reader focus away from other content so the user may not be able to access the area they want to read (or even navigate). 

Semantic Markup

You may not realize it, but the way that your site is programmed can add meaning and structure to the document. Using the correct tags helps assistive technology and search engines better understand what each part of a page represents.

From a structural level, the markup or tags that outline the document help separate primary content from other elements like headers, footers, navigation and supportive content.

At the content level, there are tags to denote the hierarchy from headings, to bold, emphasis, lists, tables, links and images.

To enhance accessibility some of these tags can be marked with ARIA roles to give assistive technologies more information to work with. 

You may need to talk to a web developer to determine if your website is programmed semantically.

An Accessible Site Starts with a Plan

Although accessibility may seem like extra work and possibly a hassle, it's important to keep in mind that it's not only the right thing to do, but it's also good for business. 

Start by doing an audit of your entire site to determine the changes needed. Those changes could be as little as a day of work or in the case of a large site a multi-month project. Put a plan in place to complete the necessary changes and keep in mind that achieving accessibility on your site as it stands now is not the finish line. All new content going forward should be accessible as well, so establishing an internal process to ensure all content creation is compliant is a good idea.

Need help with a website audit or making your website accessible? Let’s talk.