Engineering a Website with Section 508 Compliance and Accessibility In Mind

All modern applications for the desktop, mobile, and web can be used with a screen reader, and knowing how to properly program an application with this in mind, is a valuable skill in today's world.

A screen reader is a software application that identifies and interprets what is displayed on the screen for use by the visually impaired. Or to put it another way, it transforms text to speech. Screen readers are now in all major operating systems (such as Apple Mac OSX, Microsoft Windows, and Linux) including mobile operating systems (such as iOS, Android, and Windows Mobile).

There are many types of screen readers including Text Screen Readers, GUI Screen Readers, and OS accessibility tools. Also, the accessibility API systems in operating systems are known as self-voicing applications. Many have screen readers specifically designed for browsers and web applications. When there is no direct text available but images of text or handwriting, there are optical character recognition (OCR) screen readers.

Two compliant standards affect how most websites are designed for screen reading technology. The one I am most familiar with is 508 compliance. This refers to the Section 508 Amendment to the Rehabilitation Act of 1963. The other standard is known as the Web Accessibility Initiative (WAI). It is part of the World Wide Web Consortium (W3Cs) WAI standard and is an effort to improve accessibility of the World Wide Web for people with disabilities.

Many states and all federal agencies’ technology stacks are required to be compliant with the Section 508 standards. But being in compliance does not mean that you have to meet all the technical standards. If it is too difficult or expensive to meet a standard, there are general exceptions. Exceptions such as difficulty meeting a National Security Agency standard or a NIST security standard can be granted, but in all other cases where implementation of the standard would not cause undue hardship to the federal agency or department involved, 508 compliance must be achieved.

The standard states that all information that can be accessed electronically must be available to people with disabilities. It is permissible if some users need certain software in order to access certain information, such as screen readers or display magnifiers.

Any web-based intranet or Internet applications must have accessibility to web content. For example, text descriptions for any visuals such that users with a disability or users that need assistive technology can access the content are required.

Now that you understand screen readers and the compliance standards, let‘s go over some compliance tips and tricks. This will help with designing a new, or modifying an existing, website to comply with these standards.

Software Aids

Almost all application-based screen readers work off the same principle: the application reads through the text on screen by linearly traversing, or iterating, through the text content, going from left to right and top to bottom, just like a user reading the document. When the screen reading application encounters a change in content, such as an AJAX call, on the page, the reader usually stops the current navigation through the content and the reader restarts reading the page after the change in page content is completed. This also can mean changes the user can’t see, such as the reader iterating through the page from HTML to hidden assets such as JavaScript and CSS embedded into the page or rich content such as audio, video, flash, or HTML canvas elements.

HTML Code

It is recommended to keep your HTML code grouped and in order on the page. I believe this is the most important design choice you must make when preparing for screen readers. One best practice is to make screen reading easier is to make sure you limit your use of headings, divs, and spans with CSS that moves them on the page. Another tip is to make sure to separate the content portions of your website according to type; such as JavaScript and CSS on the top of the page (preferably in a reference file) and HTML content in the body with rich content such as video, audio, or flash embedded in the body without much CSS.

AJAX

Almost all older screen reading technologies cannot handle AJAX (also known as Asynchronous JavaScript Calls or postback AJAX). AJAX causes the screen readers that integrate into web browsers to lose their place on the page and start over. When working with these screen readers, I have implemented a “508 Compliance Mode” that disables postbacks. Instead, when a change happens on the page, it simply refreshes the entire page to show the update.

Flash Content

When you want a website to have maximum accessibility with the least amount of complications, stay away from flash content. Many screen readers, and even iOS devices, do not support flash and the ones that do suck at dealing with complicated flash content. But if you must use flash, populate the data in the flash portions of your webpage using the technique called frontloading. This means that you write brief paragraphs of content and place them early in the action script, and in order, inside the flash content so that is easily viewable for the screenwriter. An easy way to test flash to see if you have good screen reader compliance is to check if you are able to highlight text, or copy and paste text from the flash element. If this is true, then most flash supporting screen readers will be able to access this content.

Written Content

When designing a webpage for accessibility, ensure that you add a summary paragraph of each page at the top of the page and summaries above large blocks of written content. This allows a disabled user to get a brief and quick understanding of what information is on the page, or what page does, and therefore will be able to make decisions on what to do and where to navigate. I believe this is a best practice in general because it has the same benefits to seeing users.

Headings

Make sure to use accurate descriptions of all headings and to use the proper types of header tags (e.g. <h1> … <h6>) so that the screen reader can understand where you are in relationship to the entire page. Most screen readers create hierarchal indexes of the header levels and title tags as a way to skip to different portions of the page.

Images and Links

When using images on your website or application, make sure to always include the “alt” attribute, an alternative descriptor, when embedding rich content. This “alt” text will allow the screen reader to describe to the user what the content contains. Also use this tag for links. Don’t put “click here” or “forward” or “next” in an “alt” or “tooltip” tag for a link, say what the link goes to, such as “Next Page: Step 9, Confirmation”; this will give much better guidance to the user.

I believe these practices and tips are a good start for creating web pages with accessibility in mind, but nothing replaces good user testing. Good Luck!