Bruce Lawson's personal site

There has been a couple of blogposts recently about text-level HTML semantics and assistive technology; for example, You’re using <em> wrong and Accessibility: Bold vs. Strong and Italic vs. Emphasis, the latter of which says

The Strong tag, <strong>, and the Emphasis tag, <em>, are considered Semantic Markup that allows for added meaning to your content. It serves as an indication to a screen reader of how something should be understood.

Whenever I read “some browsers” or “some screenreaders”, I always ask “but which ones?”, as did Ilya Streltsyn, who asked me “what is the current state of the text-level semantics in HTML reality?”

Léonie Watson to the rescue! Over Twitter, Watters wrote

Most are capable of reporting these things on demand, but do not as standard. So you don’t hear the text/font characteristics being announced as you read, but you can query a character/word etc. to discover its characteristics. This is based on the visual presentation of the text though, rather than through any recognition of the elements themselves (which as @SelenIT2 notes, are not mapped to the acc API).

Ilya (@SelenIT2) noted that “almost no text-level semantic element has a direct mapping to any accessible object”, linking to HTML Accessibility API Mappings 1.0 to demonstrate. This means that even if a screenreader vendor wanted to pass that information to a user, they can’t, because the browsers don’t expose the information to the Accessibility Tree that assistive technology hooks into.

Ilya also pointed my to a GitHub issue on the NVDA screenreader “Semantic support (not just style support) for del and ins on web pages”, in which the developers pose an interesting usability conundrum:

While I normally push for semantics over style, I’ve always found elements like this to be tricky. Strong and em, for example, don’t really mean anything to most people, even though they have more semantic meaning than bold or italic. That said, I think ins and del would mean more to most users semantically speaking…

It’s worth noting that we do support strike, super and sub. We just don’t report them by default. Also, while you make valid points, the reality is that we must always consider the concerns of our users over those of authors. If users find that it causes excessive verbosity, that is reason enough for this not to be a default…

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. I had serious misgivings that this would be the result when we implemented this and it seems these unfortunately turned out to be quite warranted. As such, we’ve now disabled this by default, though the option is still there for those that want it.

So, should we stop using text-level semantics? Well, <strong>no</strong>. They continue to add meaning to sighted users, and as Watters says, some AT users can benefit from them. But don’t over-use them. Like adding title attributes to all your links, there’s such a thing as too much accessibility.

Update March 2020: Watters reports “The latest Jaws update adds support for content marked up in the del and ins elements in Firefox and the Chromium browsers (though not Edge original or IE)”

(Last Updated on 17 March 2020)

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

5 Responses to “ Screenreader support for text-level semantics ”

Leave a Reply