Pausing in a screen reader for accessibility

问题

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?

回答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.

回答2:

I suggest using aria-label when you need the screen reader to speak something different than what appears in the 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.

---

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

回答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.

来源：https://stackoverflow.com/questions/15883778/pausing-in-a-screen-reader-for-accessibility