Discussion:
Bold vs Strong
Vinil Peter
2018-08-05 15:10:26 UTC
Permalink
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​
Katie Haritos-Shea
2018-08-05 17:38:50 UTC
Permalink
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
Post by Vinil Peter
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
Vinil Peter
2018-08-05 20:17:43 UTC
Permalink
Hi Katie,

Thanks for the information and guidance.

⁣Regards,
Vinil Peter, PMP​
Post by Katie Haritos-Shea
Vinil,
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
Post by Vinil Peter
Dear colleagues,
I have been asked to provide my thoughts on a debate on the use of
bold
Post by Vinil Peter
<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
Post by Vinil Peter
errors and recommended to change them to <strong> so that screen
readers
Post by Vinil Peter
read out the text with added emphasis. This has brought their quality
and
Post by Vinil Peter
compliance scores down drastically. The client's developers are
unhappy
Post by Vinil Peter
about this and claim that they should not be marked down as there is
no
Post by Vinil Peter
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.
Post by Vinil Peter
<b> has been in use since ages and asking to replace all bold text
with
Post by Vinil Peter
strong is like declaring that use of <b> should be banned
henceforth.
Post by Vinil Peter
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
Post by Vinil Peter
still fair to allow use of <b> for other bold text. The 'appropriate
usage'
Post by Vinil Peter
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
Post by Vinil Peter
and have you come across any such debate?
Regards,
Vinil Peter, PMP
Katie Haritos-Shea
2018-08-05 20:41:32 UTC
Permalink
You bet!
Post by Vinil Peter
Hi Katie,
Thanks for the information and guidance.
Regards,
Vinil Peter, PMP
Post by Katie Haritos-Shea
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
Post by Vinil Peter
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
Phill Jenkins
2018-08-07 04:45:58 UTC
Permalink
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 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 <***@gmail.com>
To: Katie Haritos-Shea <***@gmail.com>
Cc: WAI Interest Group <w3c-wai-***@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 <***@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 < ***@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
David Woolley
2018-08-07 09:33:27 UTC
Permalink
Post by Phill Jenkins
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.
This issue is basically the result of an early aberration in HTML
resulting in B and I being introduced as presentational markup, in what
was otherwise a semantic markup language. Unfortunately, they will be
impossible to dislodge as graphic designers think in terms of
presentation not semantics, and screen reader developers go by trying to
make the best of what is in the real world, so tend to reinforce
misuses, and not support minority, but correct, use.

The HTML 1.2 definitions
<https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt> are:

B Boldface, where available, otherwise
alternative mapping allowed.

STRONG Stronger emphasis, typically bold.


where it is clear that B was only intended to have presentational semantics.
Phill Jenkins
2018-08-07 13:40:38 UTC
Permalink
David, when you said:
"...and screen reader developers go by trying to
make the best of what is in the real world, so tend to reinforce
misuses, and not support minority, but correct, use."

Is there a proposal or recommendation or discussion somewhere on how
screen reader developers should better support the correct use?
Does the "correct use" suggest that <b> and <strong> should be supported -
as in rendered - *differently* by screen readers?
I thought the issue was resolved and they were to be treated the same. I
understand that they *could* be visually styled differently, and some do
that,
but that doesn't mean they "should* be styled visually differently any
more than they should be rendered differently by screen readers.

and as most of us know, and Sean wrote, "other screen readers also support
this which indicates people might not [know how] to be using the screen
reader correctly"
___________
Regards,
Phill Jenkins
***@us.ibm.com
Senior Engineer & Accessibility Executive
IBM Research Accessibility

linkedin.com/in/philljenkins/
ibm.com/able
twitter.com/IBMAccess
ageandability.com



From: David Woolley <***@david-woolley.me.uk>
To: w3c-wai-***@w3.org
Date: 08/07/2018 04:39 AM
Subject: Re: Bold vs Strong
Post by Phill Jenkins
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.
This issue is basically the result of an early aberration in HTML
resulting in B and I being introduced as presentational markup, in what
was otherwise a semantic markup language. Unfortunately, they will be
impossible to dislodge as graphic designers think in terms of
presentation not semantics, and screen reader developers go by trying to
make the best of what is in the real world, so tend to reinforce
misuses, and not support minority, but correct, use.

The HTML 1.2 definitions
<
https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
B Boldface, where available, otherwise
alternative mapping allowed.

STRONG Stronger emphasis, typically bold.


where it is clear that B was only intended to have presentational
semantics.
Patrick H. Lauke
2018-08-07 09:37:11 UTC
Permalink
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
Post by Phill Jenkins
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
*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".
*<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
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
Date: 08/05/2018 03:23 PM
Subject: Re: Bold vs Strong
------------------------------------------------------------------------
Hi Katie,
Thanks for the information and guidance.
Regards,
Vinil Peter, PMP
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
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
Phill Jenkins
2018-08-07 14:04:52 UTC
Permalink
Patrick,
thanks for quoting the HTML 5.2 definition of <strong> and <b>, which I
agree is not worth it to nitpick/hairsplit about these definitions
which supports my argument that semantically they are (without
nitpick/hairsplitting) the same relevant to SC 1.3.1.

and I agree that alone, it isn't a very strong argument that ?<b> hasn?t
been deprecated, and there?s no failure technique explicitly forbidding
its
use?, but my point was to explain that the failure technique provide no
guidance on the issue (so why reference it?), and my suggestion to the
community is to create such missing explicit guidance. But I'm strongly
suggesting that a technique that explicitly forbids the use of <b>, would
itself be misguided until <b> has been deprecated.

otherwise, coming from my screen reader development days (OS/2, Java, and
Home Page Reader), the silly debate and worse, misinterpretation will
continue.

Does anyone disagree that guidance (either way) needs to be documented in
a WCAG technique (or equivalent), so it can be referenced?
___________
Regards,
Phill Jenkins
***@us.ibm.com
Senior Engineer & Accessibility Executive
IBM Research Accessibility

linkedin.com/in/philljenkins/
ibm.com/able
twitter.com/IBMAccess
ageandability.com



From: "Patrick H. Lauke" <***@splintered.co.uk>
To: w3c-wai-***@w3.org
Date: 08/07/2018 04:40 AM
Subject: 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
Post by Phill Jenkins
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
*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".
*<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
UPDATE 28/01/10
A _tweet by Dan Clark_
<
http://twitter.com/danclarktrainer/status/8324131517
Post by Phill Jenkins
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
Date: 08/05/2018 03:23 PM
Subject: Re: Bold vs Strong
------------------------------------------------------------------------
Hi Katie,
Thanks for the information and guidance.
Regards,
Vinil Peter, PMP
Vinil,
_https://www.w3.org/TR/WCAG20-TECHS/F2.html_
Post by Phill Jenkins
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
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
David Woolley
2018-08-05 17:51:30 UTC
Permalink
Post by Vinil Peter
I am planning to give my recommendation to use <strong> in headers
I don't understand this as headers should be specifically marked up as
such, and can therefore be styled based on that markup.
Post by Vinil Peter
Moreover, W3C has not deprecated <b>
W3C cannot effectively deprecate anything in HTML as it lost effective
control of HTML many years ago, with the introduction of HTML5 by a
rival consortium.
Mohith BP
2018-08-06 05:27:21 UTC
Permalink
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://www.w3.org/WAI/WCAG20/Techniques/ua-notes/html#H49


Thanks & Regards,
Mohith B. P.
Post by Vinil Peter
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​
Pyatt, Elizabeth J
2018-08-06 14:24:00 UTC
Permalink
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
Post by Mohith BP
Hi Vinil,
Though WCAG recommends using <em> and <strong> elements, however, the
support from the major screen readers for these 2 tags is nill.
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.
Post by Vinil Peter
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?
⁣R
Michael A. Peters
2018-08-06 15:17:49 UTC
Permalink
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.
Post by Pyatt, Elizabeth J
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
Post by Mohith BP
Hi Vinil,
Though WCAG recommends using <em> and <strong> elements, however, the
support from the major screen readers for these 2 tags is nill.
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.
Post by Vinil Peter
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​
Pyatt, Elizabeth J
2018-08-06 16:12:39 UTC
Permalink
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.
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.
Post by Pyatt, Elizabeth J
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
Post by Mohith BP
Hi Vinil,
Though WCAG recommends using <em> and <strong> elements, however, the
support from the major screen readers for these 2 tags is nill.
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.
Post by Vinil Peter
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
***@psu.edu, (814) 865-0805 or (814) 865-2030 (Main Office)

The 300 Building, 112
304 West College Avenue
State College, PA 16801
accessibility
Jonathan Avila
2018-08-06 16:16:50 UTC
Permalink
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
***@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:***@domblogger.net]
Sent: Monday, August 06, 2018 11:18 AM
To: w3c-wai-***@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.
Post by Pyatt, Elizabeth J
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
Post by Mohith BP
Hi Vinil,
Though WCAG recommends using <em> and <strong> elements, however, the
support from the major screen readers for these 2 tags is nill.
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.
Post by Vinil Peter
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, PM
David Ashleydale
2018-08-06 16:55:53 UTC
Permalink
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
Post by Jonathan Avila
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
703.637.8957 office
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-----
Sent: Monday, August 06, 2018 11:18 AM
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.
Post by Pyatt, Elizabeth J
I concur with Mohith.
Because most screen readers and visual browsers treat STRONG/B
identically by default, the distinction seems irrelevant for now.
Post by Pyatt, Elizabeth J
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.
Post by Pyatt, Elizabeth J
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.
Post by Pyatt, Elizabeth J
It's also important to tag headings consistently regardless of other
formatting tags. Some cautions etc. can be headings.
Post by Pyatt, Elizabeth J
My two cents.
Elizabeth J. Pyatt, Ph.D.
Sent from my iPad
Post by Mohith BP
Hi Vinil,
Though WCAG recommends using <em> and <strong> elements, however, the
support from the major screen readers for these 2 tags is nill.
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
Post by Pyatt, Elizabeth J
Post by Mohith BP
Thanks & Regards,
Mohith B. P.
Post by Vinil Peter
Dear colleagues,
I have been asked to provide my thoughts on a debate on the use of
bold <b>
Post by Pyatt, Elizabeth J
Post by Mohith BP
Post by Vinil Peter
and strong <strong> for one of my clients. The client's internal
accessibility testing team marked all the instances where <b> was used
as
Post by Pyatt, Elizabeth J
Post by Mohith BP
Post by Vinil Peter
errors and recommended to change them to <strong> so that screen
readers
Post by Pyatt, Elizabeth J
Post by Mohith BP
Post by Vinil Peter
read out the text with added emphasis. This has brought their quality
and
Post by Pyatt, Elizabeth J
Post by Mohith BP
Post by Vinil Peter
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.
Post by Pyatt, Elizabeth J
Post by Mohith BP
Post by Vinil Peter
<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
Post by Pyatt, Elizabeth J
Post by Mohith BP
Post by Vinil Peter
still fair to allow use of <b> for other bold text. The 'appropriate
usage'
Post by Pyatt, Elizabeth J
Post by Mohith BP
Post by Vinil Peter
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
Post by Pyatt, Elizabeth J
Post by Mohith BP
Post by Vinil Peter
and have you come across any such debate?
⁣Regards,
Vinil Peter, PMP​
Userite
2018-08-07 09:52:01 UTC
Permalink
Dear Vinil,

Richard Ishida (W3C) wrote an article on this issue in 2010 (see https://www.w3.org/International/questions/qa-b-and-i-tags ).

His quick answer was as follows - “You should always bear in mind that the content of a b element may not always be bold, and that of an i element may not always be italic. The actual style is dependent on the CSS style definitions. You should also bear in mind that bold and italic may not be the preferred style for content in certain languages.
You should not use b and i tags if there is a more descriptive and relevant tag available. If you do use them, it is usually better to add class attributes that describe the intended meaning of the markup, so that you can distinguish one use from another. “

Furthermore the HTML5 specification states that “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”

As a result I believe that your client has a strong case for asking you to replace the <b> element with <strong> or <em> or <cite>.

Be very wary of anyone who claims that, because there is no specified failure criteria, they can use an element in a situation where it is not “best practice”. just because everyone else is doing it.

<b> enhances the visual effect, but <strong> enhances the meaning as well.

Regards
Richard Warren
Technical Manager
Website Auditing Ltd
www.userite.com



From: Vinil Peter
Sent: Sunday, August 05, 2018 4:10 PM
To: w3c-wai-***@w3.org
Subject: Bold vs Strong

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
Duff Johnson
2018-08-07 13:24:57 UTC
Permalink
There’s an aspect that I’ve not seen covered in the discussion so far on this point.

There are many use cases (especially in STEM publications) in which italics and bold have specific uses that are announced in the document.

For example, italics may be used to indicate values. Bold may be used to indicate dictionary key names.

Discerning the meaning of the content without reference to bold and italics usage in such cases could lead to confusion. Here’s a (slightly hacked for effect) example:

"If IT is present and its value is not Stamp, it's Name shall not be present. "

Substituting <strong> for <b> or <i> would just.. blow all this up, and make such documents far harder - in principle - for AT users to read, no?

Duff.
Post by Userite
Dear Vinil,
Richard Ishida (W3C) wrote an article on this issue in 2010 (see https://www.w3.org/International/questions/qa-b-and-i-tags <https://www.w3.org/International/questions/qa-b-and-i-tags> ).
His quick answer was as follows - “You should always bear in mind that the content of a b element may not always be bold, and that of an i element may not always be italic. The actual style is dependent on the CSS style definitions. You should also bear in mind that bold and italic may not be the preferred style for content in certain languages.
You should not use b and i tags if there is a more descriptive and relevant tag available. If you do use them, it is usually better to add class attributes that describe the intended meaning of the markup, so that you can distinguish one use from another. “
Furthermore the HTML5 specification states that “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”
As a result I believe that your client has a strong case for asking you to replace the <b> element with <strong> or <em> or <cite>.
Be very wary of anyone who claims that, because there is no specified failure criteria, they can use an element in a situation where it is not “best practice”. just because everyone else is doing it.
<b> enhances the visual effect, but <strong> enhances the meaning as well.
Regards
Richard Warren
Technical Manager
Website Auditing Ltd
www.userite.com <http://www.userite.com/>
Sent: Sunday, August 05, 2018 4:10 PM
Subject: Bold vs Strong
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
Phill Jenkins
2018-08-07 14:16:59 UTC
Permalink
Duff said:
Substituting <strong> for <b> or <i> would just.. blow all this up, and
make such documents far harder - in principle - for AT users to read, no?
Here?s a (slightly hacked for effect) example:

"If IT is present and its value is not Stamp, it's Name shall not be
present. "

I am not and I do not think others are suggesting substituting bold with
italics ,
<b> for <i>, or
<strong>> for <em>

so even in your hacked example, the distinction remains substituting <b>
for <strong> and <i> for <em>.
The accessibility issue, meaning success criteria, is more about semantic
equivalence, not visual presentation equivalence. In other words, there
is not requirement that all headings look visually the same, for example,
just that one use the semantic heading <h1> element to identify the
heading that the author intended to be identified by the reader as is in
fact a heading without reference to the visual rendering alone.
___________
Regards,
Phill Jenkins
***@us.ibm.com
Senior Engineer & Accessibility Executive
IBM Research Accessibility




From: Duff Johnson <***@duff-johnson.com>
To: w3c-wai-ig <w3c-wai-***@w3.org>
Date: 08/07/2018 08:30 AM
Subject: Re: Bold vs Strong



There?s an aspect that I?ve not seen covered in the discussion so far on
this point.

There are many use cases (especially in STEM publications) in which
italics and bold have specific uses that are announced in the document.

For example, italics may be used to indicate values. Bold may be used to
indicate dictionary key names.

Discerning the meaning of the content without reference to bold and
italics usage in such cases could lead to confusion. Here?s a (slightly
hacked for effect) example:

"If IT is present and its value is not Stamp, it's Name shall not be
present. "

Substituting <strong> for <b> or <i> would just.. blow all this up, and
make such documents far harder - in principle - for AT users to read, no?

Duff.



On Aug 7, 2018, at 05:52, Userite <***@userite.com> wrote:

Dear Vinil,

Richard Ishida (W3C) wrote an article on this issue in 2010 (see
https://www.w3.org/International/questions/qa-b-and-i-tags ).

His quick answer was as follows - ?You should always bear in mind that
the content of a b element may not always be bold, and that of an i
element may not always be italic. The actual style is dependent on the CSS
style definitions. You should also bear in mind that bold and italic may
not be the preferred style for content in certain languages.
You should not use b and i tags if there is a more descriptive and
relevant tag available. If you do use them, it is usually better to add
class attributes that describe the intended meaning of the markup, so that
you can distinguish one use from another. ?
Furthermore the HTML5 specification states that ?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?
As a result I believe that your client has a strong case for asking you to
replace the <b> element with <strong> or <em> or <cite>.

Be very wary of anyone who claims that, because there is no specified
failure criteria, they can use an element in a situation where it is not
?best practice?. just because everyone else is doing it.

<b> enhances the visual effect, but <strong> enhances the meaning as well.

Regards
Richard Warren
Technical Manager
Website Auditing Ltd
www.userite.com



From: Vinil Peter
Sent: Sunday, August 05, 2018 4:10 PM
To: w3c-wai-***@w3.org
Subject: Bold vs Strong

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
Janina Sajka
2018-08-07 17:56:52 UTC
Permalink
Phil, All:

I recognize WCAG has been suggesting that "strong" and "emphasis" are
semantic designations for many, many years.

May I ask where we got this definition? I can't seem to find any grammar
text that speaks of bold or italics using such terms. So, what's our
authority?

I'd like to know because I, myself, am constantly getting them confused
in my own mind. I don't have that same problem with bold or italic, even
those are type-faces I haven't seen for myself in decades.

Let me hasten to underscore my strong support for semantic markup. I'm
just not convinced these two terms are all that semantic. They strike me
as rather arbitrary. I could equally accept a definition that said bold
equals emphasis, and italics equals strong.

So, please educate me.

Thanks,

Janina
Post by Duff Johnson
Substituting <strong> for <b> or <i> would just.. blow all this up, and
make such documents far harder - in principle - for AT users to read, no?
"If IT is present and its value is not Stamp, it's Name shall not be present. "
I am not and I do not think others are suggesting substituting bold with
italics ,
<b> for <i>, or
<strong>> for <em>
so even in your hacked example, the distinction remains substituting <b>
for <strong> and <i> for <em>.
The accessibility issue, meaning success criteria, is more about semantic
equivalence, not visual presentation equivalence. In other words, there
is not requirement that all headings look visually the same, for example,
just that one use the semantic heading <h1> element to identify the
heading that the author intended to be identified by the reader as is in
fact a heading without reference to the visual rendering alone.
___________
Regards,
Phill Jenkins
Senior Engineer & Accessibility Executive
IBM Research Accessibility
Date: 08/07/2018 08:30 AM
Subject: Re: Bold vs Strong
There?s an aspect that I?ve not seen covered in the discussion so far on
this point.
There are many use cases (especially in STEM publications) in which
italics and bold have specific uses that are announced in the document.
For example, italics may be used to indicate values. Bold may be used to
indicate dictionary key names.
Discerning the meaning of the content without reference to bold and
italics usage in such cases could lead to confusion. Here?s a (slightly
"If IT is present and its value is not Stamp, it's Name shall not be present. "
Substituting <strong> for <b> or <i> would just.. blow all this up, and
make such documents far harder - in principle - for AT users to read, no?
Duff.
Dear Vinil,
Richard Ishida (W3C) wrote an article on this issue in 2010 (see
https://www.w3.org/International/questions/qa-b-and-i-tags ).
His quick answer was as follows - ?You should always bear in mind that
the content of a b element may not always be bold, and that of an i
element may not always be italic. The actual style is dependent on the CSS
style definitions. You should also bear in mind that bold and italic may
not be the preferred style for content in certain languages.
You should not use b and i tags if there is a more descriptive and
relevant tag available. If you do use them, it is usually better to add
class attributes that describe the intended meaning of the markup, so that
you can distinguish one use from another. ?
Furthermore the HTML5 specification states that ?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?
As a result I believe that your client has a strong case for asking you to
replace the <b> element with <strong> or <em> or <cite>.
Be very wary of anyone who claims that, because there is no specified
failure criteria, they can use an element in a situation where it is not
?best practice?. just because everyone else is doing it.
<b> enhances the visual effect, but <strong> enhances the meaning as well.
Regards
Richard Warren
Technical Manager
Website Auditing Ltd
www.userite.com
From: Vinil Peter
Sent: Sunday, August 05, 2018 4:10 PM
Subject: Bold vs Strong
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
--
Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
c***@pubcom.com
2018-08-07 19:28:29 UTC
Permalink
Great question, Janina.

The concept of tags to indicate when text is italicized and bolded goes back
to the mid- to late-1990s, if I recall correctly. 20 years ago.

The idea was how could we convey the visual formatting we were putting on
certain words for certain purposes. Both bold and italics are used to
emphasize words, or stress them if they are being spoken.

I know we also talked briefly about other uses of formatting, such as using
bold to format headings (usually, but not always), and using italics for all
sorts of text like publication titles, foreign words, medical and scientific
terms, citations, ship names, and many more. But that part of the discussion
faded and never went further.

All these uses are just conventions of American English grammar; British
grammar varies a bit, but is mostly the same.

I doubt think that the emphasis and strong tags have worked out as well as
we thought they would. One primary reason: how many assistive technologies
actually recognize and announce them? Another is just as you mentioned:
strong and emphasis can be swapped between bold and italics and it wouldn't
matter much to a screen reader user.

A bolded heading doesn't need to have the bold/strong information relayed
because the "importance of being bold" is implied in the Hx heading tags
themselves. But I'd like to see more tags based on usage, rather than visual
formatting; Tags for titles of publications, citations, foreign terms, etc.
I think those would be very beneficial to the our users because they convey
not just the visual formatting but also the intention or meaning of the
words.

Any development in this area will need to go through the various standards
committees for WCAG, PDF/UA, EPUB, etc.

- - -
Bevi Chagnon, founder/CEO | ***@PubCom.com
- - -
PubCom: Technologists for Accessible Design + Publishing
consulting . training . development . design . sec. 508 services
Upcoming classes at www.PubCom.com/classes
- - -
Latest blog-newsletter - Accessibility Tips

-----Original Message-----
From: Janina Sajka <***@rednote.net>
Sent: Tuesday, August 7, 2018 1:57 PM

Phil, All:

I recognize WCAG has been suggesting that "strong" and "emphasis" are
semantic designations for many, many years.

May I ask where we got this definition? I can't seem to find any grammar
text that speaks of bold or italics using such terms. So, what's our
authority?

I'd like to know because I, myself, am constantly getting them confused in
my own mind. I don't have that same problem with bold or italic, even those
are type-faces I haven't seen for myself in decades.

Let me hasten to underscore my strong support for semantic markup. I'm just
not convinced these two terms are all that semantic. They strike me as
rather arbitrary. I could equally accept a definition that said bold equals
emphasis, and italics equals strong.

So, please educate me.

Thanks,
Janina
David Woolley
2018-08-07 20:26:30 UTC
Permalink
Post by c***@pubcom.com
The concept of tags to indicate when text is italicized and bolded goes back
to the mid- to late-1990s, if I recall correctly. 20 years ago.
It's in Tim Berners-Lee's 1993 HTML 1.2 specification, that I referenced
up thread, so at least 25 years old. I think it was in HTML 1.0, but I
couldn't find that quickly.

(Incidentally, to me the HTML 5.2 definitions look like attempts to give
semantic legitimacy to B and I after the fact.)
George Kerscher
2018-08-07 20:45:57 UTC
Permalink
Hello folks,

Well, I thought I would jump in...
From the digital publishing space, now part of the W3C, comes my question.
Is this correct markup that would work for everybody?

Let us say from this grammar book:

In the following examples the words in bold are nouns, verbs are italic,
adjectives are double-underlined, and adverbs are underlined. If the
students would like to read the explicit semantics, please expand the
details to find the part of speech immediately before the word.

<p aria-details="#for-screen-readers">The <strong
class="double-underline">red</strong> <b>fox</b> <em
class="underline">quickly</em> <em>ran</em> away.</p>
<details id="for-screen-readers"><summary>with explicit semantics</summary>
The (adjective) red (noun) fox (adverb) quickly (verb) ran away.</details>

Best
George

-----Original Message-----
From: ***@pubcom.com <***@pubcom.com>
Sent: Tuesday, August 7, 2018 1:28 PM
To: 'w3c-wai-ig' <w3c-wai-***@w3.org>
Subject: RE: Bold vs Strong

Great question, Janina.

The concept of tags to indicate when text is italicized and bolded goes back
to the mid- to late-1990s, if I recall correctly. 20 years ago.

The idea was how could we convey the visual formatting we were putting on
certain words for certain purposes. Both bold and italics are used to
emphasize words, or stress them if they are being spoken.

I know we also talked briefly about other uses of formatting, such as using
bold to format headings (usually, but not always), and using italics for all
sorts of text like publication titles, foreign words, medical and scientific
terms, citations, ship names, and many more. But that part of the discussion
faded and never went further.

All these uses are just conventions of American English grammar; British
grammar varies a bit, but is mostly the same.

I doubt think that the emphasis and strong tags have worked out as well as
we thought they would. One primary reason: how many assistive technologies
actually recognize and announce them? Another is just as you mentioned:
strong and emphasis can be swapped between bold and italics and it wouldn't
matter much to a screen reader user.

A bolded heading doesn't need to have the bold/strong information relayed
because the "importance of being bold" is implied in the Hx heading tags
themselves. But I'd like to see more tags based on usage, rather than visual
formatting; Tags for titles of publications, citations, foreign terms, etc.
I think those would be very beneficial to the our users because they convey
not just the visual formatting but also the intention or meaning of the
words.

Any development in this area will need to go through the various standards
committees for WCAG, PDF/UA, EPUB, etc.

- - -
Bevi Chagnon, founder/CEO | ***@PubCom.com
- - -
PubCom: Technologists for Accessible Design + Publishing
consulting . training . development . design . sec. 508 services
Upcoming classes at www.PubCom.com/classes
- - -
Latest blog-newsletter - Accessibility Tips

-----Original Message-----
From: Janina Sajka <***@rednote.net>
Sent: Tuesday, August 7, 2018 1:57 PM

Phil, All:

I recognize WCAG has been suggesting that "strong" and "emphasis" are
semantic designations for many, many years.

May I ask where we got this definition? I can't seem to find any grammar
text that speaks of bold or italics using such terms. So, what's our
authority?

I'd like to know because I, myself, am constantly getting them confused in
my own mind. I don't have that same problem with bold or italic, even those
are type-faces I haven't seen for myself in decades.

Let me hasten to underscore my strong support for semantic markup. I'm just
not convinced these two terms are all that semantic. They strike me as
rather arbitrary. I could equally accept a definition that said bold equals
emphasis, and italics equals strong.

So, please educate me.

Thanks,
Janina
ann junker
2018-08-07 21:46:51 UTC
Permalink
These pages may help in terms of what HTML and browsers believe the styling
and semantics for em and strong are, which are generally used within
paragraphs, span, div, and table tags. If another tag, like headers or
labels, are used - it's best to style those with css rather than add more
html around the text. These tags already have semantic meaning and adding
more can cause confusion in meaning and complicate styling - making unhappy
developers.
https://www.w3schools.com/tags/tag_em.asp
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_phrase_test

The b and i tags were part of HTML to style the text, though did not
provide semantic meaning. As seen from the html_phrase_test link above,
browsers general style em as italics and strong as bold, but you can use
css to style how every you need without changing the semantics.
Hypothetically, would you use the b tag with css to unbold it? Or would
using the strong tag be better without bolding?

Thanks,
Ann
Post by George Kerscher
Hello folks,
Well, I thought I would jump in...
From the digital publishing space, now part of the W3C, comes my question.
Is this correct markup that would work for everybody?
In the following examples the words in bold are nouns, verbs are italic,
adjectives are double-underlined, and adverbs are underlined. If the
students would like to read the explicit semantics, please expand the
details to find the part of speech immediately before the word.
<p aria-details="#for-screen-readers">The <strong
class="double-underline">red</strong> <b>fox</b> <em
class="underline">quickly</em> <em>ran</em> away.</p>
<details id="for-screen-readers"><summary>with explicit semantics</summary>
The (adjective) red (noun) fox (adverb) quickly (verb) ran away.</details>
Best
George
-----Original Message-----
Sent: Tuesday, August 7, 2018 1:28 PM
Subject: RE: Bold vs Strong
Great question, Janina.
The concept of tags to indicate when text is italicized and bolded goes back
to the mid- to late-1990s, if I recall correctly. 20 years ago.
The idea was how could we convey the visual formatting we were putting on
certain words for certain purposes. Both bold and italics are used to
emphasize words, or stress them if they are being spoken.
I know we also talked briefly about other uses of formatting, such as using
bold to format headings (usually, but not always), and using italics for all
sorts of text like publication titles, foreign words, medical and scientific
terms, citations, ship names, and many more. But that part of the discussion
faded and never went further.
All these uses are just conventions of American English grammar; British
grammar varies a bit, but is mostly the same.
I doubt think that the emphasis and strong tags have worked out as well as
we thought they would. One primary reason: how many assistive technologies
strong and emphasis can be swapped between bold and italics and it wouldn't
matter much to a screen reader user.
A bolded heading doesn't need to have the bold/strong information relayed
because the "importance of being bold" is implied in the Hx heading tags
themselves. But I'd like to see more tags based on usage, rather than visual
formatting; Tags for titles of publications, citations, foreign terms, etc.
I think those would be very beneficial to the our users because they convey
not just the visual formatting but also the intention or meaning of the
words.
Any development in this area will need to go through the various standards
committees for WCAG, PDF/UA, EPUB, etc.
- - -
- - -
PubCom: Technologists for Accessible Design + Publishing
consulting . training . development . design . sec. 508 services
Upcoming classes at www.PubCom.com/classes
- - -
Latest blog-newsletter - Accessibility Tips
-----Original Message-----
Sent: Tuesday, August 7, 2018 1:57 PM
I recognize WCAG has been suggesting that "strong" and "emphasis" are
semantic designations for many, many years.
May I ask where we got this definition? I can't seem to find any grammar
text that speaks of bold or italics using such terms. So, what's our
authority?
I'd like to know because I, myself, am constantly getting them confused in
my own mind. I don't have that same problem with bold or italic, even those
are type-faces I haven't seen for myself in decades.
Let me hasten to underscore my strong support for semantic markup. I'm just
not convinced these two terms are all that semantic. They strike me as
rather arbitrary. I could equally accept a definition that said bold equals
emphasis, and italics equals strong.
So, please educate me.
Thanks,
Janina
Phill Jenkins
2018-08-07 22:37:47 UTC
Permalink
... The b and i tags were part of HTML to style the text, though did not
provide semantic meaning

Not exactly correct, perhaps if it was written with some caveats, such as
The b and i tags were [originally and mostly] part of HTML to style the
text, though [they both] did not provide [some little ] semantic meaning.

ignoring visual presentation for a moment, both <strong> and <b> are
needed and can / should be used to set apart part of a heading or a part
of some other semantic element such as cite or quote, etc. Using CSS
alone to convey the part of the heading or part of the some other semantic
mark-up *is a failure* to meet SC 1.3.1
___________
Regards,
Phill Jenkins
Check out the new system for requesting an IBM product Accessibility
Conformance Report VPAT® at able.ibm.com/request
***@us.ibm.com
Senior Engineer & Accessibility Executive
IBM Research Accessibility

linkedin.com/in/philljenkins/
ibm.com/able
twitter.com/IBMAccess
ageandability.com



From: ann junker <***@gmail.com>
To: ***@montana.com
Cc: w3c-wai-***@w3.org
Date: 08/07/2018 04:52 PM
Subject: Re: Bold vs Strong



These pages may help in terms of what HTML and browsers believe the
styling and semantics for em and strong are, which are generally used
within paragraphs, span, div, and table tags. If another tag, like headers
or labels, are used - it's best to style those with css rather than add
more html around the text. These tags already have semantic meaning and
adding more can cause confusion in meaning and complicate styling - making
unhappy developers.
https://www.w3schools.com/tags/tag_em.asp
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_phrase_test

The b and i tags were part of HTML to style the text, though did not
provide semantic meaning. As seen from the html_phrase_test link above,
browsers general style em as italics and strong as bold, but you can use
css to style how every you need without changing the semantics.
Hypothetically, would you use the b tag with css to unbold it? Or would
using the strong tag be better without bolding?

Thanks,
Ann



On Tue, Aug 7, 2018 at 3:51 PM George Kerscher <***@montana.com>
wrote:
Hello folks,

Well, I thought I would jump in...
From the digital publishing space, now part of the W3C, comes my question.
Is this correct markup that would work for everybody?

Let us say from this grammar book:

In the following examples the words in bold are nouns, verbs are italic,
adjectives are double-underlined, and adverbs are underlined. If the
students would like to read the explicit semantics, please expand the
details to find the part of speech immediately before the word.

<p aria-details="#for-screen-readers">The <strong
class="double-underline">red</strong> <b>fox</b> <em
class="underline">quickly</em> <em>ran</em> away.</p>
<details id="for-screen-readers"><summary>with explicit
semantics</summary>
The (adjective) red (noun) fox (adverb) quickly (verb) ran away.</details>

Best
George

-----Original Message-----
From: ***@pubcom.com <***@pubcom.com>
Sent: Tuesday, August 7, 2018 1:28 PM
To: 'w3c-wai-ig' <w3c-wai-***@w3.org>
Subject: RE: Bold vs Strong

Great question, Janina.

The concept of tags to indicate when text is italicized and bolded goes
back
to the mid- to late-1990s, if I recall correctly. 20 years ago.

The idea was how could we convey the visual formatting we were putting on
certain words for certain purposes. Both bold and italics are used to
emphasize words, or stress them if they are being spoken.

I know we also talked briefly about other uses of formatting, such as
using
bold to format headings (usually, but not always), and using italics for
all
sorts of text like publication titles, foreign words, medical and
scientific
terms, citations, ship names, and many more. But that part of the
discussion
faded and never went further.

All these uses are just conventions of American English grammar; British
grammar varies a bit, but is mostly the same.

I doubt think that the emphasis and strong tags have worked out as well as
we thought they would. One primary reason: how many assistive technologies
actually recognize and announce them? Another is just as you mentioned:
strong and emphasis can be swapped between bold and italics and it
wouldn't
matter much to a screen reader user.

A bolded heading doesn't need to have the bold/strong information relayed
because the "importance of being bold" is implied in the Hx heading tags
themselves. But I'd like to see more tags based on usage, rather than
visual
formatting; Tags for titles of publications, citations, foreign terms,
etc.
I think those would be very beneficial to the our users because they
convey
not just the visual formatting but also the intention or meaning of the
words.

Any development in this area will need to go through the various standards
committees for WCAG, PDF/UA, EPUB, etc.

- - -
Bevi Chagnon, founder/CEO | ***@PubCom.com
- - -
PubCom: Technologists for Accessible Design + Publishing
consulting . training . development . design . sec. 508 services
Upcoming classes at www.PubCom.com/classes
- - -
Latest blog-newsletter - Accessibility Tips

-----Original Message-----
From: Janina Sajka <***@rednote.net>
Sent: Tuesday, August 7, 2018 1:57 PM

Phil, All:

I recognize WCAG has been suggesting that "strong" and "emphasis" are
semantic designations for many, many years.

May I ask where we got this definition? I can't seem to find any grammar
text that speaks of bold or italics using such terms. So, what's our
authority?

I'd like to know because I, myself, am constantly getting them confused in
my own mind. I don't have that same problem with bold or italic, even
those
are type-faces I haven't seen for myself in decades.

Let me hasten to underscore my strong support for semantic markup. I'm
just
not convinced these two terms are all that semantic. They strike me as
rather arbitrary. I could equally accept a definition that said bold
equals
emphasis, and italics equals strong.

So, please educate me.

Thanks,
Janina
Phill Jenkins
2018-08-07 22:25:37 UTC
Permalink
Janina,
hope you are well, long time no talk directly.
Post by Phill Jenkins
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.
Let me echo what David Woolley <***@david-woolley.me.uk> said in this
thread, that this was a problem introduced from the very early days of
HTML - even earlier than when I started on HTML 3 during the browser war
days, and even earlier than when you and I met regarding the Java
Self-Voicing Kit in the late 90's, haha:

This issue is basically the result of an early aberration in HTML
resulting in B and I being introduced as presentational markup, in what
was otherwise a semantic markup language. Unfortunately, they will be
impossible to dislodge as graphic designers think in terms of
presentation not semantics, and screen reader developers go by trying to
make the best of what is in the real world, so tend to reinforce
misuses, and not support minority, but correct, use.

June 1993 - The HTML 1.2 definitions are:
https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt

B Boldface, where available, otherwise
alternative mapping allowed.

STRONG Stronger emphasis, typically bold.

where it is clear that B was [originally] only intended to have
presentational semantics.

My recollection is that original intention of <b> has drifted here and
there over the years, especially when CSS was introduced, but folks still
fought for <b> to remain because of some implied semantic meaning that
perhaps wasn't there in the original HTML 1.2 definiton, but seems to be
there now, and more importantly remains until deprecated. I guess I would
have to do a more thorough search to find more e-mail posts and working
group notes. I think we have to deal with the fact that <b> is still a
semantic tag today, even though it may have been originally only intended
for presentation markup. Strong is also a semantinc tag still today and
originally less like pure presentation markup. When cite, heading, quote,
and all the other semantic mark-up gets added to the conversation it can
and has caused confusion and conflates the issues.

However, there is the valid use case where a part of the heading, or a
part of a quote needs to be emphasized, or bolded, or made strong, or
itilaized. So that use case is possible, is valid HTML, and should be
accessible too. Whether or not suported by the screen reader at all, and
if it is, can it be chosen to be rendered by the screen reader user
differently (different voices associated with the bold or strong tag as
apart from the regular heading voice or apart from the regular quote
voice) or not depends on their verbosity settings on their screen reader.

The question that started this threat was about failing a web site because
they used <b> and were told to use <strong> instead - as a failure to
meeting SC 1.3.1, which is the issue I have, because it is NOT a failure
in and of itself to use <b> instead of <strong>. I do believe it is a SC
1.3.1 failure if <b> and/or <strong> is used inplace of a better/correct
semantic tag that should have been used, such as incorrectly using
<strong> instead of correctly using <h1>, etc.
___________
Regards,
Phill Jenkins
Check out the new system for requesting an IBM product Accessibility
Conformance Report VPAT® at able.ibm.com/request
***@us.ibm.com
Senior Engineer & Accessibility Executive
IBM Research Accessibility
linkedin.com/in/philljenkins/
ibm.com/able
twitter.com/IBMAccess
ageandability.com



From: Janina Sajka <***@rednote.net>
To: Phill Jenkins <***@us.ibm.com>
Cc: Duff Johnson <***@duff-johnson.com>, w3c-wai-ig
<w3c-wai-***@w3.org>
Date: 08/07/2018 12:57 PM
Subject: Re: Bold vs Strong



Phil, All:

I recognize WCAG has been suggesting that "strong" and "emphasis" are
semantic designations for many, many years.

May I ask where we got this definition? I can't seem to find any grammar
text that speaks of bold or italics using such terms. So, what's our
authority?

I'd like to know because I, myself, am constantly getting them confused
in my own mind. I don't have that same problem with bold or italic, even
those are type-faces I haven't seen for myself in decades.

Let me hasten to underscore my strong support for semantic markup. I'm
just not convinced these two terms are all that semantic. They strike me
as rather arbitrary. I could equally accept a definition that said bold
equals emphasis, and italics equals strong.

So, please educate me.

Thanks,

Janina
Post by Phill Jenkins
Substituting <strong> for <b> or <i> would just.. blow all this up, and
make such documents far harder - in principle - for AT users to read, no?
"If IT is present and its value is not Stamp, it's Name shall not be present. "
I am not and I do not think others are suggesting substituting bold with
italics ,
<b> for <i>, or
<strong>> for <em>
so even in your hacked example, the distinction remains substituting <b>
for <strong> and <i> for <em>.
The accessibility issue, meaning success criteria, is more about semantic
equivalence, not visual presentation equivalence. In other words, there
is not requirement that all headings look visually the same, for example,
just that one use the semantic heading <h1> element to identify the
heading that the author intended to be identified by the reader as is in
fact a heading without reference to the visual rendering alone.
___________
Regards,
Phill Jenkins
Senior Engineer & Accessibility Executive
IBM Research Accessibility
Date: 08/07/2018 08:30 AM
Subject: Re: Bold vs Strong
There?s an aspect that I?ve not seen covered in the discussion so far on
this point.
There are many use cases (especially in STEM publications) in which
italics and bold have specific uses that are announced in the document.
For example, italics may be used to indicate values. Bold may be used to
indicate dictionary key names.
Discerning the meaning of the content without reference to bold and
italics usage in such cases could lead to confusion. Here?s a (slightly
"If IT is present and its value is not Stamp, it's Name shall not be present. "
Substituting <strong> for <b> or <i> would just.. blow all this up, and
make such documents far harder - in principle - for AT users to read, no?
Duff.
Dear Vinil,
Richard Ishida (W3C) wrote an article on this issue in 2010 (see
https://www.w3.org/International/questions/qa-b-and-i-tags
).
Post by Phill Jenkins
His quick answer was as follows - ?You should always bear in mind that
the content of a b element may not always be bold, and that of an i
element may not always be italic. The actual style is dependent on the CSS
style definitions. You should also bear in mind that bold and italic may
not be the preferred style for content in certain languages.
You should not use b and i tags if there is a more descriptive and
relevant tag available. If you do use them, it is usually better to add
class attributes that describe the intended meaning of the markup, so that
you can distinguish one use from another. ?
Furthermore the HTML5 specification states that ?The b element
represents
Post by Phill Jenkins
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?
As a result I believe that your client has a strong case for asking you to
replace the <b> element with <strong> or <em> or <cite>.
Be very wary of anyone who claims that, because there is no specified
failure criteria, they can use an element in a situation where it is not
?best practice?. just because everyone else is doing it.
<b> enhances the visual effect, but <strong> enhances the meaning as well.
Regards
Richard Warren
Technical Manager
Website Auditing Ltd
www.userite.com
From: Vinil Peter
Sent: Sunday, August 05, 2018 4:10 PM
Subject: Bold vs Strong
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
--
Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:
http://a11y.org


The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures
http://www.w3.org/wai/apa
Patrick H. Lauke
2018-08-07 15:01:09 UTC
Permalink
There’s an aspect that I’ve not seen covered in the discussion so far on
this point.
There are many use cases (especially in STEM publications) in which
italics and bold have specific uses that are announced in the document.
...
Substituting <strong> for <b> or <i> would just.. blow all this up, and
make such documents far harder - in principle -  for AT users to read, no?
And of course, nobody is suggesting that.

P
--
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
Pyatt, Elizabeth J
2018-08-07 15:54:20 UTC
Permalink
This is a good example of why I think we should re-think this issue.

There are uses of bold and italics which have nothing to do with emphasis. Math is one (and there is a VAR tag), and another are cases like , citation (i.e. the CITE tag), italics for foreign language words (no tag yet) and so forth.

VAR tag https://developer.mozilla.org/en-US/docs/Web/HTML/Element/var

Elizabeth

P.S. Today, I think MathML is one answer for this particular case, but I’m not sure if it would cover everything.
There’s an aspect that I’ve not seen covered in the discussion so far on this point.
There are many use cases (especially in STEM publications) in which italics and bold have specific uses that are announced in the document.
For example, italics may be used to indicate values. Bold may be used to indicate dictionary key names.
"If IT is present and its value is not Stamp, it's Name shall not be present. "
Substituting <strong> for <b> or <i> would just.. blow all this up, and make such documents far harder - in principle - for AT users to read, no?
Duff.
Post by Userite
Dear Vinil,
Richard Ishida (W3C) wrote an article on this issue in 2010 (see https://www.w3.org/International/questions/qa-b-and-i-tags ).
His quick answer was as follows - “You should always bear in mind that the content of a b element may not always be bold, and that of an i element may not always be italic. The actual style is dependent on the CSS style definitions. You should also bear in mind that bold and italic may not be the preferred style for content in certain languages.
You should not use b and i tags if there is a more descriptive and relevant tag available. If you do use them, it is usually better to add class attributes that describe the intended meaning of the markup, so that you can distinguish one use from another. “
Furthermore the HTML5 specification states that “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”
As a result I believe that your client has a strong case for asking you to replace the <b> element with <strong> or <em> or <cite>.
Be very wary of anyone who claims that, because there is no specified failure criteria, they can use an element in a situation where it is not “best practice”. just because everyone else is doing it.
<b> enhances the visual effect, but <strong> enhances the meaning as well.
Regards
Richard Warren
Technical Manager
Website Auditing Ltd
www.userite.com
From: Vinil Peter
Sent: Sunday, August 05, 2018 4:10 PM
Subject: Bold vs Strong
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
***@psu.edu, (814) 865-0805 or (814) 865-2030 (Main Office)

The 300 Building, 112
304 West College Avenue
David Ashleydale
2018-08-07 17:17:44 UTC
Permalink
We’re definitely getting very abstract here. Vinil, could you give us
specific examples of items that were called out by the tester as being
incorrect? I think there might be some false positives in that report
and/or there could be cases where we would have another recommended way of
emphasizing text if it really does need to be emphasized.

David Ashleydale
Post by Pyatt, Elizabeth J
This is a good example of why I think we should re-think this issue.
There are uses of bold and italics which have nothing to do with emphasis.
Math is one (and there is a VAR tag), and another are cases like , citation
(i.e. the CITE tag), italics for foreign language words (no tag yet) and so
forth.
VAR tag https://developer.mozilla.org/en-US/docs/Web/HTML/Element/var
Elizabeth
P.S. Today, I think MathML is one answer for this particular case, but I’m
not sure if it would cover everything.
Post by Duff Johnson
There’s an aspect that I’ve not seen covered in the discussion so far on
this point.
Post by Duff Johnson
There are many use cases (especially in STEM publications) in which
italics and bold have specific uses that are announced in the document.
Post by Duff Johnson
For example, italics may be used to indicate values. Bold may be used to
indicate dictionary key names.
Post by Duff Johnson
Discerning the meaning of the content without reference to bold and
italics usage in such cases could lead to confusion. Here’s a (slightly
Post by Duff Johnson
"If IT is present and its value is not Stamp, it's Name shall not be
present. "
Post by Duff Johnson
Substituting <strong> for <b> or <i> would just.. blow all this up, and
make such documents far harder - in principle - for AT users to read, no?
Post by Duff Johnson
Duff.
Post by Userite
Dear Vinil,
Richard Ishida (W3C) wrote an article on this issue in 2010 (see
https://www.w3.org/International/questions/qa-b-and-i-tags ).
Post by Duff Johnson
Post by Userite
His quick answer was as follows - “You should always bear in mind that
the content of a b element may not always be bold, and that of an i element
may not always be italic. The actual style is dependent on the CSS style
definitions. You should also bear in mind that bold and italic may not be
the preferred style for content in certain languages.
Post by Duff Johnson
Post by Userite
You should not use b and i tags if there is a more descriptive and
relevant tag available. If you do use them, it is usually better to add
class attributes that describe the intended meaning of the markup, so that
you can distinguish one use from another. “
Post by Duff Johnson
Post by Userite
Furthermore the HTML5 specification states that “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”
Post by Duff Johnson
Post by Userite
As a result I believe that your client has a strong case for asking you
to replace the <b> element with <strong> or <em> or <cite>.
Post by Duff Johnson
Post by Userite
Be very wary of anyone who claims that, because there is no specified
failure criteria, they can use an element in a situation where it is not
“best practice”. just because everyone else is doing it.
Post by Duff Johnson
Post by Userite
<b> enhances the visual effect, but <strong> enhances the meaning as
well.
Post by Duff Johnson
Post by Userite
Regards
Richard Warren
Technical Manager
Website Auditing Ltd
www.userite.com
From: Vinil Peter
Sent: Sunday, August 05, 2018 4:10 PM
Subject: Bold vs Strong
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.
Post by Duff Johnson
Post by Userite
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.
Post by Duff Johnson
Post by Userite
Is my recommendation correct or am I missing something? What your
thoughts and have you come across any such debate?
Post by Duff Johnson
Post by Userite
Regards,
Vinil Peter, PMP
=-=-=-=-=-=-=-=-=-=-=-=-=
Elizabeth J. Pyatt, Ph.D.
Accessibility IT Consultant
Teaching and Learning with Technology
Penn State University
The 300 Building, 112
304 West College Avenue
State College, PA 16801
accessibility.psu.edu
Taliesin Smith
2018-09-06 12:45:45 UTC
Permalink
Hi Folks,

I found a tweet yesterday (thanks Aidan Tierney) that linked to an A List Apart article on Conversational Semantics by Aaron Gustafson. I think this article sheds some light on this conversation, so here is the url:
https://alistapart.com/article/conversational-semantics <https://alistapart.com/article/conversational-semantics>

Taliesin
Post by Vinil Peter
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
Katie Haritos-Shea
2018-09-06 13:26:33 UTC
Permalink
I thought <b> and <i> originally came out of SGML.....before HTML

** katie **

*Katie Haritos-Shea*

*Principal ICT Accessibility Architect, **Board Member and W3C Advisory
Committee Rep for Knowbility *

*WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy,* *IAAP CPACC+WAS = *
*CPWA* <http://www.accessibilityassociation.org/cpwacertificants>

*Cell: **703-371-5545 <703-371-5545>** |* ****@gmail.com
<***@gmail.com>* *| **Oakton, VA **|* *LinkedIn Profile
<http://www.linkedin.com/in/katieharitosshea/>*

People may forget exactly what it was that you said or did, but they will
never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to
dictate where we are going.
Post by Taliesin Smith
Hi Folks,
I found a tweet yesterday (thanks Aidan Tierney) that linked to an A List
Apart article on *Conversational Semantics* by *Aaron Gustafson*. I think
https://alistapart.com/article/conversational-semantics
Taliesin
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
David Woolley
2018-09-06 20:47:42 UTC
Permalink
Post by Katie Haritos-Shea
I thought <b> and <i> originally came out of SGML.....before HTML
SGML has no pre-defined tags. It is the <tag>....</tag> construct, not
any particular value of tag, that comes from SGML (although the original
versions of HTML complied with SGML more fully than that).
Chaals Nevile
2018-09-06 21:56:25 UTC
Permalink
On Thu, 06 Sep 2018 22:47:42 +0200, David Woolley
Post by David Woolley
Post by Katie Haritos-Shea
I thought <b> and <i> originally came out of SGML.....before HTML
SGML has no pre-defined tags. It is the <tag>....</tag> construct, not
any particular value of tag, that comes from SGML (although the original
versions of HTML complied with SGML more fully than that).
I believe that a number of very old HTML tags (I know this is the case for
the h1-h6 set) were essentially re-using an SGML vocabulary that happened
to be familiar to many people who might have been the "first users" of
HTML, in CERN. The reason for adopting them was to ease transition to HTML
(which was SGML-like, but at the very beginning didn't actually have the
formal structure SGML did - that came later on, along with the development
of XML as a formal replacement for SGML).

'strong' and 'em' - and lots of other things, some good ideas and some
probably not - were introduced in HTML 4 - which was SGML based, attempted
to have robust semantics that allowed for things like device independence
and decent accessibility support, and so on. Early work on HTML5 also
tried to assign more semantics to things that hadn't had them before as
well as add another new set of semantic elements. Some of that took hold,
some of it didn't.

For what it's worth, "semantics" - understanding meaning and how people
use it - is really really hard. So it isn't surprising that quite often
efforts to make it work more like someone thinks it should don't get
global traction and success.

cheers
--
Chaals: Charles (McCathie) Nevile find more at https://yandex.com
Using Opera's long-abandoned mail client: http://www.opera.com/mail/
Is there really still nothing better?
Andrew Cunningham
2018-09-10 02:14:41 UTC
Permalink
Although part of the problem is that with em and strong and various
other elements,. HTML not only gave them semantic meanings but also
gave them a default Style/presentation that does not universally
apply. Depending on the languages it is common for me to need to first
negate existing default styles and then apply an appropriate style to
indicate the semantic meaning visually.
Post by Chaals Nevile
On Thu, 06 Sep 2018 22:47:42 +0200, David Woolley
Post by David Woolley
Post by Katie Haritos-Shea
I thought <b> and <i> originally came out of SGML.....before HTML
SGML has no pre-defined tags. It is the <tag>....</tag> construct, not
any particular value of tag, that comes from SGML (although the original
versions of HTML complied with SGML more fully than that).
I believe that a number of very old HTML tags (I know this is the case for
the h1-h6 set) were essentially re-using an SGML vocabulary that happened
to be familiar to many people who might have been the "first users" of
HTML, in CERN. The reason for adopting them was to ease transition to HTML
(which was SGML-like, but at the very beginning didn't actually have the
formal structure SGML did - that came later on, along with the development
of XML as a formal replacement for SGML).
'strong' and 'em' - and lots of other things, some good ideas and some
probably not - were introduced in HTML 4 - which was SGML based, attempted
to have robust semantics that allowed for things like device independence
and decent accessibility support, and so on. Early work on HTML5 also
tried to assign more semantics to things that hadn't had them before as
well as add another new set of semantic elements. Some of that took hold,
some of it didn't.
For what it's worth, "semantics" - understanding meaning and how people
use it - is really really hard. So it isn't surprising that quite often
efforts to make it work more like someone thinks it should don't get
global traction and success.
cheers
--
Chaals: Charles (McCathie) Nevile find more at https://yandex.com
Using Opera's long-abandoned mail client: http://www.opera.com/mail/
Is there really still nothing better?
---

Andrew Cunningham
***@gmail.com

Michael A. Peters
2018-09-07 00:01:36 UTC
Permalink
Post by Taliesin Smith
Hi Folks,
I found a tweet yesterday (thanks Aidan Tierney) that linked to an A
List Apart article on /Conversational Semantics/ by *Aaron Gustafson*. I
think this article sheds some light on this conversation, so here is the
https://alistapart.com/article/conversational-semantics
Taliesin
Not specifically related, but I recently have been doing some
translation of a Fraktur script (A German Blackletter) document.

When they wanted to emphasize something, how we often use Italics, they
added extra spacing between the letter - but without breaking up ligatures.

I'm not positive on this yet - but it seems that at least of the
typographers when they wanted the equivalent of our strong - what they
would do is use a slightly large font size, start it with upper case,
and use alternate upper case letters.

There are a few places where the lower cases match but look a little
bigger, that start with an upper case that is clearly a little different
than the same upper case elsewhere in the document.

Anyway these are all reasons to use semantic over descriptive tags.
Semantic allows the typesetting to be interpreted according to
convention, and in accessibility that convention often isn't visible.

QUESTION

I'm thinking there needs to be a book/article name tag too. When I
typeset, I tend to italicize and underline those - but many just italicize.

But if visual is being used to convey context then a semantic tag/label
would be good to have. Is there one?
Patrick H. Lauke
2018-09-07 00:15:42 UTC
Permalink
On 07/09/2018 01:01, Michael A. Peters wrote:
[...]
Post by Michael A. Peters
QUESTION
I'm thinking there needs to be a book/article name tag too. When I
typeset, I tend to italicize and underline those - but many just italicize.
But if visual is being used to convey context then a semantic tag/label
would be good to have. Is there one?
<cite> is your best bet
https://www.w3.org/TR/html52/textlevel-semantics.html#the-cite-element
--
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
Loading...