Background

On December 21, 2000, the technical standards for implementing Section 508 of the Rehabilitation Act of 1973 as amended by the Workforce Investment Act of 1998 were published in the Federal Register. These standards set forth, in very specific terms, criteria that must be met by software, hardware, web sites, and other electronic and information technology (E&IT) to ensure its accessibility to individuals with disabilities who are either employees or customers of the Federal government. After June 21, 2001, agencies that procure E&IT that does not meet these standards, leave themselves open to either administrative complaints or private rights of action in the Federal courts by disabled individuals unable to utilize this E&IT as a result of its inaccessibility.

These standards are of particular concern to Federal webmasters, whose web sites are potentially available to every person with access to a computer, including the millions of disabled individuals who use a variety of assistive technology to access the Internet. The phenomenally wide visibility Federal sites enjoy through the medium of the Internet brings with it the responsibility of ensuring that Federal web sites are as accessible as possible, meeting the 16 508 web-related standards to the fullest extent possible.

Since the June 21, 2001 implementation for compliance with the standards for Section 508, the number of questions concerning the proper methods for testing web sites for compliance with these standards has been increasing at an alarming rate. Both sound information and myths abound, and the web development community is fraught with concern regarding its ability to meet the accessibility standards. The Department of Education’s Assistive Technology Program, the Access Board (publishers of the Section 508 standards), and other agencies in the forefront of accessibility testing, have been inundated with 508-related questions, especially as they relate to web development and accessibility.

One of the dilemmas facing the Federal IT professional as we contemplate ensuring compliance with Section 508 in the development of ongoing web sites under the new standards, is that although the web developer may have little to no knowledge of accessibility, they are nevertheless held accountable for ensuring the accessibility of the agency’s sites. Though the development community of vendors providing web design and development services must become familiar with the 508 web-related standards to ensure that their deliverables meet the requirements as set forth, the Federal web master is faced with the daunting task of establishing some mechanisms for quality assurance and verification of whatever accessibility-related assurances the vendor may provide. No Federal IT professional can afford to rely solely upon vendor assurance as a means for maintaining quality control, and thus, a certain level of expertise must be attained by the IT professional who wishes to verify that their sites are in fact accessible and in compliance with the Section 508 standards.

As Federal web developers have begun wrestling with this objective, many have begun to contemplate the establishment of small in-house testing teams, made up of individuals who show an affinity for the appropriate use of assistive technology such as screen readers, screen magnification software, etc. Of course, for those agencies with well-established in-house testing labs such as the Social Security Administration, the Department of Education, the Department of Agriculture, the Postal Service, the Department of Defense, and others, testing for accessibility is already commonplace, and in these agencies, the various development teams can generally turn to lab staff as ongoing sources of testing, technical assistance, and advice regarding the implementation of accessible web design.

However, for the agency without such a team, who must therefore rely on staff for whom accessibility verification is only one of many duties, but who nevertheless must develop some level of acumen in the use of assistive technology in order to test their sites with some reliability, we offer these simple yet useful tips on how to use assistive technology effectively for testing purposes.

Where to Begin, and for Whom

One of the first questions people ask when trying to figure out where to begin in ensuring accessibility of the web to persons with disabilities concerns developing an understanding of which disabilities are affected most by web access so as to understand where remediation and testing efforts should be concentrated. Of no less concern is the anxiety about how to test compliance for each of the 16 individual web-related 508 standards, something that can appear to be an impossible task for the already overworked web master.

Fortunately, for the web master who has little knowledge of disability and access requirements, these 16 criteria break out into broad logical categories, some of which do not require any testing with assistive technology whatsoever in order to verify compliance. If we look briefly at those of the 508 standards, which relate to web-based Internet and Intranet sites (1194.22), we will see that most of the standards are designed to ensure accessibility of the web to persons with visual impairments. This is because most of the problems encountered in accessing the web, as an output medium requiring extensive navigability, are related to the visual accessing of information provided through a software interface. Thus, we can see that people without vision are the ones who are most profoundly affected by the nature of this interface, and who, by virtue of its design, either succeed or fail in gleaning the information they desire from a given site.

To clarify this further, let’s briefly review the 16 Section 508 web-related standards, the disabilities to which they apply, and what, if any assistive technology is necessary to test them for compliance.

1194.22 Web-based intranet and Internet information and applications.

“(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).”

Standard (a) impacts individuals who are blind, since descriptions of non-textual elements must be provided for those who cannot see them.

Compliance with this standard can generally be verified by examination of the HTML code to ensure that all images, image map hot spots, and other non-text elements contain text descriptions. In complex situations, such as where Java Script or other scripting languages are involved, the site can be tested with a screen reader to ensure that the descriptive information is properly exposed to the user.

One of the big misconceptions which has crept into the lore surrounding section 508 and the web involves the use of the Alt attribute to provide descriptions for images and other non-textual elements. Many regrettably believe, due to the phrasing of the standard, that every image must have a verbal equivalent, which must be spoken out loud. This is far from true, and web developers should realize that the audible labeling of graphics used for formatting purposes such as spacers with audio descriptions actually adds to the inaccessibility of a site by creating audio litter. For those images which do not convey content or navigation information, alt= " " is recommended for use as an appropriate solution. The screen reader skips over the unimportant graphic and remains silent, keeping its verbal output to the blind user clean and informative.

“(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.”

Standard B impacts blind individuals who may need audio descriptions synchronized to visual multimedia, which they cannot see, or hearing-impaired individuals who may need text captioning synchronized to audio multimedia material, which they cannot hear.

Assistive technology is not required to test for compliance with Standard B.

“(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.”

Standard C impacts those who are color-blind and cannot discern a given action depicted by color alone.

No assistive technology is required to test for compliance with Standard C.

“(d) Documents shall be organized so they are readable without requiring an associated style sheets.”

Standard D applies to people with all disabilities.

No assistive technology is required to test for compliance with Standard D.

“(e) Redundant text links shall be provided for each active region of a server-side image map.”

Standard E applies to individuals who are blind, since it is these redundant links, which are read with a screen reader, which cannot interpret the hot spots on a server-side image map.

As with Standard (a), compliance with Standard E can be verified through examination of the code, although the proper reading of these redundant links can be verified with a screen reader.

“(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.”

Again, Standard F impacts those who are blind. This standard states a preference for the use of client-side image maps where possible, since the hot spots on client-side image maps can be labeled with the alt attribute and thus be read by the blind user.

Compliance for Standard F can be verified through examination of the underlying code. When deemed necessary, the proper reading of the labels for the hot spots on these image maps can be verified with a screen reader.

“(g) Row and column headers shall be identified for data tables.” and “(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.”

Standards G and H also impact those who are blind, and raise more questions from web developers than any of the other standards, with the possible exception of Standard (l), which will be discussed shortly.

Due to the variety of attributes, which can be invoked in table construction, the complexity of the tables which can result from their use, and the inconsistency with which table attributes are handled by various screen readers, the Access Board has prepared state-of-the-art technical guidance on accessible table construction.

It is generally accepted however, to use the “scope” attribute to associate row and column headers with their corresponding cells in a rectangular table, and the header/id tags in more complex multi-level tables which contain diagonal associations. Jaws and other screen readers recognize the scope and the header/id attributes.

“(i) Frames shall be titled with text that facilitates frame identification and navigation.”

Standard I also impacts those who are blind.

Standard I compliance can, as with many others, be verified by an examination of the HTML code, but can also be tested with a screen reader. The Access Board is also issuing guidance on proper frame titling techniques.

“(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.”

Standard J affects those with seizure disorders for whom the onset of seizures may be triggered by material blinking within the specified range.

No assistive technology is required to test for compliance with Standard J. Individuals should utilize the blink rate specifications provided with the blink generation software to determine compliance with this standard.

“(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.”

Standard K primarily impacts those who are blind.

Verification of the non-utility of the inaccessible page should be tested with a screen reader. The accessibility of the alternate text-only page can be tested by examination of the code or with a screen reader.

“(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.”

Here too, Standard L is designed to assist the blind surfer by ensuring that text produced via scripting is available to the assistive technology.

Compliance for Standard L should be tested with a screen reader, since it may not be possible by code examination alone to verify the availability of functional text to this technology. Here too, as with tables and frame titling, the Access Board is issuing technical assistance guidance on how to construct scripts, which will yield functional text for capturing by the screen reader.

“(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with 1194.21(a) through (l).”

Standard M deals with those occasions when a plug-in is necessary to present content to the user which falls outside the standard HTML interface, thus requiring that the plug-in comply with the standards contained in another section of the 508 requirements. These requirements for plug-ins and other desktop software applications are not covered in this article, which is devoted to the specific discussion of web accessibility.

“(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.”

Standard N is also designed to assist the blind because it impacts their ability for accurately filling out forms on the web.

Here too, because of the wide variety of techniques used in form construction, which can impact the accessibility of these forms, compliance with Standard N should be tested with a screen reader. In addition, guidance may be issued in accessible form construction by the Access Board as well, to ensure a high level of accessibility in this area.

“(o) A method shall be provided that permits users to skip repetitive navigation links.”

Standard O allows repetitive information at the top of each page to be skipped so that those using screen readers don't have to listen to the same repetitive links each time a page is loaded. Standard O also assists those with mobility impairments who want to skip directly to page content and find it easier to click on a "skip navigation" button.

Standard O requires no assistive technology for compliance testing, although screen readers should be used to test if transparent gifs or gifs with the same background color are used making them invisible except to the screen reader. However, some discourage the use of invisible graphics as skip links as it negatively impacts the ability of a person with a mobility impairment to use these links.

“(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.”

Standard P is designed to allow persons with mobility impairments who may be slower than average in filling out a timed form to be alerted that time is running out and extend the time if necessary. It applies to individuals with mobility impairments which affect their ability to input data at the normal rate of speed.

No assistive technology is required for compliance testing for Standard P.

Formulating a Testing Strategy

As should be evident by now, when it is necessary to use assistive technology to test for web site accessibility, the only assistive technology that is required for ensuring compliance with a given standard is the screen reading technology used by the blind employee or customer who will also be accessing the site in the same fashion. As stated above, those standards not requiring assistive technology can be evaluated for accessibility through simple code examination and observation.

Ok, so what is a screen reader?

This technology, which resides in the user's computer, translates the visual web interface into spoken or Braille output thus making it available to the blind surfer. In fact, the Section 508 standards were designed in such a fashion so that if followed correctly, the web developer would have the best possible chance of ensuring that the screen reading technology currently in use today could best interpret the web display in a manner understandable and useable by the population of blind web surfers.

Think of it this way - when a blind individual surfs the web, or does anything with a computer for that matter, she does it without a monitor and without a mouse. Sound impossible? Well, it is, unless you have software, which provides you with verbal or Braille feedback about what is on the screen, and that, in a nutshell is what a screen reader does. The next time you hear someone question the utility of the 508 standards because they don't understand their value, just tell them to unplug their monitor and their mouse and without any assistance, turn on their computer and print out the home page of their favorite web site. In fact, promise them a million dollars if they can do it right now. You can be sure that without a screen reader, they won't be able to do it. (The author of this document is not liable for million dollar claims made as a result of reading this article.).

This discussion is in no way meant to diminish the importance of ensuring the accessibility of the web to persons with other disabilities. As stated above, there are web-related standards under Section 508 which definitely speak to ensuring the accessibility of the web to all persons of varying disabilities other than blindness -- requiring for example, that multimedia presentations be captioned for persons with hearing impairments, or that individuals with mobility impairments who may input data more slowly than average be alerted when timed responses are being encountered. Our point here though is simply that although they are just as significant as those standards affecting web access for the blind, these standards differ in one significant fashion -- compliance with them can be verified through simple code examination or site observation, and they do not, as do the blindness-related web standards, require a testing process using heretofore unfamiliar assistive technology such as screen readers.

Thus, to truly assess a site's accessibility to those blind employees and customers who may encounter it, the web developer or their designee will have to become at least minimally familiar with screen reader technology, in order to ensure that it is being used properly and is thus yielding accurate and useful information about the accessibility of the given site in question.

This is especially true in our discussion here with regard to the accessibility of complex web technologies, e.g., table construction, the use of Java scripting in revealing functional text, form development, and frame labeling.

But by mastering just a few simple screen reader techniques designed to assist the user in navigating these complex technologies, the web designer can experiment with different scenarios in these complex areas which, though all visually appealing, may each offer various access-related advantages and disadvantages which the developer can uncover by exposing these various scenarios to the screen reader environment. With just a little information, the web savvy person examining a given page can make at least some determination as to the site's accessibility, and based upon experience with the screen reader, can choose coding methods which yield the greatest possible accessibility while retaining the look and feel of the particular site design.

One Goal, Many Strategies

As with most anything in this life of ours, there is usually more than one way to do anything well, and with screen readers, this is no exception. Suffice it to say, without getting sidetracked, that each of the major screen readers/talking browsers on the market today handle the web with its complex technologies just a little bit differently, some providing greater or lesser levels of access depending upon the situation, page design, and complexity of the material being presented. Section 508 however, was written specifically to avoid the trap of requiring agencies and customers to rely upon a single screen reader technology to provide an appropriate level of access. The reality in fact, is that all else being equal, web coding in full compliance with Section 508 standards will yield different levels of access depending upon which screen reader is use. This is not your problem, and we wish to make it clear that your obligation is correct or appropriate 508- compliant coding, not the perfect performance of each screen reader on the market.

Some screen readers work better than others in different situations. By understanding and accepting this, you can test for compliance recognizing the limitations of different screen reader technologies. This of course raises the question of what happens when a site appears to be 508 compliant, but due to one factor or another, is not being handled well by a given screen reader. Does this inability of a given screen reader to handle a given site mean the site is out of compliance? Although there is no hard and fast simple answer, there are instances in which a site can be fully compliant yet yield inaccessible information due to a screen reader's inability to properly render the compliant coding.

For example, each screen reader handles tables, especially complex ones with multiple headers, differently and with a different level of skill, and one of them, due to its reliance on access technology which doesn’t yet effectively render tabular information in a useable fashion, can't yet read tables at all.

Does this mean that the use of tables is non-508 compliant? Not at all. By following the 508 standards and using the guidance issued by the Access Board, it won’t be long before assistive technologies catch up to the HTML specification currently in use, thus rendering the information in a useable form according to the 508-compliant code it encounters.

A reader’s inability to handle 508-compliant HTML is, we assure you, the exception rather than the rule, and should not deter you from establishing some level of testing and ensuring that your sites are both Section 508 compliant and thus accessible.

With this in mind, let's move to a discussion of the kinds of things screen readers do, and what one can expect from their use.

In making a determination as to which screen reader to test with, first, find out what screen reader your particular agency has standardized upon. Ask around and see if there is one that many of your blind customers are using? Once you ascertain which reader is in use within your agency, either obtain a demo copy or purchase it from its manufacturer. If you can find a savvy blind web user who can give you some testing time, so much the better; if not, you will need to get hold of one of the screen readers with which your site is being accessed. And of course, if you want to test with more than one, given their various strengths and weaknesses, we won't object. And remember, don't be put off by the seeming strangeness of the technology - your goal isn't perfection, but it is accessibility.

What to Expect Once you have picked a Screen Reader

1) All of these technologies will talk to you as you install them. This is normal and should happen if you are using an appropriate sound card (these days, most will work fine). So, when you talk to the vendor, find out first how to slow down the speech rate so you can understand what it is saying. You can't test for accessibility if you don't understand the speech, and although you will get faster if you use it enough, you should start out slow and comfortable.

2) With the exception of the Home Page Reader (a talking browser produced by IBM), other screen readers have been designed to work with a multitude of programs. If you use such a screen reader, before you open your first web page, go into say Notepad and write yourself a letter. Get brave even and turn off your monitor and leave that mouse alone. Listen to what happens as you hit your up, down, left, and right arrows, and what happens when you add the control key to various cursor movements. Can you hear the letters as you type, the lines of text as you move up and down, and the words as you ctrl-arrow right and left? Hit the alt key and move among the options in the menu bar and listen with your ears to what your eyes would normally tell you. Try opening the File Menu, arrowing down to the Save option, and hitting the Enter key. Can you type in a file name without looking. Can you tab to the Save Button and hit enter to save your document without using the mouse or looking at the screen.

Remember, your goal, within the context of limited time, is to at least become a little familiar with the paradigm of "Look Mom, no monitor, and no mouse." Get a little bit used to learning what it is like to be blind and receive information from your computer using a heretofore mostly unused sense - your hearing.

3) Next, read and print out the help section on how your screen reader interacts with web pages. For example, WindowEyes tells you when the page is done loading; Jaws for Windows tells you the same thing by telling you how many links are on the open page; and the IBM Home Page Reader just begins reading the page once loaded. Once you know what you’re listening for, it won’t throw you.

4) This is important!! Learn to shut it up (not you, the screen reader). All screen readers are designed to automatically read the entire page to the advanced user, a characteristic that will no doubt cause great confusion to anyone unfamiliar with the given product. Generally, hitting the Control key as soon as the web page begins reading will stop most readers in their tracks, and that is what you want; stay in control, don't let it talk its or your head off. Remember, you want to examine the page yourself, a line at a time, not listen to the reader just chatter away mindlessly.

5) Understand the concept that all browsers scroll; this means that there is no system caret such as you would find in Notepad or Word Perfect. For blind folks, this is bad news, since scrolling data is generally not accessible in any interactive direct fashion. This being the case, the good folks who put these screen readers together have invented special cursors and large page buffers, which allow an individual to arrow through a web page by as small a unit as a character at a time, or through the up and down arrows, a line or page element at a time. This cursor simulation thus mimics the functionality of a word processor, and although data cannot be input into the page, the blind surfer (and you too) can move through the page in a fashion, which will yield easy to understand results just as if you were carefully reviewing a document in Word. By learning to arrow through the pages in your site to review an entire page’s contents, or to tab from link to link listening to how the links are spoken, you will thus be able to use the screen reader to review all elements encountered in the page, facilitating the reading of text surrounding hyperlinks, and the detailed examining of complex sites.

6) All screen readers also allow the user to simply tab from link to link, verbalizing each hyperlink as it is encountered. This is useful for the web developer who simply wants to test the efficacy of alt text placed on images or hot spots, the proper speaking of labeled form controls, or the availability of functional text in links containing Java Script or other scripting languages.

7) Each screen reader has specific keystrokes for doing specific tasks. For example, when using Jaws for Windows in a table, one must hold down both alt and control while hitting the arrow keys to properly move through the tables columns and rows reading the information contained in each cell along with its header information.

The Home Page Reader, on the other hand, requires that the alt-t key combination be hit to engage table navigation mode. So, learn from the screen reader’s help file what specific keystrokes you need to know to test your site, and you’ll do just fine.

The Bottom Line

Is the testing of a web site with a screen reader possible with a little time and effort? We think so, and experience has borne this out. Does it require a high level of master-level skill and years of training – we think not. We believe, that with a decent level of computer literacy, some patient practice, and a true sense of the mission at hand, anyone tasked with this project can take it on and do it well.

Effective testing with a screen reader, coupled with the code examination for the non-screen reader-related standards, can help to ensure that any Federal web site complies with Section 508. It’s worth the effort, and it’s the right thing to do, and you can rest assure that your site will then be available to the widest audience possible, and that’s what it’s all about.

---

Related Links

• 508 Checklist (WEBAIM)
• Guide to the Section 508 Standards for Web-based Intranet and Internet Information and Applications (1194.22) (Access Board)
• Web Accessibility for Section 508 (JimThatcher.com)
• Testing for 508 Web Accessibility (JimThatcher.com)
• Evaluating Web Sites for Accessibility (W3C)