Re: Bold vs Strong

Compare the definition of <strong> 
https://www.w3.org/TR/html52/textlevel-semantics.html#the-strong-element

“The strong element represents strong importance, seriousness, or 
urgency for its contents.
Importance: The strong element can be used in a heading, caption, or 
paragraph to distinguish the part that really matters from other parts 
that might be more detailed, more jovial, or merely boilerplate.”

To the definition of <b> 
https://www.w3.org/TR/html52/textlevel-semantics.html#the-b-element

“The b element represents a span of text to which attention is being 
drawn for utilitarian purposes without conveying any extra importance 
and with no implication of an alternate voice or mood, such as key words 
in a document abstract, product names in a review, actionable words in 
interactive text-driven software, or an article lede.”

Now, it’s up to you to nitpick/hairsplit about these definitions, and 
whether or not they’re not relevant to SC 1.3.1. But “<b> hasn’t been 
deprecated, and there’s no failure technique explicitly forbidding its 
use” isn’t a very strong argument, I’d say.

P

On 07/08/2018 05:45, Phill Jenkins wrote:
> hmm, just a note regarding this failure technique - it does *not* 
> discuss Strong vs Bold  so no real guidance here.
> 
> The failure technique does have 3 "semantic" failure examples, none of 
> which say that using the element <b> instead of <strong> is a failure: 
> *emphasis added*
> 
> Failure example 1: *Using CSS to style the p element to look like a heading*
> The author intended to make a *heading* but didn't want the look of the 
> default HTML heading. So they used CSS to style the P element to look 
> like a heading and they called it a heading. But they failed to use the 
> proper HTML heading element. Therefore, the Assistive Technology could 
> not distinguish it as a heading.
> /Note: /In this case, the proper approach would be to use CSS to style 
> the H1 element in HTML.
> 
> Failure example 2: *Images of text used as headings where the images are 
> not marked up with heading tags*
> Chapter1.gif is an *image* of the words, "Chapter One" in a Garamond 
> font sized at 20 pixels. This is a failure because at a minimum the img 
> element should be enclosed within a header element. A better solution 
> would be to eliminate the image and to enclose the text within a header 
> element which has been styled using CSS.
> 
> Failure example 3: *Using CSS to visually emphasize a phrase or word 
> without conveying that emphasis semantically*
> The following example fails because the information conveyed by using 
> the CSS font-weight property to change to a bold font is not conveyed 
> through *semantic markup* or stated explicitly in the text.
> 
> In my opinion there is no *semantic* difference between Bold and Strong, 
> it just that the term Bold and the element <b> *also* have a visual 
> style meaning implied, but not guaranteed.
> In my opinion failing a website for simply using <b> instead of <strong> 
>   shows the lack of understanding of the success criteria, since either 
> one can be styled / rendered in any way the same or differently, but 
> semantically they are the same.  But I do agree that most folks writing 
> HTML by hand would probably feel odd using <b> and styling it 
> differently.  Its kind of a style and semantic tag wrapped up in one, 
> where <strong> is perhaps not as tied or implied to have a "bold font 
> face".
> 
> Someone else told me something to the effect of:
> *<span class="bold">Bold Text</span>* is just as semantically vacuous as 
> *<b>Bold Text</b>* or *<strong>Bold Text</strong> and *consumes many 
> more ASCII characters in the HTML file.
> *Semantically Vacuous = *Syntactically different but no semantic 
> difference.
> 
> and regarding the comment that screen readers do *nothing different* is 
> *not* exactly correct or at least current - see this update from 2010 
> (only 8 years ago):
> 
> UPDATE 28/01/10
> 
> A _tweet by Dan Clark_ 
> <http://twitter.com/danclarktrainer/status/8324131517> points out that 
> JAWS has a document proofreading scheme called/ Proofreading 
> (attributes)/, using this scheme italicized, stricken and bolded text is 
> indicated by a change in voice, but there is no distinction between <em> 
> or <i> and <strong> or <b>. He also mentions that JAWS schemes can be 
> accessed via a dialog using the INS+ALT+S key combination.
> 
> 
> Until HTML deprecates <b>, it should be treated the same as <strong>, 
> because both elements have semantic meaning, regardless of their visual 
> style.
> and in my opinion, this has been a silly debate that has been wasting 
> time and energy when there are definitely more important things to debate.
> 
> I do suggest that [no semantic difference] needs to be "documented" in 
> one of the techniques to end the debate and educate us all.
> ___________
> Regards,
> Phill Jenkins
> 
> 
> 
> 
> From: Vinil Peter <vinilpeter.wcag@gmail.com>
> To: Katie Haritos-Shea <ryladog@gmail.com>
> Cc: WAI Interest Group <w3c-wai-ig@w3.org>
> Date: 08/05/2018 03:23 PM
> Subject: Re: Bold vs Strong
> ------------------------------------------------------------------------
> 
> 
> 
> Hi Katie,
> 
> Thanks for the information and guidance.
> 
> Regards,
> Vinil Peter, PMP
> On Aug 5, 2018, at 11:09 PM, Katie Haritos-Shea <_ryladog@gmail.com_ 
> <mailto:ryladog@gmail.com>> wrote:
> Vinil,
> 
> Please see WCAG 2 failure technique as rationale for using semantic 
> markup: _https://www.w3.org/TR/WCAG20-TECHS/F2.html_
> F2: Failure of Success Criterion 1.3.1 due to using changes in text 
> presentation to convey information without using the appropriate markup 
> or text
> 
> 
> On Sun, Aug 5, 2018, 11:17 AM Vinil Peter < _vinilpeter.wcag@gmail.com_ 
> <mailto: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
> 
> 

-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Tuesday, 7 August 2018 09:37:40 UTC