Hiding Content for Screen Reader Users
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.
Assessing Effectiveness
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.
Summary
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?
David Zemens - 1955 Design responds:
Posted: January 7th, 2008 at 7:52 am →
Mel makes a great point, Mike. As usual, however, you have given considerable thought to the process and to my mind have come up with several reasonable, well meaning, well thought out and well implemented solutions.
Like most things in life, a common sense approach to the problem is usually the best method in which to proceed. It seems to me that this is the approach you normally take. Both your offset Navigation heading and your offset “second line address” idea both seem like great idea and practical solutions.
This is a great article with the intended “snowball effect”. Mel’s comment got you thinking and your article got me, and others, thinking as well.
Sarah Bourne responds:
Posted: January 7th, 2008 at 10:11 am →
The one place I use offsets is when words are in a background image, which has no ALT attribute. For instance, we use it to give the text of the words that are in our logo, which is included in a rotating , decorative banner image. This way the text part is available to screen readers and for printing.
Mike Cherim responds:
Posted: January 8th, 2008 at 12:11 am →
@David: Thank you.
@Sarah: I just thought of something you need to be consider before doing that as an image replacement technique. If you hide text by way off-setting it using absolute positioning (or any other off-screen method) that text won’t be available to users who do not support, or choose not to support, images. In such a case I would suggest either going with an embedded image or using a different image replacement technique. I use an empty span technique. I didn’t create it. I don’t know who to credit for it, but it’s one of those well-known “IR” methods.
Mel Pedley responds:
Posted: January 8th, 2008 at 10:47 am →
Like all “accessibility enhancements”, I think it boils down to thinking carefully first and then judiciously applying selected “extras”. What can happen (and I’d guess we’ve all done this at some time) is that someone discovers a new technique - such as the off screen positioning - and then, flushed with the joys of being able to communicate directly with a single group of users, proceeds to add all kinds of extra “helpful” messages with gay abandon.
It’s all very well intentioned but, as we know with other features such as tab indexing, applying this approach without considering each and every application on its own merits often ends up creating more barriers. Like yourself, I often use a header on my site navigation and I do hide that off screen but then we’ve both tried to weigh up the pros and cons of this before taking action and we’ve both tried to look at it from the perspective of a range of users rather than a single, closely defined group.
What can’t you assume?
Well, you can’t assume that all screen reader users have sight problems. Dyslexics may use screen reading software for additional reading support. Frankly, I think they have enough problems without developers throwing in a lot of extra text that isn’t mirrored in the visual display. That’s a recipe for confusion - not support.
Even if the user has a severe sight impairment, we cannot make many assumptions about what their software can, or can’t do. JAWS, for example, has it’s own audio cues which can be played before certain types of structural markup. If we then replicate that functionality using “hidden messages”, the overall gain is zero and we may have just introduced a lot of unwanted noise.
There are definitely times, in my opinion, when we should just let assistive technology get on and do its own thing without our interference. We are not here to provide all things to all users. Our job, as I see it, is to ensure that users have the opportunity to chose how they receive content - not to make the choices for them. And not to replicate, or create, functionality that they may already have or may not want.
Mike Cherim responds:
Posted: January 10th, 2008 at 1:33 pm →
Thanks Mel.
froodish responds:
Posted: January 11th, 2008 at 5:28 pm →
One place I use some css-hidden content is errors in form fields. Visual browsers get a message about completing the highlighted form fields and there’s also a list of the fields with problems for AT users that’s hidden.