For years WebAIM has recommended a specific technique for hiding content visually while allowing it to be read by screen readers. This involved using CSS to position the content above the top of the page. It has now been brought to our attention that if the off-screen content contains a focusable element (a link or form element), that the web browser will attempt to scroll to this element when it receives focus – thus scrolling to the top of the page. This could be confusing for sighted keyboard users.
To resolve this potential issue, we now recommend the following styles for hiding content off-screen:
position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
This will move the element straight to the left a considerable distance. Because the hidden element is moved directly to the left, if a link or form element within it receives focus, the browser will not scroll to the top of the page.
The width, height, and overflow styles are likely a bit overkill, but account for rare instances where positioning is disabled, but other styles enabled. Or perhaps for viewports that have VERY large external margins. These styles can probably be omitted in most instances.
It is important to note that it is not generally practice to place links or form elements, which provide functionality, in a hidden element just for screen reader users. Functionality should typically be made available to all users. Additionally, discretion should be used in providing content, cues, or information only for screen reader users. Remember that sighted keyboard users may also benefit from this information. In general, content should only be hidden from sighted users and made available to screen reader users when content is apparent visually, but not apparent to screen reader users.
An article outlining proper and improper implementations and techniques for hiding content is available at http://webaim.org/techniques/css/invisiblecontent/.
This technique has a glitch with dir=”rtl” content : the hidden content has to be pushed to the right instead of left in order to avoid a huge scroll bar.
Hi, just a quick question – I’d just like to know if the following CSS would achieve the same affect:
@media screen {
#skip { display: none }
}
@media aural, speech {
#skip { display: block; speak: normal }
}
Obviously with the intention of being hidden on-screen, but read out by screen-reader software. (My knowledge of the workings of screen-reader software is not the best, so apologies if this seems like a silly question to some of you.)
@Jordan : non, screen-reader skip content in display: none;, and they do not consider aural or speech media yet.
@Oliver G:
First, thank you for your quick response to my question.
@Oliver G:
First, thank you for your quick response to my question. That has helped a lot.
So, if I understand this correctly, you’re basically saying that screen-readers do not pay any attention to the ‘aural’ and ‘speech’ media types?
Yes, not yet.
CSS “position: absolute;” can generate positioning bugs for child elements.
Hi Jered,
I’ve been working lately on WACG 1.0 project where we used a variant of this method; using minus text-indent declaration instead of position absolute would not affect parent to child positioning.
a span {
display: block;
width: 0;
text-indent: -9000px; /* huge for wide HDTV monitors */
overflow: hidden;
}
Is this OK with WebAIM?
Martin-
It works in JAWS, but I believe that some screen readers (I’m pretty sure older version of Window Eyes) will not read content with a negative width or (and?) height. It would require some testing.
I’d have to test, but when used with a link it could result in the focus indicator extending from the link location to the left edge of the screen. I’m assuming this is why the span is being used (which is kinda icky in my opinion, but sometimes necessary).
I’d be happy to learn more about the positioning bugs you are referring to. I’ve never encountered this.
I’ve grown frustrated with the different techniques for hiding content, as I’ve seen too many inconsistent implementations (developers not using consistent phrasing, or picking and choosing when things should be hidden and when they should not). I really believe your recommendations for only hiding content when it’s visually apparent, but not screenreader-apparent, are the main points to take from any discussion on this topic. I’m hoping ARIA will eventually make the need to hide content a thing of the past.
The title “Hiding content for screen readers” is kinda confusing me.
“Hiding content from non-screen-reader-users” would sound better for me.
I’ve long been looking for a way to hide visible content from screen reader users – with no avail.
@martin : The text-indent technique fails if the used does not download the images (RTC connection, broken link…).
@Olivier G.: If dir=”rtl” or dir=”ltr” it always depend on your target group. If you wanna be sure try top:-9999px ;o)