Web Accessibility: Make Your Company Socially Responsible

This is a guest post by Maria C Lima and first published on mclinteractive.com

Website Accessibility

July 25, 2012. “About 56.7 million people — 19 percent of the population — had a disability in 2010, according to a broad definition of disability, with more than half of them reporting the disability was severe, according to a comprehensive report on this population released today by the U.S. Census Bureau”.

I have been reading materials, watching tutorials, writing accessibility code, and learned that it should be part of our strategy to make our website compliant with accessibility to allow people with disabilities to use the site.  This approach will not only help enormously people with disabilities, but also maximize the number of people using our website and promote our company as socially responsible.

Website Accessibility Considerations

If you would like to make your website accessible to all individuals, you should make the necessary adjustments to your website taking in consideration the following key items although you should consult the WCAG 2.0 Checklists for a complete set of guidelines:

1. Color Management. People with low vision have difficulty in differentiating colors. So color contrast will help them, or I should actually say will help everybody to better read and understand a web page. There are tools that analyze your web page and search for color contrast issues among others. As an example, search the Chrome Web Store for automated tools such as Wave or aXe.
2. Web Page Structure. Each web page should identify the language being used, and have a title and headings descending in size. Content should be structured to include header, navigation, main, and footer sections.
3. HTML Semantics. The inclusion of HTML5 in our code makes accessibility compliance much easier, as HTML5 includes tags, such as <header>, <nav>, <label>, <footer>, etc. which are self-explanatory. This approach reduces the use of Aria attributes, which prevents us from writing additional code. Nevertheless, there will be circumstances where we need to use Aria – please retrieve the latter link for more information.
4. Link Management. The links’ text must be clear and informative. You should avoid using key phrases, such as “Click Here”.
5. Text Alternatives. Elements such as images, which cannot be seen by visually impaired people, should include a text attribute – which is called ‘alt’ and describes the image – as an alternative to the image. You should also include a text alternative to video and audio.
6. Keyboard Operability. People motor impaired cannot use the mouse. Consequently, it is necessary to provide functionality via a keyboard, so the user can use the ‘tab’ key to navigate through your website.
   • Focus Management. We need to programmatically give focus to certain elements, so we can browse the website with the keyboard. As an instance, if a dialog box pops up, the user should be able to close it by pressing the ‘Enter’ key. In order to press the ‘Enter’ key, it is necessary to programmatically give focus to the ‘OK/Close’ button.

Website Accessibility Testing

In order to make your website accessible, it is important to invest time testing it. Hiring a person/consultant with disabilities to test your website should be a part of your company’s strategy.

Usually, I take the following steps to test a website:

1. Keyboard Functionality. I first test the web pages using the keyboard to make sure the elements are tabbed on a sequential order.
2. Testing on Screen Readers. Afterwards, I test the web pages on Voice Over, which is a screen reader for MAC computers. However, there are also screen readers for windows computers – please retrieve the latter link for more information.
3. Automated Testing: TENON / Wave / Axe. I then perform automated testing. I use tools such as TENON. The thought of making a website accessible made me always very anxious until the moment I first used TENON. The use of this tool simplifies the process because it does most of the work for us. This tool scans the pages, and provides a list of errors/warnings and suggests fixes. In addition, I use Wave and aXe. The Wave Chrome extension scans the web page and provides a detailed report on accessible elements and errors. aXe provides an analysis report.
4. Manual Testing. After the automated tests, I perform a manual test. I carefully look at the code page by page to add any other accessible markup, paying special attention to the following:
   • Page Structure and HTML5 Semantics
   • Buttons, Links, and Alternative Text
   • Focus Handling

   Usually, I need to add Aria attributes to the markup of certain modular widgets, such as dialog boxes, dropdowns, etc. This requires writing some JavaScript.

If you have any questions, please contact me at maria@mclinteractive.com. I’ll be more than glad to help you clarify any issue you might have or work with you to make your website accessible.