Re: Bold vs Strong

Like Michael, I’ve also used CSS to make the appearance of STRONG distinct from B. 

For instance, on some sites I maintain, STRONG is a WCAG 2.0 contrast compliant crimson red indicating very strong emphasis (such as for a warning). I think this preserves the semantics, but because it’s not indicated by default on a screen reader, some extra text should be included to indicate the very strong emphasis. 

I should also add that making STRONG crimson red has seriously confused other content editors. Since they think of STRONG as just the “accessible” B tag, the CSS usage is considered foreign. This could be a chance to help people re-think the semantics as Michael says, but I haven’t seen most developers follow this path.

It’s good to consider semantics, but unless a clear semantic distinction is really made within the web content, even for sighted users, then the point is moot. I sincerely doubt sighted users/developers would ever understand the semantic distinction between B and STRONG without a distinct visual cue as well. Therefore, the usage will always be muddy unless such a change is implemented. I’m not saying it can’t happen…but that it hasn’t happened so far.

FYI - If screen reader technology evolves, then CSS can be used to spot and correct errant tags, but sighted developers will again need to be seriously re-trained.

Elizabeth

P.S. I compare this STRONG/B contrast to the distinction of "who/whom.”  Even though it’s supposed to exist in written English, the reality is that almost no one makes this distinction in spoken English (or even much in written English really). Although a semantic cue has been theoretically lost, people speaking English are rarely confused so enforcing the rule may be moot.

> On Aug 6, 2018, at 11:17 AM, Michael A. Peters <mpeters@domblogger.net> wrote:
> 
> 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​
>>> 
> 
> 

=-=-=-=-=-=-=-=-=-=-=-=-=
Elizabeth J. Pyatt, Ph.D.
Accessibility IT Consultant
Teaching and Learning with Technology
Penn State University
ejp10@psu.edu, (814) 865-0805 or (814) 865-2030 (Main Office)

The 300 Building, 112
304 West College Avenue
State College, PA 16801
accessibility.psu.edu

Received on Monday, 6 August 2018 16:13:09 UTC