- From: Pyatt, Elizabeth J <ejp10@psu.edu>
- Date: Mon, 6 Aug 2018 16:12:39 +0000
- To: "Michael A. Peters" <mpeters@domblogger.net>
- CC: w3c-wai-ig <w3c-wai-ig@w3.org>
Like Michael, I’ve also used CSS to make the appearance of STRONG distinct from B. For instance, on some sites I maintain, STRONG is a WCAG 2.0 contrast compliant crimson red indicating very strong emphasis (such as for a warning). I think this preserves the semantics, but because it’s not indicated by default on a screen reader, some extra text should be included to indicate the very strong emphasis. I should also add that making STRONG crimson red has seriously confused other content editors. Since they think of STRONG as just the “accessible” B tag, the CSS usage is considered foreign. This could be a chance to help people re-think the semantics as Michael says, but I haven’t seen most developers follow this path. It’s good to consider semantics, but unless a clear semantic distinction is really made within the web content, even for sighted users, then the point is moot. I sincerely doubt sighted users/developers would ever understand the semantic distinction between B and STRONG without a distinct visual cue as well. Therefore, the usage will always be muddy unless such a change is implemented. I’m not saying it can’t happen…but that it hasn’t happened so far. FYI - If screen reader technology evolves, then CSS can be used to spot and correct errant tags, but sighted developers will again need to be seriously re-trained. Elizabeth P.S. I compare this STRONG/B contrast to the distinction of "who/whom.” Even though it’s supposed to exist in written English, the reality is that almost no one makes this distinction in spoken English (or even much in written English really). Although a semantic cue has been theoretically lost, people speaking English are rarely confused so enforcing the rule may be moot. > On Aug 6, 2018, at 11:17 AM, Michael A. Peters <mpeters@domblogger.net> wrote: > > One of the reasons I like strong / em is that I can use the semantic strong / em and then use css to make the visual distinction different that b / i when needed. > > I rarely do that but for example - in an aside I normally have the the text italicized already so in an aside, I tend to use css to use more font weight with the em tag and both more font weight and underline with the strong tag. > > Technically can do that with b / i tags as well - but using the CSS to override what tags historically mean isn't something I like. > > But em / strong have semantic meaning and the display of bold / italic is just a default intended to be altered as needed. > > Screen readers may not currently distinguish between b / i and strong / em but that doesn't make the difference meaningless. > > On 08/06/2018 07:24 AM, Pyatt, Elizabeth J wrote: >> I concur with Mohith. >> >> Because most screen readers and visual browsers treat STRONG/B identically by default, the distinction seems irrelevant for now. >> >> It is important to note that screen readers ignore both STRONG/B tags along with EM/I and color changes by default. Use either one as needed assuming that they convey little semantic info to screen readers. >> >> If you really are using STRONG/B or EM/I for major inline emphasis, you may want to add text like Note: or Warning: or Important: This was the recommendation I got from my screen reader colleagues. >> >> It's also important to tag headings consistently regardless of other formatting tags. Some cautions etc. can be headings. >> >> My two cents. >> >> Elizabeth J. Pyatt, Ph.D. >> Sent from my iPad >> >>> On Aug 6, 2018, at 1:32 AM, Mohith BP <mohith.ckm49@gmail.com> wrote: >>> >>> Hi Vinil, >>> >>> Though WCAG recommends using <em> and <strong> elements, however, the >>> support from the major screen readers for these 2 tags is nill. >>> Please refer: >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG20%2FTechniques%2Fua-notes%2Fhtml%23H49&data=02%7C01%7Cejp10%40psu.edu%7C5fac45f8eafa433d7cea08d5fb5e10c1%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636691303780330250&sdata=n4c9uZ8knlvd0aYyKDm0a1GXB2vKjsGVJidOO4dHwQw%3D&reserved=0 >>> >>> >>> Thanks & Regards, >>> Mohith B. P. >>> >>>> On 8/5/18, Vinil Peter <vinilpeter.wcag@gmail.com> wrote: >>>> Dear colleagues, >>>> >>>> I have been asked to provide my thoughts on a debate on the use of bold <b> >>>> and strong <strong> for one of my clients. The client's internal >>>> accessibility testing team marked all the instances where <b> was used as >>>> errors and recommended to change them to <strong> so that screen readers >>>> read out the text with added emphasis. This has brought their quality and >>>> compliance scores down drastically. The client's developers are unhappy >>>> about this and claim that they should not be marked down as there is no >>>> clear guideline or fine print that mandates use of <strong> over <b>. >>>> Moreover, W3C has not deprecated <b> yet and it's usage is still permitted. >>>> <b> has been in use since ages and asking to replace all bold text with >>>> strong is like declaring that use of <b> should be banned henceforth. >>>> >>>> I am planning to give my recommendation to use <strong> in headers or >>>> functionality names etc. if the text is bold as per design, while it is >>>> still fair to allow use of <b> for other bold text. The 'appropriate usage' >>>> of bold or strong is finally the designer's call as there is no clear >>>> guideline. >>>> >>>> Is my recommendation correct or am I missing something? What your thoughts >>>> and have you come across any such debate? >>>> >>>> Regards, >>>> Vinil Peter, PMP >>> > > =-=-=-=-=-=-=-=-=-=-=-=-= Elizabeth J. Pyatt, Ph.D. Accessibility IT Consultant Teaching and Learning with Technology Penn State University ejp10@psu.edu, (814) 865-0805 or (814) 865-2030 (Main Office) The 300 Building, 112 304 West College Avenue State College, PA 16801 accessibility.psu.edu
Received on Monday, 6 August 2018 16:13:09 UTC