Understanding Compliance for ADA and Section 508 Regulations
January 13, 2017
By Alison Weidner, Senior Manager, Quality Assurance, HCCS, A HealthStream Company
Several years ago, we started getting inquiries for our billing, security, and workforce compliance courses to be made compliant with ADA and 508 regulations. In particular, customers were expressing interest in the standards set forth by Section 508 of the Rehabilitation Act of 1973, as well as by the ADA.
What are these regulations? Why should I care? Why did it take us so long? What's involved in making all of this stuff work?
508 compliance means that all users, regardless of disability status, can access technology. It’s a way to break down barriers and provide the same opportunities for all Internet users.
Compliance standards are set by Section 508 of the Rehabilitation Act of 1973 that requires federal agencies to provide software and website accessibility to people with disabilities. When websites are 508 Compliant, they are accessible to all users. This can mean that they are compatible with assistive technology, such as screen readers. ADA compliance for websites has a similar goal and stems from the same regulation. Government entities that receive federal funding are generally required to conform with accessibility standards, as are their sub-contractors. By working to meet the standards of Section 508, along with recommendations from the W3C Web Accessibility Initiative (WAI) and WebAIM organizations, we are now able to deliver our courseware to users in various categories and levels of vision, hearing, physical, and cognitive disabilities.
There’s a lot that goes into complying with these standards. The website https://www.ada.gov/pcatoolkit/chap5toolkit.htm gives a great overview of the problems and challenges when building a website accessibility.
For starters, every graphic and image has to have a text equivalent—so that a screen reader can literally read the content aloud for someone with visual impairments. Next are issues with text sizes and font colors, video and other multimedia, and embedded documents that may not be compliant. For courseware websites like ours, there are additional challenges. Most of the navigation repeats on every page and the learner progresses through the courseware. A visually impaired learner does not want to hear a description of every button on the page each time he or she progresses to the next page. We needed to "teach" the screen reader to identify the important elements to read first and which to read last, so a learner can skip the repetitive ones that come at the end.
Below is a screen shot of one of our testing utilities—the Web Accessibility Evaluation Tool or "WAVE." Our course does not actually look like the screen I’m showing. There are various warnings and alerts to help our programmers identify what needs to be addressed so the courses are ADA and 508 compliant. On this screen, we might want to tell an accessibility screen reader to start reading "Welcome to the Nursing Facility Compliance Library Resident Care Risk Area course." After reading the text below that introduction, we want to tell the reader that the screen has a graphic of a compass with the word "Risk" written on it. Finally, we want the screen reader to list the navigation elements in a specific order.
One of the challenges encountered was the need to program for the wide range of assistive technologies that help users across the different categories of needs. Screen readers like JAWS, VoiceOver, and NVDA provide varying levels of support consistency. There was also the complexity of handling tabs and modal windows and also having to identify and add roles to the markup even though HTML5 is supposed to define those properties—that ended up being a lot of work just based on volume. We also included programming for users with cognitive disabilities like elements that provide attention focusing assistance.
Our QA strategy for the initial round of testing was to first utilize the Wave Tool to analyze error or warning messages, to review alternative texts, and to identify contrast issues. Next we used VoiceOver to test that we were able to navigate through the course, access the exercises, and successfully complete the course. The main reasons for choosing Apple’s VoiceOver in our initial round was because it was readily available, because it was user friendly, and because it’s one of the commonly used screen readers.
In Beta testing, we were fortunate enough to partner with the University of Washington’s Accessibility Team. These specialists helped us to further refine the accessibility of our product. They identified and prioritized what was more important to accessibility users. One of the surprising recommendations from UW’s team was the concept of “Don’t be too helpful.” For example, providing appropriate landmarks for assistive technologies is required, but if you provide too much information that could lead to annoying repetition in some screen readers. They also tested our courseware under the guidelines of WCAG 2.0 AA. This is important since the proposed new standard for Section 508 is expected to require conformance to the W3C Web Content Accessibility Guidelines (WCAG) 2.0 Level AA.
Since embarking on this journey, HCCS/HealthStream is now proud to provide accessibility options for all of our authored courseware.