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?

Credible

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.

Turbinate

Good point on the HTML structure, in your experience a (proper) screen reader will definitely create a 'breath' or 'pause' after a <div> ends (without punctuation)? To be fair in this instance perhaps a <ul> could be considered the most semantic element, which I know will pause. One other question... I'm finding (again, with the Mac Reader) that when I do: <span>Word </span>Word it is being read "WordWord" and not "Word Word", no matter where the space goes... is this purely a Mac Reader problem or is it by design in all screen readers? – Credible

Haha I'm no expert in screen readers, but I'm making an assumption on how they follow markup. The span issue is weird, and sounds like a bug with Mac's reader. But I doubt any of them are perfect; they've got to make tough assumptions about how the markup should be read, which will inevitably lead to incorrect results. It's good that you're considering it though, your site will perform better than 99.99% of sites out there just because of that. – Turbinate

Christian is basically correct, adding more semantics will help some. It looks like the OP is using the say all command, which will just start rambling. – Calorifacient

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.

Henderson

Super thorough answer and probably better suited to the landscape of development, screens and readers today. Thanks! – Credible

Good answer and something I'm working through now. However in your case it is recommended aria-labelledby should be used eg "If there is visible text labeling the element, use aria-labelledby instead." ~ developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/… – Boutonniere

@Boutonniere - Thanks for pointing this out. There is a subtle difference. The aria-labelledby is more useful when one element is "labeled by" a sibling element. However for the specific example in the original question here, the goal is to provide an aria label to replace all the contained elements. – Henderson

Keep in mind when aria-label is applied to certain unsupported HTML, this can lead to "Possible misuse of aria-label" warnings when validated. – Pendergrass

Automatic machine translation (browser based) doesn't jive with aria-label hence why in some cases sr-only hidden elements are preferred – Jackscrew

Answer 3

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.

Metastasize