Links, hidden copy and voice recognition

An often-used technique for ensuring links to different targets have different accessible names (think of the classic "Read more" links on a blog), is to add some "contextual" content. This is so that screen‐reader users, who might be viewing a list of links extracted from the page by their screen‐reader software, won't have to guess at where a link might take them and can instead action the link directly from that list.

However if not done well this can have a deterimental impact on other users, in-particular speech-recognition users.

If you are reliant on speech-recognition software your primary interaction model is likely going to be saying "Tap (or click) [name of the thing on the screen]". So if a button has the text "Submit" on it, you might say "Tap submit" and the software will action the button.

Where this becomes more tricky is where the accessible name (the thing the speech-recognition software is waiting to hear) has been modified and no longer matches the visible name. This is exactly what we are doing when we add screen‐reader "only" contextual information to a link or other element.

General guidance is always to append the hidden copy to the visible copy to make it less problematic for speech-recognition users. But how exactly do other placements of this new copy affect the speech-recognition user's experience?

What I tested with:

• iOS Voice Control on iPad (7 gen) running 14.6 on Safari
• Android Voice Access on Pixel 2 running Android 11 on Chrome 92.0.4515.131
• Dragon on Windows 10 on IE11

Dragon seems to find the best match, front-loading the wording vocalised by the user. If saying "click account" it would pick the 3 links on the page with "account" in the visible name (but won't also flag the ones with "account" in the hidden copy alongside them). It also can search hidden copy - for example try saying "click of account".

Previous testing also suggests Dragon will search attributes for a match, so it will search in this order, stopping once it finds hits:

• visible text
• hidden text
• attributes - further testing needed

On the examples below the phrasing "tap" is used for ease of writing, but this might be "click" instead if the speech-recognition is using mouse-style input rather than touch-screen.

Standard link

For control purposes. No hidden copy, visible text is the accessible name.

<a href="#">Change name</a>

Unique visible text with hidden content appended

<a href="#">
    Edit applicant
    <span class="sr-only"> of account</span>
</a>

Non-unique visible text with different hidden content appended

<a href="#">
    Edit name
    <span class="sr-only"> of account</span>
</a>
<a href="#">
    Edit name
    <span class="sr-only"> of employee</span>
</a>

Unique visible text with hidden content interleaved

<a href="#">
    Delete
    <span class="sr-only">Lisa's </span>
    account
</a>

Non-unique visible text with hidden content interleaved

<a href="#">Remove
    <span class="sr-only">Bob's </span>
    permissions
</a>

<a href="#">Remove
    <span class="sr-only">Bob's </span>
    account
</a>

<a href="#">Remove
    <span class="sr-only">Pete's </span>
    account
</a>