- From: Phill Jenkins <pjenkins@us.ibm.com>
- Date: Tue, 7 Aug 2018 17:25:37 -0500
- To: Janina Sajka <janina@rednote.net>
- Cc: Duff Johnson <duff@duff-johnson.com>, w3c-wai-ig <w3c-wai-ig@w3.org>
- Message-Id: <OFB58D9CCD.30F10816-ON862582E2.00696C6B-862582E2.007B32C1@notes.na.collabserv.c>
Janina, hope you are well, long time no talk directly. On 07/08/18 05:45, Phill Jenkins wrote: > 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 <forums@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 pjenkins@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 <janina@rednote.net> To: Phill Jenkins <pjenkins@us.ibm.com> Cc: Duff Johnson <duff@duff-johnson.com>, w3c-wai-ig <w3c-wai-ig@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 Phill Jenkins writes: > 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 > pjenkins@us.ibm.com > Senior Engineer & Accessibility Executive > IBM Research Accessibility > > > > > From: Duff Johnson <duff@duff-johnson.com> > To: w3c-wai-ig <w3c-wai-ig@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 <richard@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-ig@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 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
Received on Tuesday, 7 August 2018 22:26:10 UTC