This practice, while it does carry risks, like most things we do, can be successful, but it must be used intelligently and in moderation.
My friend and colleague, Mel Pedley, brought up a point recently — as we were discussing a site being graded at Accessites — about hiding text for screen reader users using an “offset class,” where one uses absolute positioning to send the element outside the viewport, usually by thousands of pixels. Our grading discussions are under lock and key, available to the team members and site submitter only, so there’s no sense providing a link, but here’s an excerpt:
If we start adding ‘hidden’ messages that are rendered by screen readers, we risk either creating unnecessary noise for non-sighted users or completely confusing sighted screen reader users. Been there, done that, some years ago. Fortunately, a very experienced JAWS user politely suggested that I drop the idea. — Mel Pedley
Since this is something I have been exploring quite a bit during the past year or so, and actually employing in a few cases as well, I was taken aback. A bit disappointed actually to learn my well-meaning practice might not be appreciated or found useful, or worse, viewed as clutter or deemed confusing. And I never considered the sighted screen reader user. The practice of adding some content is well meaning, of course, but if it’s not useful or helpful…
Then I started thinking about it and realized this practice, while it does carry risks, like most things we do, can be successful, but it must be used intelligently and in moderation. Just like any progressive enhancement. In the last sentence in the paragraph above, I feel it’s important to emphasize the word some: The practice of adding some content.
Some Content, Defined
I feel it’s now necessary to define “some content” and hopefully spark some discussion about the potential merits or possible lack thereof for each. Here are three examples:
Hiding Some Headings
This may immediately strike someone as a bad practice, but I think there are a few isolated situations where this can be used successfully. One such case — and you’ll find it on this blog — is a hidden heading for a navigation menu. My main navigation menu should be very obvious to any visual user using my style sheet, but to a person not supporting styles, or a non-visual user listening to the site being verbalized, this may not be so obvious. There are, after all, other menus on the page, and structurally speaking, they’re similar. The link text, level of hierarchy, or source order might be a clue, but an upper level heading really spells it out. It leaves no doubt about the list’s purpose and importance.
The screen reader user in particular may very well be able to access the lists and the headings on the page as soon as it’s loaded, depending on their user agent, assistive technology, and preferences. Being given a list headed by a “Navigation” heading seems like a good thing, not clutter, not confusing. And to the sighted screen reader user, I really don’t think it would be noticed. The visual user would likely associate the style or location of the list with the notion of navigation automatically. The mind would say “Navigation” so hearing the heading would seemingly be very natural — an unexperience. Though I’d love to hear what the “experienced JAWS user” would think about it. To me it’s logical, but there are always other views and that they are just as logical to those who foster them.
Some Spatial Clarifications
I have used this in a couple of instances where I feel it’s important to speak in spatial terms to the typical sighted, style sheet-supporting majority user. An example of this can be seen on my company’s site since we have lots of visitors that appreciate a little hand-holding — they’re not geeks like me. You’ll see, on the home page, under the heading “Getting Around this Site,” the paragraph reads like this:
Use the menu to the right to get around this site. You’ll see that when you click on some of the links a new sub menu will appear. There are many pages for you to explore. To learn more about the sections, you might want to check out the overview below. — GreenMethods.com
If, however, you access that page with a handheld style sheet supporting device, text browser, screen reader, or without style sheet support, you’ll get this paragraph.
Use the menu to the right — or after the content if you’re not using our style sheet or you’re using a handheld device — to get around this site. You’ll see that when you click on some of the links a new sub menu will appear. There are many pages for you to explore. To learn more about the sections, you might want to check out the overview below. — GreenMethods.com
I wrapped that text in an offset
span. In my opinion that is a naturally flowing sentence that my logical mind cannot visualize as an impediment to anyone. In my mind I see that as an example of passive accessibility. In other words it exists to those who need it, and doesn’t exist to those who don’t. Perfect? Maybe the sighted screen reader user might notice this one, but I don’t think it’ll be too much of a bother. Maybe I’m wrong.
Some Form Elements
Lately I have been moving form elements out of view more and more, typically the
legend element (when used in conjunction with an inner
span) — and I offer this as an option on my latest contact form script. But sometimes I will offset a
label, too. I only do this if it is visually clear as to what the input or grouping (in the case of a legend) is for. My form script, for instance, hides one label by default. The “Address (continued)” label (see test form page). By virtue of the styling, this should be obvious. Another example can be found on a simple calculator experiment I did.
One word: Empathy. Put yourself in the shoes of the other user by trying it out for yourself. To do this you can fire up Opera and use the voice feature to have the page read to you. You can turn off styles and read the content. Does it sound smooth and natural or is it more of a tacked on afterthought? You can also click on your page, type Ctrl+A with your keyboard to Select All, then type Ctrl+C to Copy the selected content, then in your editor of choice, type Ctrl+V to Paste what you copied. What you end up with, according to Yahoo Accessibility Engineer Victor Tsaran in his video “An Introduction to Screen Readers,” is pretty much what the screen reader user will end up with. Minus, of course, verbal cues such as the announcement of links and headings, and other such assistive technology-specific enhancements.
Please bear in mind, I’m not disagreeing with Mel, not one bit, and what she offered about the “experienced JAWS user” is invaluable. I have had this draft started for a while and when I read that it really inspired me to continue this article but in a more refined way so as to emphasize the fact (as I know it) that this can be useful but only if done with care. To reiterate:
[…] this practice, while it does carry risks, like most things we do, can be successful, but it must be used intelligently and in moderation.
What does your logical mind say?