Force screen reader to read one letter at a time rather than the entire word

Question

I'm building an HTML webpage that contains the following content:

In order to proceed, please enter this code: GJBQTCXU

"GJBQTCXU" is a code comprised of a string of letters; however, screen readers attempt to pronounce this as a single word. How can I stop them from attempting to pronounce this nonsensical word and instead get it to read one letter at a time: "G J B Q T C X U".

As clarification, I'm building this page so that screen readers automatically do the right thing. I know that users can choose to have their reader pronounce each letter at a time, but I don't want my users to have to take any additional steps.

Theological

Don't. I've been down this path and tested it with real users. You may think you are helping, but you really aren't. Particularly when a user wants to just let the reader fly through a page, knowing the letters, and you have slowed that user down by forcing letter-by-letter pronunciation. – Meldameldoh

There is a CSS speak-as (and also speak) property which has terrible browser support. – Ithunn

Answer 1

try using CSS letter-spacing property -

<div>G J B Q T C X U</div>

div {
    letter-spacing:-1.9px;
}

example: http://codepen.io/stevef/pen/grZGBP

Nanette

For OP: Yeah after testing out in JAWS and NVDA (not the only screen readers but they give some insights) this looks to be read as individual letters in different browsers. This seems like the simplest solution compared to multiple block element tags with CSS to inline them. However users who use direction keys to read one letter at a time do read spaces. So like Adam mentions it might be good for the input to remove blank spaces on blur or submission. – Osculation

As well as breaking cursor-navigation, it also means you get all the spaces if you copy the text. – Hyperesthesia

Answer 2

I feel like the real answer to this is:

<div aria-label="G J B Q T C X U">GJBQTCXU</div>

Utmost

aria-label is not to be used on divs without a role. – Innis

This attempts to optimize for text-to-speech audio output, but it's unnecessarily verbose when using a braille output device with a screen reader. Braille devices have limited size, often capable of showing just one line at a time. The spaces mean each letter is treated as a word, which may cause it to wrap to a new line, and there's a risk the user will miss part of the code. Without the spaces, the whole code will be treated one word, and a braille device will try to avoid breaking over multiple lines. – Hepatica

Answer 3

There are many screen readers and those readers can also be inconsistent between browsers due to accessibility APIs differences.

With that said here is a good generalization of functionality from WebAIM http://webaim.org/techniques/screenreader/

They note that some screen readers by default won't read punctuation like periods, semi-colons, etc. but rather pause between them. You could try visually hidden versions of these. Now if they have more verbose settings turned on it might read those.

Another reading aspect mentioned is that some screen readers pause at the end of a paragraph. So if you wrapped each letter in a p tag and then made them display inline, there could be pauses.

Since nuances aren't as well documented between the screen readers between browsers it's hard to say either will work in your instance.

Since users can just use left/right arrow keys to read individual letters it wouldn't take much for regular screen reader users to read the word slowly.

I would say the punctuation is more dangerous if their verbosity settings are set high. So try the paragraph tag approach first. Since users can also jump between paragraph tags with screen readers there might be some confusion but it seems like the lesser of the two.

Osculation