Including emphasis

emphasis shouted from a megaphone Reading Time: 5 minutes

There’s a choice of content emphasis strategies available to us including the emphasis (em) tag, headings, lists, and more. These may not be well understood and are often not accessible.

The spark for this Post is finding an em tag enclosing the content of an HTML heading. It’s silly because headings add emphasis.  If your team is doing that, then this Post is certainly for you.

Understanding the heading tag

Headings give emphasis to content and so much more. This section’s heading content is styled to look italicised using the inline CSS, style="font-style: italic;". There’s no need to contain the copy text within em tags. None. Using the em tag in the heading here is only silly. It indicates a paucity of digital writing knowledge, or the use of an inferior writing tool.

The heading informs our reader of new sections and sub-sections of content. A well written heading highlights and emphasises the section’s purpose and tasks. We can scan through and navigate content using headings as visual and programatic anchors, too.

HTML headings are available in six flavours from h1 to h6. Browsers give each a default presentation that offers a visual hierarchy of precedence. We can override the default presentation using CSS, of course.

The h2 heading this section is styled as italic using in-line CSS. That’s OK as the heading can be announced by our assistive technology. However, if the heading is of special importance among its peers, then we should offer screen readers an opportunity to share with that special emphasis. The best way to do that is to design a better heading hierarchy so we don’t need to do anything.

When we must do something silly, then we should add a hint for people using a screen reader to understand.

Understanding the emphasis tag

The HTML emphasis tag (em) offers a semantic prominence to the text copy it contains. It stresses the importance of one content over another, although not all assistive technologies will convey it.

Visual browsers apply an italic font style to the em tag’s content. We can also style the em content using CSS like in the following examples. However, as assistive technologies may ignore the em tag, all this effort may feel ableist. Worse, italic fonts may reduce legibility and make content more difficult to read. There’s a balance between offering a visual emphasis and creating a barrier to reading.

Examples of copy inside the em tag using inline CSS to style them.
  • Default browser italicised copy.
  • Stylised italicised copy
  • Colored italicised copy.
  • Underscored italicised copy.
  • Bold roman copy.
  • Highlighted roman copy.
  • Uppercase (standard case styled with CSS).

Alternative emphasis methods

The problem with emphasis is giving it so everyone gets it inclusively. Visually, we can add boxes, colours, shapes, font styles and weights, movements, and all sorts of other dog poo decorations. How do people using a screen reader access those? (Read more in my Post, Dog poo is Accessible Too.)

The slow death of B and

Desktop publishing gave HTML the historical typeface b for bold tag and the i for italics tag. Browsers interpret these only as visual styling codes. We then received the strong and em tags that give semantic meaning.

Fanfare for em and strong

The Web Accessibility Initiative (WAI) works to improve the accessibility of the em tag semantic even when W3C Schools makes the following generalisation:

“A screen reader will pronounce the words in <em> with an emphasis, using verbal stress.”

It’s all a bit confusing. Is the content enclosed in the em tag announced by screen readers with a verbal emphasis? It seems to depend on the browser client and our user’s settings, which may create barriers. What I read of joanmarie’s (2019) discussion focusses on adding an ARIA role attribute is that the tag needs an additional semantic to win through any technology or user created variables and barriers.

What happened to the semantic baked-in to the tags, anyway? Maybe our browser and assistive technology vendors should reprogram their softwares properly instead?

Strategies that emphasise content and semantic

We can consider each of the following as alternatives to the em tag, or as an alternative content emphasis strategy. They include my writing this list as a list, which adds a semantic meaning or emphasis to the content block.

  • Headings h1 to h6 deployed in the correct hierarchy.
  • Parentheses.
  • The strong tag, which is not an alternative to a heading!
  • The highlighting mark tag.
  • The dfn tag, although it needs used with care.
  • The definition list (dl).
  • Ordered (ol) and unordered (ul) lists, which should only be used when listing more than one item.
  • Tables and particularly when used for data-value pairing.
  • Images, correctly encoded for accessibility. (Read my Posts, Shaking the Alt Decision Tree and Altruistic Alternative Attributes). 
  • The language (lang="") attribute. For example, within a span element styled like this, français!
  • The code and pre tags.

There are other semantic tags that separate and emphasise content.  Lynch and Horton’s (2017, chp. 8) Web Style Guide helps to guide when and how to deploy them.

Not all these emphasis strategies will affect a screen reader’s announcements. Screen readers may offer tonal emphasis in response to some punctuation, too. Always test as widely as you can.

An important note

How often do we see the following, including in this blog’s Posts?

Important: You may see this copy within an emphasis, and can you perceive it when using a screen reader?

The styling of content with visual emphasis is widespread. What we often miss and myself included, is consideration for people using a screen reader. The CSS styled left border and additional margins are not announced. When the emboldened copy enclosed in strong tags isn’t announced, then we’re essentially proliferating an ableist or print-based writing habit.

An improved strategy is to use the next appropriate heading. It’s added to the implied table of content that people using screen readers may use to navigate by. The heading is usually announced by screen readers, too. It’s a win-win strategy and can prove difficult to implement.

One problem remains. The heading level for important notes may prove inconsistent throughout a document or website. I’ve not always solved that.

MDN Web Docs’ direction on the aside element prevents our using it to contain inline notes:

“The aside HTML element represents a portion of a document whose content is only indirectly related to the document’s main content.”


  • Emphasis is all about inclusively highlighting the semantic difference between one content and another.
  • Emphasis isn’t limited to the em and strong tags.
  • There are semantic alternatives suited to emphasise short text strings and whole content blocks. 

We can do better. For example, enclosing a heading tag’s content with em tags is a nugatory exercise at best. At worst, it’s an ableist abuse of HTML for visual styling. The heading is the semantic emphasis and we should use CSS to add visual styles to headings.


1 thought on “Including emphasis

Leave a Reply

Your email address will not be published. Required fields are marked *