VoiceOver capitalized small words are read as abbreviations

Question

I have the following header

<h1>ADD MONEY</h1>

and it is being read by VoiceOver as

a-d-d money

whereas if I change the text to lowercase it will read it properly as "add money". Do you have any suggestions? I have already tried using the aria-labelledby with no luck!

Answer 1

I recommend developers avoid trying to control screen readers in this situation. Some reasons:

• Screen reader users are (typically) well accustomed to quirks like this, and will understand common words like "add" being spelled out. What can seem like a huge problem to developers (and QA testers) may actually just be minor issue for people who use screen readers all day long. Longer or uncommon words may be more of a problem with capitals, but there's no threshold.
• It varies between different screen readers, and may come down to which voice (or text-to-speech engine) is being used. Words that are capitalized may be spelled out in one screen reader, and announced as a word by another. It's too much for most developers to worry about.
• Some screen readers use different approaches with capitalization, for example announcing "cap" or changing pitch.
• Some screen readers offer user settings for these. In my view, this is the main reason for developers to avoid micro-managing the screen reader experience - we may inadvertently get in the way of user preferences.
• All of this may change as in the future, as speech engines and assisitive tech evolves. Attempting to control the announcements today may interfere with assistive tech capabilities in a few years time. WCAG guideline 4.1 states: "Maximize compatibility with current and future user agents, including assistive technologies" (emphasis mine). I interpret this as meaning that it's not worth attempting to micro-manage minor quirks like this in the short term.

Some answers here suggest the use of a CSS text-transform: uppercase. That's a good approach, but it also has inconsistencies between different screen readers. In an ideal world, the raw text and the text-transform could both be passed to assistive tech, to provide better information to speech engines, and also respect user preferences. We're not there yet, but it's being discussed by browser implementers - see this discussion in the Chromium bug tracker for extra detail: Honouring text-transform styles in the a11y tree?

Another suggested technique is to use a lower-case aria-label to duplicate the visible text, but force browsers to pass the lower-case version to assistive technology. For example <button aria-label="add money">ADD MONEY</button>. This may work quite well in many cases, but it's an example of how developers could get in the way of user preferences. For example, users who want their screen reader to change the speaking pitch for capitals will miss out here. A screen reader's primary job is to convey what's on the screen, including capitals. The lower-case aria-label technique is at odds with that, in my opinion.

A discussion about all-caps (in a Drupal CMS issue) has some interesting contributions from screen reader users: Readability problem with all-caps text in core themes.

Answer 2

Leave the markup as lowercase, but use CSS to only change the text to uppercase visually via text-transform.

Then add an aria-label of "add money".

h1 {
  text-transform: uppercase;
}

<h1 aria-label="add money">add money</h1>