Content

Numbers

Something which is often questioned is how screen‐readers seem to handle things like long reference numbers and phone numbers.

Screen‐reader users are used to how these types of content sound and some screen‐readers have settings which can change how numbers are read.

JAWS has a few options for users, although these are normally left to the chosen speech synthesiser. For example, given a number like “1234” a JAWS user can adjust their settings so it reads:

• as a full number: “one thousand two hundred and thirty‐four”
• as pairs: “twelve thirty‐four”
• as individual digits: “one two three four”

and it can be set to read out as single numbers if there are more than a given number of digits in a row.

Resist the urge to fix

These settings are global and so for specific examples you might be tempted to try and “fix” it. But screen‐reader users are used to how these types of content sound and trying to force them to be announced a particular way can have unintended side‐effects.

It's also worth pointing out that users can read these numbers out number-by-number if they want.

Navigating content

It is possible for JAWS users to move word‐by‐word or character‐by‐character when needed.

Acronyms and abbreviations

Whilst it might be tempting to use the abbr element along with a title attribute, like in the following example for UTR, to help screen‐readers with these, there are a few issues with this approach.

Even if JAWS did expose the abbreviation by default (it does have the option to but the user has to enable it), there are still issues with this approach:

• just hearing the expanded acronym without the contracted version (as JAWS operates when this option is enabled) means the user will not understand the contraction when it is used later
• this does not help other users in explaining the acronym
• the abbr tag is not announced to most assistive technology, including JAWS. Whilst JAWS users can query information about an item, they would need to know to look for it
• you have to hover with a mouse on the acronym to expose the expansion, which is only helpful for some people
• you need to add additional styling to provide affordance to users that an expansion is available, which adds visual noise

It is much better to expand the acronym on first usage so the user is aware of it. Screen‐reader users can then add it to their screen‐reader's vocabulary so they pronounce it correctly.

Other semantic markup

You might think that using the semantic <strong> and <em> tags might convey their meaning to screen‐readers - perhaps changing the voice announcement slightly?

As you should be able to hear, there is no difference in how the two paragraphs are announced. What is probably more important is that the common styling for these elements (bold and italics) is not overwritten as screen‐readers can be set to report styling of text.

The treatment of strong and em is common for all screen‐readers although other (less used) text-level semantics such as del and ins are announced.

Whilst using this markup can have visual advantages for users, the meaning is not communicated audibly. That is not to say you should not continue using this markup.

Next, images