GW Micro recognizes the importance of accessibility for all people, regardless of disability. Our primary focus, however, is on people who are blind and visually impaired. Therefore, the tips we include on this page deal specifically with screen reader related issues.
Web Accessibility Standards
Before beginning any kind of web development project, before the first character of code is written, it is important that you memorize the following web address: w3.org/WAI. This is the World Wide Web Consortium's Web Accessibility Initiative web page considered to be the Holy Grail in terms of understanding and implementing web accessibility standards.
Included on the w3.org/WAI page are an Introduction to Accessibility, Guidelines and Techniques, Managing Accessibility and Evaluating Accessibility, as well as a host of other information and resources dealing specifically with web accessibility issues.
As the W3C's WAI web site provides a comprehensive resource for creating accessible web sites, our goal will simply be to provide you with a handful of quick tips that can help you understand the importance of making your website accessible.
Getting Your Hands Dirty
Although the use of HTML and web based IDEs (Integrated Development Environments) can certainly be beneficial, it is important to understand the underlying code that these applications create.
Knowing how code makes or breaks accessibility is imperative when your customers tell you something isn't reading right. Much like understanding how an engine works can save you a trip to the mechanic, knowing how your code works could potentially save you a lot of time and money when trying to debug accessibility issues.
So use your editing tools, but keep a text editor (like Notepad) in your back pocket, and know how to tweak the code when tweaking is called for.
Common Pitfalls
As a screen reader manufacturer, we have a unique perspective in that we hear directly from our users when they encounter accessibility issues when browsing web pages. Listed below are several common mistakes web authors make that cause screen reader users the most frustration.
Images
The most common complaint we receive from our customers in regard to accessing web pages turns out to be one of the simplest problems to resolve: a lack of descriptive text for images.
Form Controls
The second most common complaint we receive from our customers in regard to accessing deals with entering information into forms, or more specifically, knowing where to enter information into forms.
Click Here
If you asked someone for directions, and their reply was simply, "Over there," you would probably doubt their ability to completely understand the situation. This is the same kind of reaction you'll get from a screen reader user who encounters a link that just says, "click here," or even worse, "here."
Visitors to your website are not going to select a link simply because it is a link. You wouldn't open a suspicious email message from someone you didn't know, would you? Why, then, should you expect visitors to select links that provide them no clue as to where they're going to end up?
Link names (also known as anchor text) should be useful. They should indicate the link's destination, and they should give the individual selecting the link a reason to do the selecting. For example, which link of the following links do you think would garner the most clicks?
Another important reason to ensure that link names are descriptive has to do with a feature that exists in most screen readers today, and that is the ability to present all of the links on a page in one concise list.
Window-Eyes offers such a list when pressing the INS-TAB hot key. When link names contain useful information, the list of links presented to the user can be navigated easily.
On the other hand, when links are poorly named, the user has no good way of determining the purpose of a page, and is apt to quickly navigate to another site, leaving yours in the dust.
Required
Often, when developing forms, you must ensure that certain information be entered before the data can be processed correctly. One popular, and unfortunate, way of indicating that certain fields must be filled out is to color the field name in a color that tends to grab sighted people's attention, usually red. To see how well the method of coloring a required field works for people who are blind, try the following exercise:
- Turn off your monitor.
- Enter your name in the name edit box that is "required".
Name:
Name:
As you might have guessed, identifying important information strictly with color alone is usually not a good way to ensure that visitors will know what information they must provide.
The solution is simple: use the TITLE attribute to place the word 'required' in the field label.
Name:
Most browsers will display TITLE attributes as tool tips when the mouse pointer is hovered over the form control. Window-Eyes, as well as most other screen readers, will automatically retrieve TITLE attributes, and present them to the user when they're tabbing through form controls.
TITLE attributes provide a clean way to tell people who can't see the form what information is most important to ensure a successful submission, while keeping the visual layout of the form intact.
Skip Navigation Links
Creating consistent layout between pages often means having the same set of navigation tools on each page. Sighted people usually have no problem scanning past static navigation links, and finding the main contents of a page. To a screen reader user, however, those navigation links are read at the beginning of each page before the main content. An easy solution to this common annoyance is to include a "Skip Navigation" link. These same page links simply reference the main section of the page so that screen reader users can jump right to the important information. At the top of the page, including a link that looks something like:
<A HREF="#mainContent">Skip Navigation</A>
At the point in your code where the main information begins, you can either use an anchor with a name attribute, or other element with an ID attribute as a reference for the skip navigation link, like this:
<A NAME="mainContent">Main Content</A>
or
<H3 ID="mainContent">Main Content</H3>
Once your skip navigation link is working, you can use style sheets to hide the link from your sighted visitors. The easiest way to hide a link using style sheets is to move the element off screen, like this:
<A HREF="#mainContent" STYLE="position: absolute; left: -1000px;">Skip Navigation</A>
Now the link is positioned 1000 pixels to the left of the left edge of the browser window. It is no longer visible to sighted visitors, but will still show up in speech.
DHTML
Information on the inner workings of Accessible DHTML can be found on the Mozilla Accessible DHTML page.
JavaScript/Dynamic Menus
Like most programming languages, JavaScript can be used to create accessible objects just as easily as to create inaccessible objects. The same goes for dynamic menu systems.
There are, fortunately, several real-world examples of JavaScript/dynamic menu systems that do read well with Window-Eyes. The most notable is the Ultimate Drop Down Menu (a.k.a. Accessible Website Menu - http://www.udm4.com). This is a highly customizable menu system that can easily be dropped in to just about any existing framework.
Other examples can be found at www.adobe.com (the menu bar across the top of the page), and www.google.com (look at the "more >>" link).
All of these examples read well with Window-Eyes, and probably with other screen readers too (after all, your goal is to use a menu system accessible to everyone).
If possible, use one of these existing systems rather than re-inventing the wheel (so to speak). If you do insist on creating your own custom menu system, then use these sites as guides, as their accessibility has already been tested and proven.
Checking Your Work
The best way to know whether or not you have created an accessible web page (aside from validating the code) is to have someone using an accessibility aid (such as Window-Eyes) test your application. The most popular way to find someone to test your application is to subscribe to the GW-Info email list. Almost all of the members of this list have a visual impairment of some sort, and are familiar with Window-Eyes (and usually other adaptive products too). They will be able to provide you with the necessary feedback regarding the accessibility of your web pages.
Writing Accessible Web Applications
The Microsoft whitepaper Writing Accessible Web Applications "is intended to help readers better understand the issues involved in making Web applications accessible to people with disabilities, a legal obligation that also benefits all users of the Web."
