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