Pausing in a screen reader for accessibility

It's been a while since this question was asked, but it's worth noting that there is nothing wrong with the technique proposed in the question. I can confirm that the current version of Jaws, Jaws 18.0, will pause for either commas or periods, unlike marks such as colons or bullets which are announced outright as such. Current versions of iOS VoiceOver pause nicely for commas as well. Your punctuation (if it is not part of your design) can be hidden via screen-reader only CSS as proposed above, or, where appropriate, the aria-label attribute can include punctuation for pauses.

If you format your code semantically, it should work fine. By the looks of your HTML structure, you're using a <br> tag for presentational purposes. This is not what line breaks are meant for, and thus is not a semantic use of markup.

You specifically want each line to be separate, so you should put them in wrapping block level tags. You could wrap each line in a p or div tag, and then the screen reader will separate them properly.

I suggest using aria-label when you would like the screen reader to speak something different than the content contained within the tag's html markup.

I would update your code to be:

<div class="breakdown">
  <span aria-label="35 New.">
    <strong>35</strong> New
  </span>
  <br>
  <span aria-label="4 Overdue.">
    <strong>4</strong> Overdue
  </span>
</div>

With this, a screen reader will speak the following with full pauses at each period:

35 New. 4 Overdue.

We are specifically targeting ChromeVox, but this should work for all screen readers.

Thoughts on aria-label

• 😞 Because there are two strings to maintain, it's possible they may diverge if a developer misses an update.
• 😄 When localizing strings, the string used will come from one source and be used twice, thus alleviating the duplication.
• 😄 This is the purpose of aria-label and how I see it used often in other projects.
• 😄 The aria-label strings are faster to read/grok/edit for humans.
• 😄 Less markup using aria-label than hidden elements.
• 😄 Tests can be updated to look for specific strings in aria-label. Snapshots will also capture changes, but devs have to be aware of this.

Thoughts on Hidden Elements

• 😄 Less string duplication, pre-localization.
• 😞 When using the ChromeVox shortcuts, it's possible to get to a place where as the user tabs through, the voice over sees each hidden comma/period as a separate item when in reality it should just be a sentence w/o extra markup.
• 😞 Strings with copious html markup are difficult to localize and difficult for translators to maintain.
• 😞 The extra markup feels hacky compared to aria-label. If the user selects text on the screen and the selection spans content which is in a hidden element, the hidden content will be copied when the user performs the copy command, and pasted when the user performs the paste command.

Considering all pros/cons, long-term my bet is that you will find that choosing aria-label will provide the best developer, translator, and user accessibility experience.

If an element is described by a sibling element's text content, consider using aria-labeledby to link elements.

---

This answer is coming in 6 years after being asked… but hopefully it will be helpful.