Invisible Content (by CSS) Just for Screen Reader Users

system · April 5, 2012, 2:45pm

In the case of Invisible Content Just for Screen Reader Users, a WebAIM article concludes this:

[…] the CSS techniques presented here are used to hide content, sighted users will never know that the content is there at all (unless they disable styles). Screen reader users, on the other hand, will never realize that this content is invisible to sighted users.

The part where screen reader users are unaware that the hidden content is for them, obviously, made me wonder if there is a way to clarify that for them: what content has been added on their behalf.

For one thing, for them to be able to properly evaluate how much better is it and to be able to provide valuable feedback.

The solution has to be simple enough to accommodate older agents as well.

I thought about using elements like . It’s won’t be very obvious, but it will be a pattern on a site a screen reader user should be able to easily id, since it won’t make much sense.

To exemplify.

The WebAIM breadcrumb:


<p id="breadcrumbs">
  <span class="hidden">You are here: </span>
  <a href="/">Home</a> > <a href="/articles/">Articles</a> > CSS in Action: Invisible Content Just for Screen Reader Users
</p>

The “hinted” WebAIM breadcrumb:


<p id="breadcrumbs">
  <strong class="hidden">You are here: </strong>
  <a href="/">Home</a> > <a href="/articles/">Articles</a> > CSS in Action: Invisible Content Just for Screen Reader Users
</p>

Normally, it doesn’t make a lot of sense to use strong there. This odd event, of using a strong element when there is no “ominous” context, can it became a pattern screen reader users would recognize somehow?

rguy84 · April 5, 2012, 4:44pm

I think you are asking if a was used, could it set off a flag to alert a screen reader user this is special content? It depends on what screen reader is being used. Most have settings to do inflections and announce Alll Caps, End All Caps and such. I know people who don’t care to hear if some part is bolded, they just want the page read. This also runs into the problem of how will be interpreted when used to highlight a part of a part of a sentence, such as: All federal government agencies in the United States of America must comply with Section 508?

The next step would be suggesting a new HTML tag for screen readers only. That could open a can of worms.

Could you also link to your source?

system · April 5, 2012, 7:24pm

It’s not from a source, it’s something I thought of.

I’m asking that if was used, could it suggest even more to a screen reader user, or, at least, to some of them, that it has encountered special content, for its benefit alone.

You’ll notice that in the previous phrase, the element fits well, where as with phrases like below
You are here: ,
Choose from the following links: ,
it makes no sense to use and that would somehow reveal to a screen reader user a special content, for its benefit alone.

Of course it may be a little hard to distinguish from other legitimate elements (like are those in the next phrase). But if it’d follow a pattern of odd use, it’d be easy to spot as an odd use, as it wouldn’t necessarily fit. Also, showing up the same way in several spots on a page, it would be easy an to spot pattern for content meant for accessibility enhancement alone.

<hr>

What’s wrong with HTML tags for screen readers only? We already have tags for screen displaying only: , . Visual elements are somehow better or have more legitimacy over auditory elements?

<hr>

I see your point, but to nitpick, I’m not sure

All federal government agencies in the United States of America must comply with Section 508

is correct use for strong, for several reasons. I see a element there, a element perhaps.

This is a legitimate use of for me:

All federal government agencies in the United States of America must comply with Section 508

rguy84 · April 6, 2012, 3:08pm

Your first line says:

In the case of Invisible Content Just for Screen Reader Users, a WebAIM article concludes this:

[QUOTE][…] the CSS techniques presented here are used to hide content, sighted users will never know that the content is there at all (unless they disable styles). Screen reader users, on the other hand, will never realize that this content is invisible to sighted users.
[/quote]
So I was asking you to post the link to the article you read for the benefit of other users here…

I’m asking that if was used, could it suggest even more to a screen reader user, or, at least, to some of them, that it has encountered special content, for its benefit alone.

Over time screen reader users speed up the read back rate, and some disable the inflections as I noted. So the next thing would have a screen reader sound a chime to set off that special content is hit. This would either need a HTML tag or attribute, and that could open a can of worms.

What’s wrong with HTML tags for screen readers only?
Some of the W3C members try to incorporate universal design, and groups (like mobility, learning disabilities) may get upset of catering the web to them. If a tag was created for screen readers only, naive developers may be like “Oh I am lazy today, I will shove my skip links in that special screen-reader-only tag.” People with mobility impairments and “power users” find skip links benefitical for navigating a page. Well under that mindset, the developer just [unintentionally] excluded two groups of people.

We already have tags for screen displaying only: , . Visual elements are somehow better or have more legitimacy over auditory elements?
These are announced to a screen reader users (and some to most other speech output programs) if they want them to be. They have the choice, the reverse is not true. Currently there is no sniffing capabilities to detect AT, and been discussed at length. Personally, I can use the keyboard to do 85-90% of my daily activities if chose to. Thus making me near impossible to sniff.

is correct use for strong, for several reasons. I see a element there, a element perhaps.

To AT, like browsers/HTML and act the same way. I am not on the HTML5 bandwagon yet, so I will have to ask my contacts with W3C about the thought behind mark. It seems like to me. If a combination of those tags didn’t work, I would either make a CSS class that overrules the default behavior of one of those tags, if I cared about it getting inflected. If I didn’t I would just wrap the phrase in a and apply CSS.

This is a legitimate use of for me:[…]

This is where this thought fails though. This could be extrapulated to making equivalent to parenthesis (). The point about parenthesis is if you remove the words that they are surrounding, the sentence still reads correctly. In both examples, taking out the bolded words, the sentence isn’t complete.

system · April 6, 2012, 4:46pm

Oh… Here it is: http://webaim.org/techniques/css/invisiblecontent/

I’m not sure what you understand by though.
Semantically, is not to bold text, even though visually it may present itself like that. It appears the auditory effect is also similar to ?

And I’d argue that is, in fact, tailor made for screen reader users, as it is the case with (and the two are very different one from another), but I have no real user agents facts to sustain that, while it seems that you have hands on experience, which is better than any theory I might have.

Still, semantics are semantics. ,, have no semantics attached to them. and do.

That’s why I’m lost completely about you seeing as parenthesis…
To me it’s very clear that your example of using is <wrong>, while mine is <right>.

What I’m proposing is a different thing all together. The text I’d apply to will be added text, meaning the content makes sense completely without it. Probably the missing link to the article has added some confusion in our talk.

&lt;strong&gt; doesn't have an equivalent in &lt;b&gt;

&lt;mark&gt; is not the same with &lt;strong&gt;, &lt;b&gt;, &lt;i&gt;, &lt;em&gt;, &lt;u&gt;

&lt;strong&gt;,&lt;b&gt;,&lt;i&gt;,&lt;em&gt;,&lt;u&gt; don't have any equivalence one with another

I find it hard to believe you actually think otherwise.

Stomme_poes · April 7, 2012, 9:02pm

I’ve never heard anything from em and strong tags, and I don’t intentionally disable inflection (I don’t listen that fast).

If I need to say something to screen readers specifically, I call it out (and Google does this too… go to Google main English search with a screen reader and you’ll be warned about the Google Instant (because it screwed badly with a lot of screen readers)) like so:
“Screen reader users: blah blah.”

This avoids the issues inherent with HTML tags specific to browser, OS, geolocation, ability, or hardware types, assuming we want to avoid those.

system · April 9, 2012, 2:20pm

“I hear you loud and clear, Mallory!” LOL

I guess I was trying to complicate things instead. Not a good idea.

Like always, you make complete sense. Thanks.

rguy84 · April 9, 2012, 8:18pm

[QUOTE=itmitică;5097739]I’m not sure what you understand by though.
Semantically, is not to bold text, even though visually it may present itself like that. It appears the auditory effect is also similar to ?[/quote]
I never dug into the semantics of versus . The advocacy of versus was highlighted when I was hitting the two year experience with web development. At that time, I read enough posts about using strong versus b I just accepted it as true, but this was also when the argument for xhtml to be the hot new thing. To answer your question, the only way a screen reader user would know if you used or is to dig through the code.

[QUOTE=itmitică;5097739]And I’d argue that is, in fact, tailor made for screen reader users, as it is the case with (and the two are very different one from another), but I have no real user agents facts to sustain that, while it seems that you have hands on experience, which is better than any theory I might have. [/quote]
The argument I heard back in the day was, was the old school way, and was the improved way. The same goes with and . I would either need to dig through the specs to figure out why. Note in this post and the others in this thread, I only discussed b and strong. Now to a screen reader, and are inflected in somewhat harsh or hard tone; and are announced in a somewhat questioning tone. Which is different than the /.

[QUOTE=itmitică;5097739]Still, semantics are semantics. ,, have no semantics attached to them. and do.[/quote]
I would buy that argument except for the . I am not fully up-to-speed/confortable with HTML5 to argue for it. From the two things I read about , it seems like one of the other nonsense tags that was made up. I will have to either read something from the W3C or talk to a contact I have to grasp the bigger picture of .

[QUOTE=itmitică;5097739]That’s why I’m lost completely about you seeing as parenthesis…
To me it’s very clear that your example of using is <wrong>, while mine is <right>. :)[/quote]Now you just reversed your argument, and made it null. One way of reading this is by looking at a page (not a page source) you can correctly tell when somebody uses versus . If you can, please tell me how because with my ~13 years of being a developer, and look exactly the same to me.
Re paranthesis, I point to your statement:

What I’m proposing is a different thing all together. The text I’d apply to will be added text, meaning the content makes sense completely without it. Probably the missing link to the article has added some confusion in our talk.

The link has nothing to do with it. The “The text I’d apply to will be added text, meaning the content makes sense completely without it.” line is basically the definition of parenthesis usage in the English language :). If you want to add additional words in the form of details to a sentence, you wrap the words in parenthesis…

doesn’t have an equivalent in 
Correct, cause is considered dead and replaced by aka you shouldn’t be using if you are using post-HTML 4.0 (or 4.01 I forget which) and XHTML1.0 or 2.0 DOCTYPEs.

,,,, don’t have any equivalence one with another

I find it hard to believe you actually think otherwise.
Check the specs replaced and replaced . != && != != .

system · April 9, 2012, 8:32pm

OK. A rather long argument.

Except I don’t agree with you at all on the “ replaced and replaced ” part.

You’re only talking visual styles they have in common. Yes, and and and share the same visual default style. But here is where the resemblance stops.

and are meaningless pure decorative elements.

and have very well defined semantic meaning, each.

Check for yourself.
http://developers.whatwg.org/text-level-semantics.html#the-b-element

The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.

The following would be incorrect usage:

WARNING! Do not frob the barbinator!

In the previous example, the correct element to use would have been strong, not b.

is a little different from , being

for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood

while being

a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name in Western texts.

but I wouldn’t say that became and became since
http://developers.whatwg.org/text-level-semantics.html#the-i-element

Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term.

Stomme_poes · April 10, 2012, 8:57am

That’s sorta what people were saying back in the day, but that view is indeed outdated. Back in the days of tags, and were used for importance and emphasis, so when they wanted to encourage developers to use and , indeed it was time to replace a lot of b’s and i’s with strong and em.

But and were never formally deprecated because of the typographical reasons for bold and italic text… text you would not speak out any differently from surrounding text.

So today, it’s this: use strong for important/notable text, use em where you’d speak out emphasis, use b and i for things like ship names, book titles, species names and other Latin/Greek words, foreign words (it’s okay to use i for a foreign word and then conveniently you can throw the lang attribute on it), and interviewer/interviewee names in a written interview.

is for actually highlighted text. This has a few very specific applications, the most famous/well-known one being, when you do a search for a word in a search engine, you’ll notice the document you read will have background highlighting on the term you sought in the document. So, it’s a purely visual method of bringing a sought-after word to the user’s attention. It’s an extra, since you could also just CTRL-F for your search term too.

Another use of is when you are quoting another source, and highlighting some portion to make a point. Sometimes you just want to emphasis it with or maybe tags, but other times you’re pointing out a particular wording for skimmers. For example, when I made my rant about webkit-only prefixes, I had quotes of some W3C discussion. http://stommepoes.nl/webkitprefix.html (not styled yet, so this is default styling) Again, it’s simply to visually call attention to something in a way that doesn’t imply emphasis or special importance, for people who visually skim.

rguy84 · April 11, 2012, 1:51pm

You really should use the W3C over WHATWG.org. WHATWG is a spin off group Hixie made when he was mad at W3C…

Anyway, I get it now the difference between strong vs b. That doesn’t change my original point that in my experience, to a screen reader strong and b were announced the same (JAWS 5-10/11). So using strong currently wouldn’t set off anything special, aka screen reader only. A chime or something would need to be sounded. Then again there is issues with that. First more advanced users read at a crazy rate, so the chime would need to happen at the beginning of the line/paragraph to get around potential lag issues. Second, infomation overload. Third, users who use a Braille display, may not be able to hear, as they are Deaf-Blind, or don’t have audio available at that time, so what would be an acceptable way to denote the specialness? In Braille, there are a few ways to denote bold: two underscore characters (using dots 4-5-6 in a single cell); or the combination of cells 4-5-6, 4-6, 4-6. So you would need to spell out stuff like Mallory said.

Gotcha, I figured in those cases they just used a formatted span…

system · April 11, 2012, 2:05pm

You mean to say:

You can also look at the W3C, if you like.

right?

I’m more into WHATWG, what can I say?

<hr>

Yes, Mallory did a great job talking some nonsense out of me. Glad we now both understand the same thing when talking about though.

Stomme_poes · April 11, 2012, 7:08pm

Well, here’s the thing, if I understand it correctly:
in 2000, the W3C was done with HTML. Finished. The new sexy cousin was XHTML and XML and this would be the future, a pristine XHTML2 without retardation on the part of authors or WYSIWYGs being rendered, forcing errors to be fixed.

Hixie (Opera, and then Mozilla, and finally Apple) thought HTML was already a well-established lingua franca for the web and it made more sense to improve it. They started with forms because HTML forms suck while XForms rule. They then said “the web is increasingly becoming applications rather than linked text documents” and because HTML (nor necessarily the upcoming XHTML2) reflected that, they decided to just continue developing HTML.

They went to the W3C in 2004 and asked the W3C to reconsider letting HTML die. The W3C was not interested. So the WHATWG was just some rebel group doing their thang.

At some point when the W3C decided XHTML2 wasn’t going to happen, they figured if there’s going to be a new HTML beyond version 4.01, they needed to be involved because what was HTML without the W3C?? First thing they did was copy what the WHATWG had started with, and since then the two have diverged. Even if you stick with just the W3C specs, for developing things like canvas API etc you know they’re going to borrow too heavily from each other and browser vendors determine what goes in the spec at some level (if it ships, it’s in), so W3C can have plenty of specs that aren’t “real”. In other words, both specs need to be looked at.

I thought both agreed on the “new” meanings of b and i. Though the redefinitions seem kinda silly to me. They were fine the way they were before.

kohoutek · April 12, 2012, 3:44pm

Everyone, please keep the discussion civil. No personal attacks.

It’s a great thread and it should remain that way. I’ve removed posts that don’t add to the discussion in any shape or form.

Danke.

Stomme_poes · April 12, 2012, 8:51pm

wut?

system · April 12, 2012, 9:29pm

Yeah Mallory, don’t play the innocence game. You better listen to Maleika. Behave!

“lingua franca” and other six-letter words is not something we tolerate here!

Young girls these days…

<hr>

Oh, and me and some other guy we were just… Well, it’s better if I just show you:

kohoutek · April 12, 2012, 11:03pm

Like I said in my post above, I’ve deleted the posts that were irrelevant, the warning doesn’t pertain to your last post.

All good. Please continue the conversation.

system · April 13, 2012, 7:07am

^ Don’t trust her Mallory. She’s out to get ya’!

You’ll notice, to throw you off, she’s randomly signing off as some dude called “Danke”. :feeshee:

http://www.myspace.com/video/chari/here-feeshee-feeshee/4329014

kohoutek · April 14, 2012, 9:27am

No. Danke means thanks in Swahili.

Stomme_poes · April 14, 2012, 11:48am

Asante, asante sana!

Topic		Replies	Views
<strong> or <b> HTML & CSS	48	3284	November 14, 2011
In praise of the <B> tag HTML & CSS	74	3205	January 15, 2011
Frequently Asked Questions about HTML HTML & CSS	12	24428	January 30, 2007
Best way to style Inline Text? HTML & CSS	15	1586	November 3, 2011
<p> vs <span> HTML & CSS	102	43814	August 7, 2009

Invisible Content (by CSS) Just for Screen Reader Users

Related topics