Screen Readers support for text level HTML semantics

A long time ago (2008) I wrote an article: Screen Readers lack emphasis. At the time, 15 years ago, the screen readers tested did not signify the semantics of text level elements and did not signify, by default, font styles associated with such elements.

Notes:

I am not suggesting either behaviour is required or desirable. In 2008 role semantics did not exist for any of these elements. Most have recently been defined in ARIA 1.2.

Now, how do screen readers support such semantics?

Updated: 7th September 2023 with correct information about JAWS (lack of support) for role=insertion and role=deletion.

Updated: 11th August 2023 with information about the <s> element.

Using the default settings:

Notes:

• None of the Screen Readers tested convey strong or em semantics to users. NVDA did for a while but “Having emphasis reported by default has been extremely unpopular with users and resulted in a lot of complaints about NVDA 2015.4. The unfortunate reality is that emphasis is very much over-used in the wild.” source: Comment on GitHub by James Teh
• JAWS and NVDA convey ins, del and mark semantics. There is no reliance on the visual style.
• NVDA supports role=insertion and role=deletion JAWS does not.
• VoiceOver on iOS (Not on macOS) conveys ins and del. There is no reliance on the visual style. 
• Narrator does not convey any HTML semantics.

Test file: text level semantics – no styles

See the Pen text level semantics – no styles by steve faulkner (@stevef) on CodePen.

What are the semantics exposed in the Browser Accessibility Tree?

Notes:

• No browsers expose strong or em element role semantics in the accessibility tree.
• All browsers expose semantics for explicitly defined roles, only some for their implicit counterparts. Though this does not mean that SRs convey these semantics to users.
• The term xml-roles is used as a property name for roles when exposed as an iA2 object attribute property, it’s an echo of ARIA long past, when roles had a namespace prefix. It is now merely a naming convention, nothing more.
• How semantics are exposed in browsers differs across accessibility APIs. For the mark role/element in AXAPI the description is an accessibility wrapper for the text rather than being a property (role/subrole) of the containing AXGroup. This is not displayed in the in-browser accessibility panel of the developer tools. To check for its presence you need to use the macOS X Accessibility Inspector
  
  
• Refer to HTML Accessibility API Mappings 1.0 and Core Accessibility API Mappings 1.2 for expected API browser implementation details

Screen Readers and text formatting

With style reporting enabled (if available):

Notes:

• Of the screen readers (SRs) tested, all have some form of support for conveying text formatting styles such as bold, italics except VoiceOver on iOS.
• All are off by default, but can be enabled though user settings.
• The level of control over what is conveyed to users varies widely across SRs.
• The most complete style announcements are provided by JAWS, NVDA and Narrator.
• The most configurable is JAWS via speech and sound schemes.
• JAWS does not announce/indicate strikethrough style. (It does in a Word document).

How to enable reporting of document style:

1. Narrator- text details
2. NVDA – document formatting
3. JAWS – Speech and Sounds Schemes
4. VoiceOver – text attribute changes

test file: text level semantics – default browser styles

See the Pen text level semantics – default browser styles by steve faulkner (@stevef) on CodePen.

Discussion

Since my last look at this 15 years ago 

• Exposure of semantics for role=strong, role=emphasis, ins, del and mark has been implemented in all modern browsers.
• The Windows Screen readers; JAWS and NVDA provide good support for conveying ins, del and mark semantics using the information providing in the browser accessibility tree.
• role=strong and role=emphasis semantics although exposed by browsers are not supported by any SR
• Visual CSS styles of bold and italic are well supported across all SRs (on desktop) and will be identified to users when the appropriate setting are enabled.

WCAG SC 1.3.1:Info and Relationships is often cited as a reason why strong and em must be used and Technique H49:Using semantic markup to mark emphasized or special text provides examples of “Using the em and strong elements to emphasize text” In practice their use does nothing for screen reader users at least, nothing that the i and b elements don’t provide (with their default styles).

Simply put the strong and em are not accessibility supported and therefore should not be a factor in accessing conformance with SC 1.3.1:Info and Relationships. Visually identifying emphasised and important text via CSS styles is an accessibility supported method and will be conveyed to SR users when they have the required settings enabled. This can be achieved by style declarations alone, it does not require the use of elements with particular semantics.  By all means encourage the appropriate use of em and strong elements, but don’t require it.

With thanks to Ian Lloyd and Jonny James for providing macOS testing.