- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Mon, 6 Aug 2018 08:17:49 -0700
- To: w3c-wai-ig@w3.org
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 >>
Received on Monday, 6 August 2018 15:36:00 UTC