DEV Community

Sandrina Pereira
Sandrina Pereira

Posted on • Updated on

A11Y study case: Breaking text on a specific word and Screen Readers implications

Asking to visually break a sentence in multiple lines on a strategic word is a common request from the design team, especially on landing pages. Eg “Hello /n human being”. However, that might affect a Screen Reader pitch flow in unexpected ways...

Scenario issue

For example, let's imagine we have the title "Hello human being" and we are asked to break it after the "hello" word.



Hello   
human being


Enter fullscreen mode Exit fullscreen mode

Here are some common (poor) approaches I've seen being used around:

  1. Add <br /> between each line: Don't do this! Despite being very common, because of its ease of use, it's semantically incorrect! <br> is meant to be used when the division of lines is significant. E.g. stress addresses, poems, etc...
  2. Add <span /> with display:block between each line. This creates the same effect as <br /> but without any semantics, which is good.
  3. Using flexbox: Wrapping each line into an <span> and adding flexbox to the sentence itself with flex-direction: column does the trick too.

However, all of these three approaches have the same unexpected result in the VoiceOver screen reader pitch flow:

  • Expected pitch: "Hello human being"
  • Actual pitch: "Hello" [pause] human being."

Another common practice is to set max-width, however, that solution is highly dependent on the text content. In this scenario that approach wouldn't work.

Shocase failed max-width attempt

Let's keep looking for a bulletproof solution instead.

Possible solution

Among other experiments, using write-space: pre-line; seem the best solution! We can create a literal newline or use &NewLine; control character to break the text.



<h2 style="white-space:pre-line;">Hello       
human being</h2>

<h2 style="white-space:pre-line;">Hello &NewLine;human being</h2>


Enter fullscreen mode Exit fullscreen mode

This is just an example of how HTML semantics and CSS usage can affect the way text is read out loud in ways we might not expect.

Here's a Codepen where you can try out the approaches described and other solutions attempts:

Top comments (0)