Skip to main content

Bold and italics aren’t read by screen readers

Posted in Accessibility

Whether you call them italics and bold or <em> and <strong>, we’re talking about emphasis and the HTML used to communicate it.

A sighted user will be able to pick out the italicised or heavier text that denote levels of emphasis, but unfortunately most non-sighted screen reader users won’t know anything about it. They can query a word, but if they don’t know there’s anything different about it, why would they query it?

Interestingly, the NVDA screen reader added support for emphasis, only to remove it following complaints by users:

Having emphasis reported by default has been extremely unpopular with users and resulted in a lot of complaints about NVDA 2015.4 … As such, we’ve now disabled this by default, though the option is still there for those that want it

So it can be switched on, but I doubt a high percentage of users use the feature because:

In the old GOV.UK Elements, they were very clear about how bold and italics should be used in body copy:

avoid using bold and italics

The GOV.UK Design System that superseded Elements is less prescriptive, though they talk more about highlighting critical information, than semantic emphasis:

You can use bold to emphasise particular words in a transaction. Use it to highlight critical information that users need to refer to or you’ve seen them miss.

The example they give draws attention to a reference number and an email address, so the use of the word “emphasise” is misleading; the <b> element would be more appropriate than <strong> here.

It’s also worth noting that the GDS Transport doesn’t have an italic/oblique variant, just Light and Bold, so emphasis (if indeed it is emphasis) doesn’t come in more than one flavour.

The take away here is: if you’re relying on emphasis to convey meaning you’re on dangerous ground, as some users won’t know it’s there.

Like many tools we reach for as web designers, text-level semantics like italics and bold should be treated as a progressive enhancement. In other words, your sentences should make sense without emphasis; those <em> and <strong> wrappers should just offer a nice added extra for users that know they’re there.

Accessibility in your inbox

I send an accessibility-centric newsletter on the last day of every month, containing:

  • A roundup of the articles I’ve posted
  • A hot pick from my archives
  • Some interesting posts from around the web

I don’t collect any data on when, where or if people open the emails I send them. Your email will only be used to send you newsletters and will never be passed on. You can unsubscribe at any time.

More posts

Here are a couple more posts for you to enjoy. If that’s not enough, have a look at the full list.

  1. Images as the first thing in a button or link

    If the text of an interactive element like a button or link is preceded with an accessible image, we’ve probably got an accessibility problem.

  2. Alt text for CSS generated content

    There’s an interesting feature in Safari 17.4 that allows content added with CSS to have ‘alt’ text. I’m not sure how I feel about this.