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 <strong>. 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?
I think you are asking if a <strong> 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 <strong> 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.
It’s not from a source, it’s something I thought of.
I’m asking that if <strong> was used, could it suggest <strong>even more</strong> 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 <strong> element fits well, where as with phrases like below
<strong>You are here: </strong>,
<strong>Choose from the following links: </strong>,
it makes no sense to use <strong> 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 <strong> elements (like are those in the next phrase). But if it’d follow a pattern of <strong>odd use</strong>, it’d be easy to spot as an <strong>odd use</strong>, 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: <i>, <b>. 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 <strong>United States of America</strong> must comply with Section 508
is correct use for strong, for several reasons. I see a <b> element there, a <mark> element perhaps.
This is a legitimate use of <strong> for me:
All federal government agencies in the United States of America <strong>must comply</strong> with Section 508
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 <strong> was used, could it suggest <strong>even more</strong> 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: <i>, <b>. 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 <b> element there, a <mark> element perhaps.
To AT, like browsers/HTML <strong> and <b> 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 <strong><b><i><em><u> 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 <span> and apply CSS.
This is a legitimate use of <strong> for me:[…]
This is where this thought fails though. This could be extrapulated to making <strong> 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.
I’m not sure what you understand by <strong> though.
Semantically, <strong> is not to bold text, even though visually it may present itself like that. It appears the auditory effect is also similar to <b>?
And I’d argue that <strong> is, in fact, tailor made for screen reader users, as it is the case with <em> (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. <b>,<i>, <mark> have no semantics attached to them. <strong> and <em> do.
That’s why I’m lost completely about you seeing <strong> as parenthesis…
To me it’s very clear that your example of using <strong> is <wrong>, while mine is <right>.
What I’m proposing is a different thing all together. The text I’d apply <strong> 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.
<strong> doesn't have an equivalent in <b>
<mark> is not the same with <strong>, <b>, <i>, <em>, <u>
<strong>,<b>,<i>,<em>,<u> don't have any equivalence one with another
I find it hard to believe you actually think otherwise.
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.
[QUOTE=itmitică;5097739]I’m not sure what you understand by <strong> though.
Semantically, <strong> is not to bold text, even though visually it may present itself like that. It appears the auditory effect is also similar to <b>?[/quote]
I never dug into the semantics of <strong> versus <b>. The advocacy of <strong> versus <b> 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 <strong> or <b> is to dig through the code.
The argument I heard back in the day was, <b> was the old school way, and <strong> was the improved way. The same goes with <i> and <em>. 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, <strong> and <b> are inflected in somewhat harsh or hard tone; <i> and <em> are announced in a somewhat questioning tone. Which is different than the <strong>/<b>.
I would buy that argument except for the <mark>. I am not fully up-to-speed/confortable with HTML5 to argue for it. From the two things I read about <mark>, 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 <mark>.
[QUOTE=itmitică;5097739]That’s why I’m lost completely about you seeing <strong> as parenthesis…
To me it’s very clear that your example of using <strong> 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 <strong> versus <b>. If you can, please tell me how because with my ~13 years of being a developer, <strong> and <b> 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 <strong> 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 <strong> 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…
<strong> doesn’t have an equivalent in <b>
Correct, cause <b> is considered dead and replaced by <strong> aka you shouldn’t be using <b> if you are using post-HTML 4.0 (or 4.01 I forget which) and XHTML1.0 or 2.0 DOCTYPEs.
<strong>,<b>,<i>,<em>,<u> don’t have any equivalence one with another
I find it hard to believe you actually think otherwise.
Check the specs <strong> replaced <b> and <em> replaced <i>. <strong> != <em> && <strong> != <em> != <u>.
Except I don’t agree with you at all on the “<strong> replaced <b> and <em> replaced <i>” part.
You’re only talking visual styles they have in common. Yes, <strong> and <b> and <em> and <i> share the same visual default style. But here is where the resemblance stops.
<b> and <i> are meaningless pure decorative elements.
<strong> and <em> have very well defined semantic meaning, each.
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:
<p><b>WARNING!</b> Do not frob the barbinator!</p>
In the previous example, the correct element to use would have been strong, not b.
<i> is a little different from <b>, <b> being
for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood
while <i> 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.
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.
That’s sorta what people were saying back in the day, but that view is indeed outdated. Back in the days of <font> tags, <b> and <i> were used for importance and emphasis, so when they wanted to encourage developers to use <strong> and <em>, indeed it was time to replace a lot of b’s and i’s with strong and em.
But <b> and <i> 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.
<mark> 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 <mark> is when you are quoting another source, and highlighting some portion to make a point. Sometimes you just want to emphasis it with <em> or maybe <strong> 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.
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…
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.
