Apps

A checklist for web accessibility issues

In addition to designing for all kinds of devices with varying screen sizes, developers also aim for accessibility for all users. Here is a checklist to help you rate your website and apps.

As the catalog of Internet-connected gadgets and appliances continues to grow, content owners, stakeholders, and web developers alike are attempting to keep pace by offering the same user experience across all browsers and screens. Web accessibility issues remain only vaguely recognized as we continue to adjust to the ever changing landscape of devices.

In a previous post I touched on optimizing your PDF's for your website with an eye toward making them more accessible to all visitors. However, in this post I will touch on more ways that you can break down the barriers and bring better accessibility to your websites. I'll give you a list of accepted standards along with a checklist for testing your web pages against commonly known accessibility issues, and finally, further resources for you to explore.

Accessibility is one of the cornerstones of the web, as Tim Berners-Lee, Director of the W3C and inventor of the World Wide Web has stated: "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." With accessibility equally one of the WWW foundations, why do so many websites fail to pass accessibility standards today? Ignorance maybe, or is it a conscious decision that stakeholders make to exclude accessibility from their technical expressions? In either case, websites that fail accessibility checklists also fail to capture every opportunity that exists on the screens of those with disabilities. And while it is required of Federal agencies, most in the private sector have waved off the majority of web accessibility standards because they are not required, and it becomes a pure voluntary action for those who understand its importance.

Section 508 technical standards

The Rehabilitation Act of 1973 was amended (29 U.S.C. 794d) along with the implementation of Section 508 which requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, that Federal employees and the public with disabilities have access to and use of information and data that is comparable to those who do not have disabilities, unless an undue burden would be imposed by the particular agency. The Section 508 Standards are the technical requirements and criteria that are used to measure conformance within this law. If you want to find more detailed information about the Section 508 technical standards, they can be found at Section508.gov. While the Section 508 technical standards are not a requirement of civilian organizations, it serves as a foundation for those seeking a proven list of best practices when it comes to providing access guidelines for web technologies.

Web-based Intranet and Internet Information and Applications (1194.22)

Section 508 Standards can be summarized into four subparts, General (Subpart A), Technical (Subpart B), Functional Performance Criteria (Subpart C), and Information, Documentation, and Support (Subpart D). The portion that relates to web development is the Web-based Intranet and Internet Information and Applications (1194.22) section, which is part of Technical (Subpart B). Here is a summary:

  • It is based on guidelines developed by the W3C's Web Accessibility Initiative.
  • Provisions ensure access for people with vision impairments who rely on assistive technologies and products to access computer-based information
  • Standards ensure that non-textual content such as graphics and animations provide alternative text labels or descriptors for these elements.
  • Addresses the usability of multimedia presentations, image maps, style sheets, scripting languages, applets and plug-ins, and electronic forms.
  • The standards apply to Federal web sites but are not required for the private sector unless a web site is provided under contract to a Federal agency.
  • Web sites must offer a significant advantage that goes beyond access, such as providing a text only option for faster downloading and to facilitate the transmission of data across all devices and digital assistants.

While the 508 Standards are not required of civilian and private entities, the standard does provide a guideline that can be applied universally across all forms of technology, public or private.

Web accessibility checklist

Next, I would like to share with you a checklist that helps to test and identify some of the most commonly occurring accessibility issues for website and web-based applications. Every web page or web application is different and you may or may not need to address every item on this checklist; however, it can be utilized throughout the life-cycle for any web-based project. It is a tool that can be used to help during the project planning stages, to test for accessibility compliance of existing projects, and finally as a tool to communicate with project stakeholders about the importance of accessibility within your organization.

The checklist should also include the specific URL of the web page under review, along with the documented date, name of the reviewer, and any testing protocols that are used, such as browsers, software, or devices. Each question should be used in the review process, and can be marked with either of three typical responses, "Yes", "No", or "Not Applicable" depending on the subject and the results of the testing.

  1. Does the keyboard provide access to navigation, in particular the tab, arrow, and enter keys without the use of a mouse?
  2. Using the keyboard for navigation, does the cursor move in a logical flow or order?
  3. Do all elements (links, radio buttons, text boxes, and drop down menus) work when selected?
  4. Does the link text explain and provide context?
  5. Is ALT text provided for all non-text elements?
  6. Are captions provided for multimedia elements?
  7. Is the web page organized such that it is readable without the use of an associated stylesheet?
  8. Are there color elements that cannot be identified?
  9. Are data tables coded with column headings and row names in the scope?
  10. Does the web page have frames?
  11. If there is a timed response, are users prompted to request more time?
  12. Are electronic form elements organized in a logical tab order and labeled?
  13. Are links provided for applets, plug-ins, or third-party software that might be required to access content on the web page?

The checklist above provides a highlight of items that ought to be reviewed for all web pages and web-based applications; however, for a complete list of items, you can visit the W3C's Checklist of Checkpoints for Web Content Accessibility Guidelines, which provides the full list of priority checkpoints. The priority checkpoints are divided into three priority levels, where the web content:

Priority 1 - Must satisfy the checkpoints Priority 2 - Should satisfy the checkpoints Priority 3 - May address the checkpoints

More resources

About

Ryan has performed in a broad range of technology support roles for electric-generation utilities, including nuclear power plants, and for the telecommunications industry. He has worked in web development for the restaurant industry and the Federal g...

2 comments
lunchbeast
lunchbeast

I've long suffered the results of an injury to my right hand that makes using a mouse virtually impossible. However, I manage hunting and pecking on the keyboard fairly well, which means most software is reasonably easy for me to use because most vendors use standard keyboard shortcuts or at least are consistent within their own package(s). Regrettably, many websites completely ignore keyboard navigation in their UI, and more and more thin client browser based software is coming out with the same problem. There are controls on the pages that you simply cannot get to with the keyboard, and even on the ones that don't suffer that failure, getting to a control can require dozens of tabs that may not even be in any kind of logical order. I've tried various browser add-ons that let me define shortcut keys, but there's always some kind of compatibility issue that seems to pop up with them with a browser or OS patch. And don't get me started on that Windows 8 $hitware or the equally heinous Microsoft Ribbon. It's refreshing to see somebody point out the need for keyboard UI functionality and standards for it. At least it means I'm not the only one that thinks developers are dropping the ball when the neglect this aspect of their software. lunchbeast

richard.s
richard.s

Sadly even large companies are ignoring "accessibility" and setting a poor example for others: Yahoo! is about to withdraw the "classic" interface to its popular webmail service. Many people with poorer eyesight find the "new" interface far less accessible, but Yahoo seems to be ignoring the problems. Also, Yahoo appears to be making a common mistake: They seem to recognise only two types of people: - People who have "normal" eyesight; - People who use special screen-reading software such as Jaws. But this completely ignores the much larger number of people, many of whom are registered as "partially sighted," who cope by adjusting the settings in their PCs and web browsers; most obviously by enlarging the text. Even Yahoo's young designers, will one day need enlarged text to help them cope with their changing/failing eyesight. The inflexible layout of the "new" Yahoo webmail interface does not work properly with enlarged text: Lines in email messages become hidden behind the large adverts; the over-wide control bar "wraps" so that its buttons interfere with the left-hand menu; the layout of the control bar is poor, so that commonly used buttons are "lost" while less commonly used buttons remain in full view. This is rather similar to the poor interface design adopted by Mail.com when their webmail service became "powered by AOL." I've avoided that service ever since. A website, web service, or software program which works only for people who have either normal eyesight or a screen-reader, really cannot be classed as "accessible."

Editor's Picks