W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2018

Re: Bold vs Strong

From: David Ashleydale <dashleydale@gmail.com>
Date: Mon, 6 Aug 2018 09:55:53 -0700
Message-ID: <CAGELhn=H=rET1q78oVUtH-t-CjUo7-fx7zoiSbsHShT=aktuWA@mail.gmail.com>
To: Jonathan Avila <jon.avila@levelaccess.com>
Cc: "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
My understanding has always been that b/i are for visual decoration only,
and that strong/em are for actual emphasized content.

For example, I saw a case where a web designer wanted to use a certain font
family, but didn’t like the thinness of some of the letters. So they made
those certain letters bold. I think that’s a clear case where <b> should be
used — screen reader users would find it super annoying to have those
letters announced in some way. That is purely visually decorative.

<strong> should be used when the emphasis changes the meaning of the
sentence. Take these two sentences, for example:

<strong>Mary</strong> had a little lamb. (Mary, not Tom, had the lamb.)
Mary <strong>had</strong> a little lamb. (She had it once, but she doesn’t
have it now.)

That’s the intention of this rule, but I acknowledge that in practice today
it doesn’t work. You would expect screen reading software to somehow
indicate emphasized words by default by saying them slightly louder like we
do with our voices. However, even if you did get your screen reader to do
that, there are so many misuses of strong on the internet, that it would
probably become quite annoying.

Still, my opinion is that web developers should still strive to do it
correctly in the event that someone figures out a way to make it work
correctly in the future.

Thanks,

David
On Mon, Aug 6, 2018 at 9:33 AM Jonathan Avila <jon.avila@levelaccess.com>
wrote:

> I would agree that if strong versus bold were used correctly then users
> who use custom stylesheets would be able to overwrite the 2 correctly.  For
> example, a b element could used within a heading because the heading
> already communicates the structure.  However, for a passage that was bolded
> to communicate strong semantics then the strong element would be the
> correct semantics with my custom CSS that I might want overridden.  So not
> all uses of b are problematic -- only the ones that are used to communicate
> semantic information that is not communicated another way.
>
> I would consider use of B or I a guided automatic or potential automatic
> test because their use relies on human or AI judgement
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access
> jon.avila@levelaccess.com
> 703.637.8957 office
>
> Visit us online:
> Website | Twitter | Facebook | LinkedIn | Blog
>
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
>
>
> -----Original Message-----
> From: Michael A. Peters [mailto:mpeters@domblogger.net]
> Sent: Monday, August 06, 2018 11:18 AM
> To: w3c-wai-ig@w3.org
> Subject: Re: Bold vs Strong
>
> One of the reasons I like strong / em is that I can use the semantic
> strong / em and then use css to make the visual distinction different
> that b / i when needed.
>
> I rarely do that but for example - in an aside I normally have the the
> text italicized already so in an aside, I tend to use css to use more
> font weight with the em tag and both more font weight and underline with
> the strong tag.
>
> Technically can do that with b / i tags as well - but using the CSS to
> override what tags historically mean isn't something I like.
>
> But em / strong have semantic meaning and the display of bold / italic
> is just a default intended to be altered as needed.
>
> Screen readers may not currently distinguish between b / i and strong /
> em but that doesn't make the difference meaningless.
>
> On 08/06/2018 07:24 AM, Pyatt, Elizabeth J wrote:
> > I concur with Mohith.
> >
> > Because most screen readers and visual browsers treat STRONG/B
> identically by default, the distinction seems irrelevant for now.
> >
> >  It is important to note that screen readers ignore both STRONG/B tags
> along with EM/I and color changes by default. Use either one as needed
> assuming that they convey little semantic info to screen readers.
> >
> > If you really are using STRONG/B or EM/I for major inline emphasis, you
> may want to add text like Note: or Warning: or Important: This was the
> recommendation I got from my screen reader colleagues.
> >
> > It's also important to tag headings consistently regardless of other
> formatting tags. Some cautions etc. can be headings.
> >
> > My two cents.
> >
> > Elizabeth J. Pyatt, Ph.D.
> > Sent from my iPad
> >
> >> On Aug 6, 2018, at 1:32 AM, Mohith BP <mohith.ckm49@gmail.com> wrote:
> >>
> >> Hi Vinil,
> >>
> >> Though WCAG recommends using <em> and <strong> elements, however, the
> >> support from the major screen readers for these 2 tags is nill.
> >> Please refer:
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG20%2FTechniques%2Fua-notes%2Fhtml%23H49&amp;data=02%7C01%7Cejp10%40psu.edu%7C5fac45f8eafa433d7cea08d5fb5e10c1%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636691303780330250&amp;sdata=n4c9uZ8knlvd0aYyKDm0a1GXB2vKjsGVJidOO4dHwQw%3D&amp;reserved=0
> >>
> >>
> >> Thanks & Regards,
> >> Mohith B. P.
> >>
> >>> On 8/5/18, Vinil Peter <vinilpeter.wcag@gmail.com> wrote:
> >>> Dear colleagues,
> >>>
> >>> I have been asked to provide my thoughts on a debate on the use of
> bold <b>
> >>> and strong <strong> for one of my clients. The client's internal
> >>> accessibility testing team marked all the instances where <b> was used
> as
> >>> errors and recommended to change them to <strong> so that screen
> readers
> >>> read out the text with added emphasis. This has brought their quality
> and
> >>> compliance scores down drastically. The client's developers are unhappy
> >>> about this and claim that they should not be marked down as there is no
> >>> clear guideline or fine print that mandates use of <strong> over <b>.
> >>> Moreover, W3C has not deprecated <b> yet and it's usage is still
> permitted.
> >>> <b> has been in use since ages and asking to replace all bold text with
> >>> strong is like declaring that  use of <b> should be banned henceforth.
> >>>
> >>> I am planning to give my recommendation to use <strong> in headers or
> >>> functionality names etc. if the text is bold as per  design, while it
> is
> >>> still fair to allow use of <b> for other bold text. The 'appropriate
> usage'
> >>> of bold or strong is finally the designer's call as there is no clear
> >>> guideline.
> >>>
> >>> Is my recommendation correct or am I missing something? What your
> thoughts
> >>> and have you come across any such debate?
> >>>
> >>> ⁣Regards,
> >>> Vinil Peter, PMP​
> >>
>
>
>
Received on Monday, 6 August 2018 16:56:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:37:20 UTC