I like to blog little veins of thought as I see them. We recently linked to an article by Facundo Corradini calling out a tweet of ours where we used an
<em> where we probably should have used an
Bruce Lawson checks if screen readers are the victims of these semantic mistakes…
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 I suppose is to say that if you’re really fretting about screen readers misinterpreting the nuanced usage of your semantic emphasis… you can relax on that one.
Bruce’s article led me toward Steve Faulkner’s article “Screen Readers lack emphasis” from 2008.
Using the semantic elements strong and em does not convey any useful information to users of JAWS or Window Eyes under typical browsing conditions. While it is good to know this, it is not a reason to not use these elements to convey meaning. Accessibility is not just about people with vision impairment, it’s about all user’s with disabilities, and web standards is not just about accessibility.
So, not much has changed there in a decade. It’s unclear to me if things should change here or not, but if virtual voices are improving, it stands to reason they could get better at voice inflections that convey emphasis. I certainly am thinking of voice emphasis when I write those HTML tags.
This idea of too much accessibility has been a bit of a theme.
- Eric Baily addressed how WIA-ARIA, when misused, can do more harm than good.
- Jared Smith responds to a question from a student: “Is it possible for a web page to be overly accessible?”
- 11 years ago, Patrick H. Lauke created a presentation called Too Much Accessibility that covers things like being over-explicit.
Please don’t read this article as suggesting that we worry too much about accessibility — only that it’s possible to worry about the wrong things and even screw up accessibility in the process, just like anything else.
Great little tidbit of thinking here. tnx!
CSS Strikethrough is another that isn’t really communicated by screen readers but has a ton of visual meaning. e.g. Sale Price / Regular Price. Not a semantics thing, because the strike tag is obsolete, but in the same arena. The best way to know is to test. Creative aria-label or visually hidden text can build meaning in this case.
The <s> element is not deprecated (it was the <strike> element that got deprecated, because for whatever reason there were two of them…) and in fact sale prices are precisely the provided example in the specs: https://www.w3.org/TR/html51/textlevel-semantics.html#the-s-element
But yeah, screen readers won’t announce it (to reduce verbosity) so you have to be careful with how you word the text within that tag so it still sounds reasonable even without the clue.
<del>tag to provide semantics for something like a regular price that’s been superceded by a sale price, and attach CSS strikethrough to that.
<del>element is implemented in all browsers with a strikethrough styling, but no OS accessibility API recognizes it with any special meaning so semantically its equal to a neutral span element.
The problem lays with old OS accessibility APIs that overall lacks most text level semantics.
How can accessibility be too much? This sounds like an excuse to be lazy. Don’t only care about the current state. Also care about the future state.
I think the title doesn’t really convey the point as well as I think the points in the article do. Essentially it’s possible to recklessly throw aria attributes onto elements thinking that you are helping users when that in itself can actually cause more problems.
Usually when I see a lot of aria attributes it is a sign of a larger problem in terms of design. For example if using
role="button"on something like a Div. Sure there are instances when you can do that, but a lot of the time a normal button would suffice and actually be far better to use.
The best way to make a site accessible is through well structured semantic markup, and intentionally accessible design that follows best practices. It shouldn’t require much work or thought beyond that and if you find yourself having to do that, something is wrong with your initial design.
This feels like an “I read the title and now I’m going to jump to the comment section” comment, yeah?
@chris that seems to be jumping to a conclusion a little. Here’s why I agree with William:
The articles main point is that there seem to be no cases of current browsers presenting certain semantic markup in a different/better way than markup considered to be less-semantic.
The whole point about writing code for the web is not to only make it work today, it has to be forward thinking and work on tomorrows browsers too. The W3C has always tried to guide developers towards a more semantic Web, and does advise things like
<i>where the text needs more than just a visual emphasis.
As responsible developers, we shouldn’t be satisfied with just making things work, we should be trying to consider situations that haven’t come up yet. It’s why responsive design is more than just making websites work on a specific fixed size mobile screen. It’s why inroads are being made to make content responsive to users connection speeds, even though we don’t know what our users might have. It’s why we’re constantly learning about new technologies, because we always want to be forward thinking.
I completely agree we can screw up accessibility, but I don’t believe it’s by trying too hard, I think it’s because we don’t understand. Throwing ARIA attributes over a
<div>infested page is wrong. It seems right, because we are spending a lot of time on it, so we’re working hard, but we’re working on the wrong things. ARIA was only ever meant as an aide when semantic markup failed; but semantic markup should always be king.
So that’s why I agree with William. We have to be mindful about our markup, and unfortunately it does feel like this post is not giving the best advice (or at least not giving the best advice in the best way).
“11 years ago, Patrick H. Lauke created a presentation …” good lord, I feel old now…
I spend too much time on StackOverflow telling people they do not need to force hidden text to speak dates or prices the way they want simply because a screen reader does not say it as expected. Over-engineering can happen easily when we think about the technology as our target instead of the user.
Related to the announcement of
<em>in screen readers, Steve Faulkner also wrote a great piece on making
I expanded it to handle
<s>for more than screen readers: http://adrianroselli.com/2017/12/tweaking-text-level-styles.html
To bring this back to Chris’ point, with NVDA adding support for
<ins>, some users to my site will now experience too much accessibility: https://github.com/nvaccess/nvda/pull/8558
These semantic elements may have implicit roles in the future: https://github.com/w3c/aria/issues/698
The point was that screen readers are compensating for our failure to provide good semantic code. If we were using
<em>tags correctly, they would have been adding voice emphasis and sounding much more human-like for ages. They make the language switch for the correct pronunciation whenever we use things like
<i lang="fr">, adding emphasis should be much simpler.