RE: Bold vs Strong [SEC=UNOFFICIAL]

Paul wrote:
<Change the coding to <strong> if the intention is to convey additional meaning.  Leave it as <b> if the intention is presentational only.>

my understanding would be to change the coding to <span> with a CSS font-weight property if the intention (how is this determined?) is presentational.

And use <b>,<i>,<strong><em> etc. as defined in the current HTML specification (take you’re pick of which one – they are the same in this regard) so that ‘additional meaning’ might be derived (and unambiguous) at some point in the future when screen reader manufacturers implement proper support?

Does anyone know if there is a technical limitation to differentiating between these two techniques in the accessibility stack?

Otherwise wholeheartedly agree – classic case of where automation is about discovery and aggregating information rather than testing.

My two cents worth ….

Adam


From: Paul E Matthews <PaulE.Matthews@ato.gov.au>
Sent: Wednesday, 8 August 2018 10:46 AM
To: Vinil Peter <vinilpeter.wcag@gmail.com>
Cc: w3c-wai-ig@w3.org
Subject: RE: Bold vs Strong [SEC=UNOFFICIAL]

Hi Vinil (et al)

RE:  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.

I have been following this discussion with interest – and I’ve learnt a few things along the way – but I think we need to get back to the original issue (above).  To me, this is a clear example of an automated test (“marked *all* the instances”) that is not useful or accurate.  If your aim is to remove this error from the report, globally replacing <b> with <strong> will do it.  But is that the aim of accessibility testing?

My advice is to explain to your client that the use of <b> is *not* an error – it’s an indication that human intervention is required.  Each use should be based on an assessment of what is intended (emphasis or presentation).

·         It may be the case that most <b> tags should be <strong> tags but an automated test can’t tell you for sure.

·         It may be the case that most <strong> tags are correct (following a global change) but automated testing won’t tell you this either.

Instead of globally replacing <b> with <strong>, instigate an ongoing content review process that includes an assessment of each <b>olded piece of text.  Change the coding to <strong> if the intention is to convey additional meaning.  Leave it as <b> if the intention is presentational only.

This article – http://www.karlgroves.com/2017/03/24/automated-web-accessibility-testing-tools-are-not-judges/ (or a synopsis) – may help explain the reality of accessibility assessments to your clients.

Hope this helps …

Regards
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Paul E. Matthews
ATO Community User Interface Designer


From: Userite [mailto:richard@userite.com]
Sent: Tuesday, 7 August 2018 7:52 PM
To: Vinil Peter; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: Re: Bold vs Strong

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<http://www.userite.com>



From: Vinil Peter<mailto:vinilpeter.wcag@gmail.com>
Sent: Sunday, August 05, 2018 4:10 PM
To: w3c-wai-ig@w3.org<mailto: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
**********************************************************************
IMPORTANT
    The information transmitted is for the use of the intended
recipient only and may contain confidential and/or legally
privileged material. Any review, re-transmission, disclosure,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited and may result in
severe penalties. If you have received this e-mail in error
please notify the Privacy Hotline of the Australian Taxation
Office, telephone 1300 661 542 and delete all copies of this
transmission together with any attachments.
*********************************************************************