strong/em vs. b/i respectively

[SEFL]

Since this is a coding "best practice" issue and it's been bugging me for a while now, I'd figure I would post it here.

Why does the W3 recommend that <strong> be used instead of <b> and <em> be used instead of <i>? I can't see it being a question fo semantics, because <em> and <i> are both abbreviations. And I can't see it being used to make code more readable, since <strong> and <em> create slightly more code.

I haven't yet seen a good answer for this question, and Matt Cutts said himself (after verifying with a Google tech) that <b> and <strong>/<em> and <i> don't make a difference in terms of the Google algo (although it may have an effect on Yahoo!/MSN, I don't know). So why is this so important? I really don't get it.

Thanks.

[JohnC]

Personally I think that all 4 will work for a very long time in browsers. So from a purely functional POV I don't think it makes any difference at all.

As to why W3C prefers one over the other, they made a choice and are sticking with it. That about as close as I can come .. :)

Good question though ...

[Connie]

Good question. I wonder if it could have something to do with xhtml>? <b> will validate using HTML 4.01. Will bold validate using xhtml?

[WebSavvy]

<b> and <i> are both to become deprecated tags. Using <strong> and <em> are the tags that will be cross-browser compatiable as browsers move forward to embrace the new standards in HTML (e.g., XHTML)

When validating a site for WAI-AAA if <b> and <i> are used, the site does not pass. You must use <strong> and <em>

[Irony]

The screen readers, AFAIK, can read <strong> and <em> correctly, but ignore <b> and <i>.

[JohnC]

Very good reasons for picking <strong> and <em> girls. :)

Any idea "why" they are on the chopping block. What was the reasoning behind the change? I am sure WAI-AAA and screen-readers are just staying compliant, but why did the depreciation happen in the first place? Just curious if anyone knows.

[WebSavvy]

Screen readers are browser dependent (not independent). So therefore, as the web pushes to become more accessible, the standards for such have to change in order to accommodate this.

This means that anything any browser will no longer support (as in not backwards compatible) it then becomes a deprecated element as more functional (supported) markup takes its place.

[Blue]

FYI:

Depreciated is the incorrect term here.

Deprecated would be the correct term.

[ihelpyou]

Thanks Scholar John. :smart:

[JohnC]

LOL .. I blame Google Spellcheck .. hehe

[WebSavvy]

lol thanks Blue ... didn't even notice that "i" snuck in there ;)

[Blue]

Yep. I can be sneaky sometimes. :rolleyes:

[SEFL]

Originally posted by Connie
Good question. I wonder if it could have something to do with xhtml>? <b> will validate using HTML 4.01. Will bold validate using xhtml?

Yes. That's part of what led to my question.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.greenbuildingfest.com%2F <-- valid XHTML with bold tags.

It doesn't really make sense to me from an accessibility standpoint either. It just seems to me like a tag is being phased out. Ah well. I guess I'll have to learn to deal with it from now on. I really don't like it, but can't do much about it.

[g1smd]

A screen reader cannot make the spoken words bold or italic, but it can add emphasis or use a stronger intonation.


Matt Cutts confirmed (a few days ago) that <strong> and <em> are treated the same as <b> and <i> by Google in their page analysis.

[WebSavvy]

Hey Adam, here's one for you: :D

This is a test page:
http://www.websavvy.cc/tab-test.htm

XHTML 1.1 valid
Web Accessible (WAI-AAA)

Now, check the page using Bobby:
http://webxact2.watchfire.com/

Note, under the ::Accessibility:: tab from the top menu, it shows

Priority 1 (A) with 0 Errors / 0 Instances
(but shows 3 warnings / 3 instances)

Priority 2 (AA) with 0 Errors / 0 Instances
(but shows 8 warnings / 8 instances)

Priority 3 (AAA) with 0 Errors / 0 Instances
(but shows 8 warnings / 8 instances)

This page complies with all of the automatic checkpoints of the W3C Web Content Accessibility Guidelines. However, it does not comply with all of the manual checkpoints, and requires manual verification.

To me, their reports send mixed messages. The page doesn't contain anything to flag a manual noncompliance so it should show this as passed (but doesn't).

I know the page is valid, and passes priority 3 checkpoint.

However, to someone that's new to all of this, it's confusing because of the mixed signals (conflicting points) that the verification report comes back with.

They automatically list those same warnings and instances for all three checkpoints even when the site doesn't trip any flags.

The way the tool is set up, it currently does not give a report where 0 warnings / 0 instances are found.

It's much better to use the verification tool provided here:
http://www.contentquality.com/

[Dave Hawley]

I haven't yet seen a good answer for this question, and Matt Cutts said himself (after verifying with a Google tech) that <b> and <strong>/<em> and <i> don't make a difference in terms of the Google algo (although it may have an effect on Yahoo!/MSN, I don't know). So why is this so important? I really don't get it.In their prime SE yes, but what about their new Beta accessible search?

Personally, I doubt it is "important". But, if you are going to validate you should, I guess, do as w3c states. Don't want to be one of those many sites that display the w3c logo when the page doesn't in fact validate ;)

[pageoneresults]

<b> and <i> are both to become depreciated tags. Using <strong> and <em> are the tags that will be cross-browser compatiable as browsers move forward to embrace the new standards in HTML (e.g., XHTML)I won't get into the real nitty gritty stuff on this but <b> and <i> are presentational elements while <strong> and <em> are semantic elements that have meaning.

I've been using all four for the past couple of years. I use <b> and <i> when I want a presentational effect and then <strong> and <em> when I want what's between those elements to have semantics along with the presentational effect. ;)

[ihelpyou]

I have no idea what you mean, but I did notice this:

http://www.ihelpyou.com/forums/showthread.php?s=&threadid=22949

:)

[pageoneresults]

Arrrggghhh... I have no idea what you mean, but I did notice this:I've got to take that out of my profile. :)

45 down, at least another 45 to go.

[g1smd]

A screen reader cannot make the spoken words bold or italic, but it can add emphasis or use a stronger intonation.

That is what is meant by presentational versus semantic markup.

[WebSavvy]

Edward (quoting me) -- I already knew the what the differences were as g1 has also just stated.

Try using a screen reader (I have to) and you'll hear what we mean.

[Quadrille]

Instead of pushing <STRONG>, it would have been much more elegant (and much less work) to have said to screen readers "hey guys, where you see <B>, take that as a semantic element, would you?" - rather than force every web page to be rewritten to achieve the same effect.

99.99999% of <b> will be replaced by <strong>.

Similarly, they could have decided "where you see <i>, give it emphasis, why dontcha" - but no; introduce new terms which will be almost invariably a straight one-for-one, and force every single web page to be rewritten.

A victory for geekdom, if ever there was one.

[g1smd]

He shouted loudly at me, his words were bold and the important bits he said in italics.

[Dave Hawley]

He shouted loudly at meAs apposed to shouted quietly :)

RE: presentational versus semantic markup.

But <b> and <strong> both present the same. So what is <b> for then if the standard by definition (not usage) is <strong>.

[g1smd]

You can only do bold and italics with something that is written or printed.

[Dave Hawley]

Yes I know that :rolleyes:

I don't get the statement below to which you appeared to agree with;
I use <b> and <i> when I want a presentational effect and then <strong> and <em> when I want what's between those elements to have semantics along with the presentational effect.So why not ONLY use <strong> and <em> as their "presentational effect" is the same as <b> and <i>?

[pageoneresults]

So why not ONLY use <strong> and <em> as their "presentational effect" is the same as <b> and <i>?They have different meaning. Use the Screen Reader example above. <b> and <i> have no meaning as they are strictly for presentational markup. But, <strong> and <em> are semantic markup and provide meaning. In the Screen Reader example, elements wrapped in <strong> are pronounced louder. Elements wrapped in <em> are pronounced with emphasis.

I surely wouldn't want my 11px/12px <b> navigation links to be shouted at someone using a Screen Reader. ;)

In theory, <b> and <i> should not be used. Anything needing bold or italics should be done via a style wrapped in a <span> or directly from the style sheet (font-weight:bold). But, that's in a perfect world and we are nowhere close to being perfect. :)

If you ever plan on validating to the WAI Triple A level, you'll need to really hunker down on semantic markup and structure.

[Quadrille]

Originally posted by pageoneresults
I surely wouldn't want my 11px/12px <b> navigation links to be shouted at someone using a Screen Reader. ;)So why make them bold?

Why would you be sending mixed messages to different user groups?

[pageoneresults]

So why make them bold?At the time, that was what I knew. These days, I'll typically use my external style sheets to control just about everything that is presentational.

Also, it's always been much easier to click that <b> button and/or Ctrl + B to bring visual emphasis to text. I grew up in the WYSIWYG generation. :)

[Dave Hawley]

So there is no point in using <b> and <i>.

[pageoneresults]

So there is no point in using <b> and <i>.lol! I think you might get some arguments there. Particularly from the old school crowd as <b> and <i> are the shortest route to what they want to achieve. And, many are using WYSIWYG and that would be the default element wrapper when pressing the B and I buttons.

[pageoneresults]

It really is a non-issue these days as presentational markup is becoming less utilized and those who are thinking ahead have already started down the semantic trail.

If you read the various patent applications out there and look at the companies Google has bought and the others too, semantics are part of the algos. They have to be. There's a lot of information out there that relies on semantic indexing for proper classification, etc.

I've been experimenting with this over the past couple of years and it's really hard to pinpoint how effective "just semantics" are. I can tell you that my portfolio of sites along with my client sites remain unaffected by anything the major three are doing to "mix things up a bit". There's a bit more to it than "just semantics" too. Site architecture, document structure, source ordered content, etc.

[WebSavvy]

Originally posted by pageoneresults
If you ever plan on validating to the WAI Triple A level, you'll need to really hunker down on semantic markup and structure.
That's what I did. :)

Wait'll you see it, Edward. Every page in websavvy meets WAI-AAA and section 508 (wasn't easy either).

The new stuff will be up shortly. Right now I'm just down to the last few details.

:)

[Quadrille]

Seems to me that when 'depracated' becomes 'banned', everyone who knows how to 'find and replace' will substitute strong for bold, em for i.

I do not believe the semantic versus presentation arguments will be raised, let alone heard.

And I regret to say I see no reason to tell them they are wrong - and that's after reading this thread several times. :(

[pageoneresults]

Seems to me that when 'depracated' becomes 'banned', everyone who knows how to 'find and replace' will substitute strong for bold, em for i.Hehehe, first people need to know what the term deprecated means. Then they need to know which elements are deprecated. It's not going to happen anytime soon. Heck, Google still uses <font> tags. ;)

[Quadrille]

I think most of them know what 'banned' means ;)

[SEFL]

Okay...so this is starting to make sense to me, the whole screen reader thing that is.

But let's say you have a CSS class that you use repeatedly, and the CSS class has font-weight bold in it. e.g.

.boldandblue {
color: blue;
font-weight: bold;
}

Or even better, font-weight 900.

How does the screen reader interpret that?

[WebSavvy]

Adam, I have fonts set to bold, and some set for font-weight:700 and my screen reader does not shout them when reading back.

You can download JAWS or ReadPlease (they're both free) and check your site with them.

:)

[srikanthsh]

But let's say you have a CSS class that you use repeatedly, and the CSS class has font-weight bold in it. e.g.
...
...
Or even better, font-weight 900.


Logic. I like it.

[Connie]

But let's say you have a CSS class that you use repeatedly, and the CSS class has font-weight bold in it. e.g.
From what I understand a screen reader will ignore anything bold.

I think a better question would be:

I have a css class strong. Will the screen reader understand the css class and pronounce the words a little louder? Or, does the <strong> tag actually have to be on the page?

[pageoneresults]

Or, does the <strong> tag actually have to be on the page?It would have to be on the page. The <strong> element provides the semantics. <span class=""> provides no semantics and is strictly for styling purposes where semantics are not applicable (when it is strictly for visual presentation).

[WebSavvy]

<strong> and <em> must be present in the body copy for the screen reader to apply meaning to it.

Using strong in a CSS class is not valid CSS.

The weight of the font is what we're referencing in a CSS class, therefore the font weight can be set as bold or can be set as a weight integer between 100-900.

[Connie]

That's what I thought but wasn't sure.

So the emphasis upon using an external style sheet really has nothing to do with accessibility? A style sheet is only about presentation. Is that a correct assumption?

I think this thread is the first time I have ever read about a distinction between semantics and presentation.

[WebSavvy]

Yep, stylesheets are all about presentation and nothing more.

I personally don't add any classes to my paragraphs or fonts (in this new layout).

I assign a class to the block level tag, as an id class # and then apply class rules to that class id #

Example, let's say I have <div id="main">

In my CSS file it'd look like this:

#main {
font:bold 85% verdana, serif;
}

I can add other classes to affect elements living inside that block by doing this:

#main p {
text-indent:8px;
}

Then any paragraph living inside that <div id="main"> class, will be indented by 8px.

This way the markup is clean, and it's just a normal <p> instead of <p class="foo">

This way presentational elements are kept to a minimum within the body copy HTML markup.

[srikanthsh]

So the emphasis upon using an external style sheet really has nothing to do with accessibility?
Have never done, but I think stylesheet can be different based on the output device.. screen, print, screen reader? etc.. But, dont know about other devices as i have worked for the Web only. Though did few things for print media, but not using stylesheets.

[WebSavvy]

From one of my favorite haunts, here's an informative article about the different mediums stylesheets can be classified for:

http://meyerweb.com/eric/articles/webrev/200001.html

[Connie]

Well just read my home page using a screen reader. Interesting to say the least.

On the semantics issue. Reading the SR introduction it did not emphasize words that were bolded in the introduction. I would assume they used strong at that point.

Only the anchor text of hyper links is read. Do all links have to be placed in [square] brackets? If that is the case how does someone using a reader actually click on a link?

And should the link be [http://www.somesite.com] or [<a href="http://.www.somesite.com">anchor text</a>]?

One thing that really surprised me was the fact that tables were ignored. The screen reader only read text. I always thought tables were a problem for screen readers.

Or more appropriately I suppose a problem for people using a screen reader.

[WebSavvy]

People using screen readers hear the data being read back. Links should be separated either by enlcosing them in brackets [ ]
or by using a pipeline at the end of the anchor </a>|

What I did with mine is, set a class called .pipe as follows:

.pipe {
font:normal 95% verdana, serif;
color:#000;
background-color:#fff;
display:none;
}

Then you can do this:
<a href="/">Text</a><span class="pipe">|</span>
All links should use tabindex, and accesskey (which is how people using assistive technology access links).

The above link, properly coded would look like this:
<a title="Go to Foo - accesskey:a" href="/foo.htm" tabindex="1" accesskey="a">Foo</a><span class="pipe">|</span>
Having an accesskey applied to a link, enables the user to "click" through to the linked page simply by using their keyboard.

[g1smd]

Semantics: that is the comment that I have been making for several years: "make your pages out of headings, paragraphs, lists, tables and forms".

As for accessibility, you'll need [<a ... > ... </a>] I think.

[Connie]

Deb what your describing is not according to ReadPlease. Unfortunately they did not go into much detail in the intro.

Your example is still using a style sheet which has been my understanding from this thread that screen readers ignore a style sheet.

I think G1 may have answered my question.

When I get time I will figure this out, but even the couple of links that were read (by the screen reader) as links in the intro did not provide a way to click on them.

The person would have had to type those links.

[WebSavvy]

Connie, using accesskey makes the link accessible via keyboard. The screen reader cannot click links.

In order for links to be "clicked" it has to be accessible via a mouse or keyboard.

Here's some info on this for you:
Using accesskey attribute in HTML forms and links (http://www.cs.tut.fi/~jkorpela/forms/accesskey.html)

:)

[Connie]

Thanks Deb I will look at that. From my POV a screen reader is worthless if a person can't easily access the links on a page.

I would have thought a screen reader would have provided more information about that rather than a blanket statement that e-mail links and html links could be read if enclosed in [ ].

I'm really interested in this or I would not have downloaded a screen reader and be asking so many questions.

[Blue]

Try surfing for a day with your eyes closed.

[Connie]

Blue I think you missed my point, yet that is exactly my point.

What good does it do a surfer to end up on one of my pages, and then there is no way to get to the next page, or order (if that is what they want to do.

I would think that kind of information would be in the intro pages of the screen reader.

[WebSavvy]

Connie, a screen reader will read the accesskey out loud. If you've assigned accesskeys to your links and inserted that accesskey info into the ANCHOR TITLE tag, the screen reader will read it out loud.

So, if I went to your site and found a link to "Kitchens" it would be like this

<a title="Kitchens - (accesskey:K)" href="/kitchens.htm" tabindex="1" accesskey="K"><u>K</u>itchens</a><span class="pipe">|</span>

I'd hear:

Kitchens (stop) accesskey:K (stop)

I'd then know that by using my keyboard ALT+K
-- I can go to the "kitchens" URL on your site.

When you use accesskeys in links it creates a shortcut on the keyboard that acts the same as a mouse clicking the link to deliver the user to that page.

Not sure if I explained this well enough ... but I think you get the general idea.

Just a FYI, not all screen readers are created equally.

Try using JAWS and you'll notice a difference between JAWS and ReadPlease.

[Connie]

Deb I think I'm getting the general idea. By access key your talking about keyboard commands? I think.
Just a FYI, not all screen readers are created equally.


Try using JAWS and you'll notice a difference between JAWS and ReadPlease.

Of course this raises a different question. Do pages have to be designed for each screenreader?

Are screenreaders like browsers? What works in one may not necessarly work in another.

[WebSavvy]

A screen reader uses whatever browser it is that you're using. Since you're not worried about how it's going to visually display (since it's for a text reader) it doesn't matter which browser is used.

Yep, I'm talking about keyboard commands. They're called "accesskeys" (shortcuts).

You can assign the same accesskey to any number of links on a page (all links must have one).

It makes more sense to set the accesskey for each link to whatever the first letter of the first word is in that link.

Example:

Kitchen
Spice Racks

The bolded underlined letters are the visual clue that those are the accesskeys to be used for those links.

The rest of the hyperlinked word would be normal font weight and would not be underlined.

Now, you're not going to run through your site and add <b><u></u></b> to every single first character of every single link in your site. That would be waaaaay too much work.

I played around with CSS for about 3 days trying to figure out an easy way to do this, and this is what I've come up with so far. I'll post it here in case anyone else wants to use it too. :)

CSS CODES:

<style type="text/css">
<!--

body {font:normal 16px verdana, serif; color:#888;}

#content {
font:normal 96% verdana, serif;
color:#aaa;
}

#content li {
list-style-type:none;
float:left;
line-height:100%;
}

#content li:first-letter {
font-weight:bold;
border-bottom:1px solid #aaa;
}

#content li a {
color:#ce0000;
margin-right:2px;
margin-left:2px;
text-decoration:none;
line-height:100%;
}

//-->
</style>


BODY COPY:

<div id="content">
<p>
<ul>
<li><a title="Cleveland" href="/foo.htm" tabindex="1" accesskey="C">Cleveland</a></li>
<li><a title="Boston" href="/foo.htm" tabindex="2" accesskey="B">Boston</a></li>
</ul>
</p>
</div>

The above produces the following:
Cleveland Boston

The first:letter rule can only be applied to block level elements.

So far, this works very well except that I can't add an
a:hover
to the anchor color

If you add one, it makes the underline disappear from under the first letter once it's hovered over.

If anyone else can figure out a way to add that in please do and post it here!

[Connie]

Thanks for the added information Deb.

Time to start playing with a webpage to see if I can get it to work right.

[SEFL]

Man, I'm glad I brought this up. This may be one of the most insightful and informative discussions I've seen online...ever. Lots of good stuff to pick apart.

[Connie]

It's been an enlightening thread Adam. I've been wondering about screen readers for some time.

Don't know that I could ever get it working with my shopping cart.

[WebSavvy]

Connie, you could easily make your shopping cart, web accessible. :)

The photo's on your site can use longdesc="" (which is known as long description) to describe the photo for a screen reader.

Not all screen readers support longdesc, so you have to add a description link (d-link) next to the photo.

How this is done is:

<img src="/images/photo.png" alt="Image Description here" title="Image Description here same as ALT TEXT" longdesc="#spice_racks"><a href="#spice_racks">d</a><span class="pipe">|</span>

Then, on your page where the copy is written about the spice rack image you're showing, you'd insert this just above it:

<p><a id="spice_racks"></a></p>

Now, since this would all destroy the look of the site for sighted people, we'll add the pipe class to it like we did for our anchors and we'd then have this:

<img src="/images/photo.png" alt="Image Description here" title="Image Description here same as ALT TEXT" longdesc="#spice_racks"><a class="pipe" href="#spice_racks">d</a><span class="pipe">|<span>

<p class="pipe"><a id="spice_racks"></a>


This way everything looks good to sighted visitors and helps those with low vision or blindness.

I've spent a lot of time doing a lot of research and trying lots of ways to do things more effectively with regard to accessibility, and as a result have been able to bring my site up to par. :)

[Connie]

Deb you only taking into consideration the html pages. Of course a order would have to start there, but the cart is written in pearl. I think there would have to be a lot of changes to the pearl code for someone using a screen reader to fill out the information on the actual order pages of the cart.

What I'm thinking about doing is creating pages for screen readers. Putting them in a separate folder and disallowing the SEs from that folder. Then add one link at the top of each page to the home page in that folder.

For anyone who is interested here is a demo download of Jaws.
http://www.freedomscientific.com/fs_downloads/jaws.asp

I'm downloading Jaws now. I will compare it to ReadPlease when I get it downloaded. (2hours and 24% downloaded)

A couple of questions, and there will be more.

Since screen readers ignore <b> and <u> what is the purpose of adding <b> or <u>. I understand that is a visual thing so that someone knows you have an access key. On the other hand if the screen reader ignores visual tags, how do they help someone using a screen reader?

[Blue]

The short answer is, they don't. They are for visual media only.

[SEFL]

#content li:first-letter:hover maybe? (Never tried this.)

[WebSavvy]

Nope. Tried that, and a few other ways. So far no joy. :(

[WebSavvy]

For anyone that might be interested, this is a really nice disability resource site and they provide a list of software sites that offer screen reading software (many are free):

http://www.ebility.com/links/software.php

[g1smd]

Pseudo-classes currently only work for anchors.


I think that CSS3 extends them to work with all other tags.

[WebSavvy]

If anyone's interested, I've figured out how to make it work with a hover on anchor (which is required in WAI-AAA guidelines)

Tested on FF -- If any of you want to test it in other browsers please indicate which ones, and how it displayed. Thanks!

CSS Code

<style type="text/css">
<!--

body {font:normal 16px verdana, serif; color:#888;}

#content {
font:normal 96% verdana, serif;
color:#000;
}

#content li {
list-style-type:none;
float:left;
margin-right:2px;
margin-left:2px;
}

.content:first-letter {
font-weight:bold;
border-bottom:1px solid #aaa;
}

a.content {
color:#ce0000;
text-decoration:none;
}

a.content:hover {
color:green;
text-decoration:underline;
}

//-->
</style>

BODY HTML

<div id="content">
<p>
<ul>
<li class="content"><a class="content" title="Cleveland" href="/foo.htm" accesskey="C" tabindex="1">Cleveland</a> »</li>
<li class="content"><a class="content" title="Boston" href="/foo.htm" accesskey="B" tabindex="2">Boston</a></li>
</ul>
</p>
</div>

The preceding will produce the following:
Cleveland » Boston

On hover will produce the following:
Cleveland » Boston

[g1smd]

There is usually no need to repeat the class name on the anchors:

<a class="content" ...



The anchor text can be styled using:

#content p ul li a { the style ; }

to reach into the inner nested tags.

[WebSavvy]

Normally, yes, it would work. However with using pseudo-selectors to change the first letter, an anchor doesn't inherit the class unless it's specifically told to do so.

The first letter in the class to be affected resides inside <li>

Trust me, I've tried this every way imaginable and this is the ONLY way I've been able to get it to work without the underline below the first letter disappearing, and still having the anchor hover.