Pausing in a screen reader for accessibility

Question

I have been using the Mac OSX's built in screen-reader for testing my site, I know it's not the best but it's all I have for now. But I'm finding it isn't pausing at the end of elements... which makes sense; but I'm finding myself placing hidden periods to make things readable:

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

I feel really dirty doing this, but if I dont then either it ruins the design, or it is read in a continuous sentence which is not comprehensible.

Does anyone have an experience of this kind of thing to offer?

Answer 1

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.

Answer 2

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.