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.
Comments
Thanks for the tip on the title for links, I will try to be more consistent in using a title.
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.