Skip to main content

Talking to the Web

A fellow web development aficionado recently asked me a question I commonly receive concerning web accessibility, so I thought I'd share my thoughts here in hope that others might benefit from my ideas (and hopefully expand upon them). Here's the question:

Is there anything in particular in terms of accessibility or even just coding in general that you find to be the most helpful when using the web?

This is obviously a very broad question and to limit its response to a single blog post probably does not do it justice. However, it is indeed a very simple, honest concern that deserves a simple, honest reply, so I'll try my best to offer my advice here. Of course, you should keep in mind that my suggestions are focused on my own experience in accessibility. My vision and hearing are actually quite good, so I'm not as familiar in accessibility concerning those areas. But I can tell you a lot about how speech recognition works as far as web pages are concerned.

I suppose the main suggestion I tend to stress to other web developers about accessibility is to always focus on carefully and completely designing links. Links are, after all, what the web is all about. Always use the a (anchor) element for links, as anchor elements tend to be better supported by things like speech recognition, screen readers, etc. It can be tempting to sometimes utilize other HTML elements with events like onclick to simulate what an anchor element might do, but this route is a surefire way of leading to accessibility problems.

With that thought in mind, it's also a good idea to make sure that all the links on any given web page can be accessed easily by a straightforward command, which is usually the text of each link. Good speech recognition software actually extracts the text from the visible screen so that when you say something, it will try to find the associated anchor element that matches what you say, and it will go there, which makes this an easier task for us web developers than some of us might think. However, there are caveats you need to keep in mind. If there are several links that sound alike, you are given options, generally a numerical list to choose from, instead of going directly to a certain link by voice, which can be a nuisance if there are a number of links that sound alike. This might give you some ideas on what makes a good name for a link, and what might not. So try to be unique when naming each link and, in general, avoid redundancy as much as you can.

Also, for what it's worth, when dealing with graphical links (and certain abbreviated textual links), it has been my experience with Windows Speech Recognition that implementing the title attribute of the anchor element is the most important component for the speech recognizer (at least for WSR). For images, the title attribute does not necessarily have to be identical to the alt attribute of the embedded img (image) element, but it usually makes sense for both to be the same so that the tooltips match whatever the spoken command would be. I'm not sure if this conforms exactly to a specific web accessibility initiative or not, but this process has generally been what I've used in practice. Also, it is best to try to use this title attribute as a simple, non-redundant command that makes sense in the context of what the link does, not necessarily describing exactly what the image is. Just be sure to remember that the link is always more important than the image. Substance before style.


Anonymous said…
Excellent advice. Accessibility is an important consideration for screen readers and the like, but also for perfectly able people who use a non-standard setup. If I am confronted with a website that requires JavaScript in order for the links to work I may choose to enable JS for that site on my laptop. If I happen to be using my ancient handheld I will have no choice but to give up and go elsewhere.

Thanks for the tip on the title for links, I will try to be more consistent in using a title.
Marc of the Web said…
Thanks for reading, anti! I appreciate the compliments.

I agree with your assessment of JavaScript as often being a hindrance to true web accessibility. However, it should be noted that good speech recognition software like WSR is generally able to parse the DOM, not just the initial HTML markup. But that means you have to be careful with your JavaScript, adding the title attribute when necessary in the code. Of course, this step is easier to forget in JavaScript as compared to markup, so that is often why it is a real problem for me.

Popular posts from this blog

Using the On-Screen Keyboard as an Alternative to Typing with a Physical Keyboard

As an individual with a physical disability who touts speech recognition so much, I occasionally get asked how I ever use the computer without having speech recognition available (since I cannot move my arms well enough to operate a standard physical keyboard)? This is a good question, since speech recognition is not one of the most portable tools around. For example, I've never come across a public computer at a library or hotel that was set up with a good microphone and sound card combo, which are necessities for using speech recognition. So, when the necessary hardware is unavailable, that means I have to look for software to simulate it--in this case, the On-Screen Keyboard . The On-Screen Keyboard is nothing new to Windows; it's been one of the standard accessibility tools for several versions now, not just Vista. It's pretty simple, really, but is extremely useful for users like me who cannot utilize a traditional physical keyboard. Basically, the On-Screen Keyboard a

Using the XPS Document Writer as an Alternative to Printing Hard Copies

The other day, a colleague submitted a programming request to me to try to improve the way some of the pages on our company web site print out. Knowing that I had trouble handling traditional paper documents because of my disability, she was polite enough to ask if we could just set up a quick meeting so she could show me the printed examples and flip through the pages for me. Although I appreciated the friendly gesture of help, I like it when I can suggest simpler, more accessible solutions that really end up saving time for everyone involved. So I asked if she could simply just print an XPS document instead of messing with a hard copy at all. And as somewhat expected, I promptly received a confused "What's an XPS document?" in return. So then, what is an XPS document? Well, if you are really technically savvy and want to know the details, then I'd suggest looking elsewhere, perhaps starting by reading all about the XML Paper Specification at Microsoft . But if