Search code examples
accessibilitynvda

On arrow access, word has to read like individual letters as it is invitation code , it should not read like words

Invitation code is: UHM85QP6

tried below two cases, but still not working.

case 1:

It's reading like letters only, while accessing single letter it is reading space also. It should read like individual characters.
We are doing this space thing through JavaScript and showing in sr-only.

<div>Your invitation code is:<span class="sr-only">U H M 8 5 Q P 6</span> <span aria-hidden="true" class="application-title">UHM85QP6</span></div>

case 2:

Its reading like words and billions for numbers.

<div>Your invitation code is: 
 <span class="sr-only">U</span><span class="sr-only">H</span><span class="sr-only">M</span><span class="sr-only">8</span><span class="sr-only">5</span><span class="sr-only">Q</span><span class="sr-only">P</span><span class="sr-only">6</span> <span aria-hidden="true" class="application-title">UHM85QP6</span></div> ```

case 1 image , while doing in down arrow its reading individual characters, but the issue is while doing right and left arrow its reading with spaces also. Accessing through left and right also, it should reading like individual characters without spaces.

[1]: https://i.sstatic.net/ONeqW.png
Solution

  • My advice is to do nothing. Discard the .sr-only spans and aria-hidden, and just include the code verbatim. Keep a styling span if you like:

    <div>Your invitation code is: <span class="application-title">UHM85QP6</span>

    There's no need for authors to attempt to manage the screen reader on the user's behalf. Screen reader users are accustomed to quirks like reading telephone numbers as billions, or pronouncing abbreviations and invitation codes like words.

    Screen reader users can choose to read text using different granularities: block, line, word, or character. The exact commands vary, but most screen readers offer this feature. Confident users will often switch modes on the fly, and read one character at a time to clarify the invitation code. For instance they may be reading on one device then typing it on another, and need to go slowly.

    I think you've tried to optimize for how the invitation code sounds when using text-to-speech audio output from a screen reader, at the expense of other ways of using it. Users can also use a braille output device to read, and can perform other actions like select-and-copy. We don't want to make a worse experience for those cases.

    Let's look more closely at the approaches you tried.

    Case 1:

    • The spaces inside span.sr-only mean each character is a treated as a word. Remember that sentences normally have some words which are only one letter long (such as "I" and "a" in English; "o", "a", "e", and "é" in Portuguse). So when the invitation code has spaces, each letter is treated as a word by the screen reader. Reading one word at a time, the spaces aren't pronounced, but reading one character at a time, the spaces are pronounced. This is why you hear different output when using the down or right arrow keys; you're using the word and character reading modes. Announcing the spaces in character browsing is expected.
    • The spaces in span.sr-only are also output on a braille device. These devices often have a very limited size, and the spaces are unnecessary.
      • There's a risk that the invitation code won't all be displayed at once, because the braille display wraps it to a new line (like it would for separate words). Many braille devices only have one line!
      • Without the spaces, the whole invitation code will be treated as a word, which is better because the braille display will try to keep it on one line, without splitting it. So there's less risk that the user will miss part of the code.
    • The spaces may cause a problem for users who want to select and copy the invitation code, so they can paste it somewhere else.
      • Screen readers will ignore the visible code, because of aria-hidden. Users will have to copy the .sr-only version which includes the spaces. When this is pasted in another application, it may be rejected because of the extra spaces.
      • Users who aren't using a screen reader risk copying both versions of the code! This is a bit hit-and-miss, depending on exactly what method is used to select text (click/drag, find-in-page, or caret browsing mode). So they end up pasting UHM85QP6 U H M 8 5 Q P 6 into another application, and it gets rejected. This is because the .sr-only CSS doesn't remove anything from the DOM, it just clips it in the rendered layout. (Aside: invisible text is a known security risk when copying specimen terminal commands from tutorials.)

    Case 2:

    Its reading like words and billions for numbers.

    It reads like a word because there aren't any spaces! The spans follow each other directly, without any spaces between them:

    <span class="sr-only">U</span><span class="sr-only">H</span>

    Screen readers don't have to do anything with the span elements, because they have a generic role.

    Users without a screen reader are also at risk of copying the invitation code twice, as in case 1.