The following is republished from the Tech Times #158.
- users that browse without using a mouse
- users that browse using a screen reader
“One person’s preference is another person’s real need. It may be that a group of users finds it easier with Ajax, but if another group of users finds it completely impossible then you’re cutting people out, and you’re doing it for basically nothing.
“I think of it as a hierarchy, basically, where accessibility is the most important thing, and usability comes next, and preference and design and aesthetics comes next. All of those things are important, but if one affects the other then you have to think which is the most important.
“And to my mind, accessibility is always the most important, because accessibility impacts on what people really need. Everything else is just preference.”
- Users that browse without using a mouse
Due to a wide range of impairments, particularly those that affect fine motor control, certain users are unable to use a mouse when browsing the web. Instead, they use the keyboard navigation features of browsers to get around on the Web.
In most cases, keyboard navigation is no more complicated to implement than mouse navigation. All it takes is a little thought, and some extra code to handle this alternative method of interaction. For example, you need to make sure users can reach every “active” element on the page with keyboard focus (typically with the Tab key), and take equivalent actions once there.
- Users that browse using a screen reader
Here’s where things get tricky. Currently, the best available web browsing experience for many visually impaired users is screen reader software. A screen reader sits on top of a desktop web browser, reads the page aloud, and provides additional ways to navigate within the content and to accomplish tasks like filling out forms.
- Screen readers do not read content that is hidden by setting the CSS display property to none.
- Screen readers operate on a static snapshot of the page, which is occasionally refreshed in a process that can neither be initiated or detected by the developer.
Writing scripts that operate under these conditions without interfering with the user’s ability to understand the content and use the features of the site can be extremely challenging, if not impossible in some cases. So what do we teach beginners about this issue, and how well can we expect their scripts to work with screen readers?
The approach to encourage in beginners, I believe, is somewhere in between. Make them aware of the issue, demonstrate some easy ways that you can cater for screen reader users in your scripts (e.g. by using offleft/offscreen positioning to hide elements instead of display: none), and enable them to make informed decisions about the accessibility of their own scripts.