Website accessibility is more often than not overlooked. I’m not going to pull punches here, even our own website lacks in this area – please be patient with us, we are planning a massive overhaul to improve access, looks and function. More often than not, the culprit behind the lack of access is the vast majority of webmasters around the world. Once a website is up, it requires constant maintenance and upkeep, redevelopment and realignment with new standards. This doesn’t often happen.

Taking the driver’s seat as a user with a visually-impairment is a difficult and unnerving experience. I first did it to test internal software; I fired up a copy of JAWS and shut off my monitor. Minutes later, I was exasperated and frustrated with the software I wrote and depended on – and that was with my knowledge of how the graphical environment worked and looked. I imagined that I was entering important data, perhaps involving finances or the health and safety of a consumer. I decided it was time to learn more about how software, such as JAWS, translated the graphical environment visual users used into the text-based system for users who are blind.

It may be useful to note that this blog article will only focus on HTML-based environments that you would see through your web-browser. That’s because deeper applications have their own methods of reporting accessibility elements to the operating system. Since these are not standards-based, we’ll pass over them in favor of your web browser.

First and foremost, following best practices such as small pages, minimal images and non-complex elements make sense. Cascading Style Sheets (CSS) have been around a while and offer the webmaster a way to apply unified styling to an entire website – allowing one to use text where graphics (which obviously cannot be seen) would otherwise be used. Because text can be read directly, image-based links need a separate description to be useful and load faster on any browser.

Keeping pages small and succinct also makes sense. Visual users hate having to scan through a page for the information they need, whereas users with visually-impairments lack the same luxury and are more frustrated! Because screen-reader software cannot separate important items and links from the rest of the page, the user is forced to listen to the entire page, top-to-bottom until they reach the content they need. Nothing is more aggravating than listening to three pages of text before you get to the link you need.

If the page must contain more than one subject or section, it makes sense to embed anchor tags (<A NAME=[name]>) and links at the top of the page so the user can jump to the appropriate section without waiting for the screen reader to get to it.

Complex elements such as Flash and Shockwave-based menu systems do not work well with screen readers (if they work at all). That’s because all information in these elements are considered graphics and they lack the basic accessibility API that even HTML provides. If a user with a visually-impairment cannot hear the element as read through a screen reader, they may only hear “Flash Animation” despite the fact that your entire site may be designed through a Flash script.

Getting to know accessibility tags and properties is essential. The most salient example of this comes from a site I tested which involved a list of items, all of which had a graphical button to perform the same action on each item (such as ‘Join Group’). Despite the fact that the page developer included an ALT tag on each graphical button, the ALT tag was the same for each – “Join this Group” – which meant nothing to the screen reader because, as I tabbed through the list, I only heard “Link Image: Join Group” repeated as I tabbed over the links. I had no idea which group the selected button was in, so I was completely unable to use the page. Had the developer made the ALT text something like “Join Group titled: Disability News” or “Join Group: Security Issues” I would have known immediately what button I was on. Better yet – had the links been text in the first place and intelligently titled, the link text itself would have been read and immediately useable.

Become familiar with tag properties such as ALT and TITLE. Links and form input fields (such as INPUT and CHECKBOX) can also utilize the ACCESSKEY property to give any user quick access to an element. Properties such as TITLE are very useful to any user; if they highlight an element with this property they’ll get a tooltip with the extra information and a screen reader will read it aloud.
Make sure when you lay out your site links and movement, you take into account an overall site plan that would give the user quick access to common areas of your website. For example, if your site has six main sections, give the link for each section the same access key on every page in your site. That way, getting to “Contact Us” is as easy as ALT-3 anywhere on the site. Remember that many browsers have different methods of implementing access keys so some many not be available on different browsers; safe bets are number keys (0-9) and are easily found on the keyboard by feel.

Going back to the start, how you structure your HTML and CSS is very important. Screen readers will typically read content in the order specified in the HTML file, not the order on the page. This means that, despite your navigation menu appearing on the side or below content, if you place it first in the HTML code and position it visually with CSS, the visually-impaired user hears the links first, while the visual user sees the design as you want it. Additionally, much like there are CSS rules for printers, there are also rules for screen readers which can help you present your content as you desire.

Lastly, research screen reader support regularly using Google and other resources – things change regularly as screen readers are updated in a cat-and-mouse game with developing technologies (such as AJAX) and the way they are implemented (i.e. available Javascript objects, classes and support). For example, heavily-used items with a CSS display value of “none” aren’t read in most screen readers where items displayed off-screen and not visible to visual users is often read in the order it appears in the HTML file. If a script changes these values after the screen reader has passed them, chances are good that they won’t even be noticed unless you anchor the page to the new content.

There are many resources on the internet that can be of use. While JAWS is a commercial program with a sizable expense, there are free, community-developed programs like NVDA that visual users can utilize to experience a website. Turn your monitor off and try to accomplish the same tasks that your visual users would. Browsers such as Firefox may not be commercially supported by screen readers like JAWS, but they do come with a bevy of tools (such as RESEARCHME) that let you disable style sheets or view a site as only pure, plain text so that you can get a better idea of how it is presented to users with visual-impairments. A few moments of research will yield a wealth of information that will come in handy in fixing the issues you’ll invariably find with your site when you step outside the realm of visual cues and presentation.