Introduction to screen‐readers: JAWS Edition


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

Activity - how JAWS handles different formats

Read the following list of examples with JAWS to hear how they might sound to a user:

  • A UTR like 1234567890
  • A reference number like 123PX0012345X
  • A National Insurance number like QQ123456C
  • A telephone number like 01632 960 001
  • A currency value like £1500

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.

Activity - reading text

Move to the sentence in the following example.

Once on the sentence, use JAWS + right arrow to move word-by-word through the sentence.

When you reach the number use the left/right arrow keys by themselves to move character-by-character.

A UTR like 1234567890

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.

Activity - abbreviations

Use JAWS to read the sentence in the following example. It uses an abbr tag for the UTR, but as you should hear this is not exposed to the user.

Do you know your UTR number?

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?

Activity - text level semantic tags

Use JAWS to read the sentences in the following example. Try to listen for any differences between the two.

Tulips are a perennial bulb and are very easy to grow.

Tulips are a perennial bulb and are very easy to grow.

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.

Key takeaway:

In general I recommend you do not make any adjustments for screen‐readers to make content sound different.

Workarounds which try to force a screen‐reader to read in a particular way often have undesirable side‐effects and are not required.

Next, images