I have the following markup:
<p><span alt="Something else">Lorem</span> ipsum blah blah</p>
But I want to substitute the Lorem with "Something else" just for the screen readers. How can I do that? I won't be able to use aria-label as span is not an interactive element.
You would need to use a combination of aria-hidden and visually hidden text.
Visually hidden text (which is what I suggest and explain below) should be used to add contextual information. It is very rarely a good idea to replace information.
The reason for this is that you could be offering a different experience to screen reader users than to non screen reader users and that is against the core principles of accessibility!
Without knowing your specific use case I cannot advise whether this is true in your use case (hence why this answer shows you how to do it) but a general rule is that if it is useful to one group of people it is useful to everybody. Instead look at ways to make the explanation / information etc. work for all users so everyone has a similar experience as possible.
aria-hidden allows you to hide information from a screen reader. Think of it like display: none but for assistive technology.
You would hide the part that you do not want read out.
<span aria-hidden="true">Lorem</span>
Visually hidden text is the opposite of aria-hidden. It is often referred to as "screen reader only" text.
You simply place your text you want to be read by a screen reader within an element (normally a <span>) and apply the class. This will be read by a screen reader but visually invisible.
There are classes built into most libraries but I would encourage you to use the CSS indicated in the example below as my visually hidden class has better compatibility / support as discussed in this answer I gave..
As visually hidden text works all the way back to IE6 you shouldn't have any compatibility problems (although some screen readers may ignore the aria-hidden and announce that as well so bear that in mind, there is nothing you can do about that though)
<span class="visually-hidden">Something else</span>
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}<p><span aria-hidden="true">Lorem</span><span class="visually-hidden">Something else</span> ipsum blah blah</p>
TL;DR: You can set a role on the tag to make it an interactive element, but wait...
But I want to substitute the Lorem with "Something else" just for the screen readers. How can I do that? I won't be able to use aria-label as span is not an interactive element.
The problem in many similar questions is that you are focusing on screenreaders while the text alternative might be useful for everyone : for instance people with language difficulties (aphasia, dyslexy, illiterate, deaf people, ...) or even blind people using non-screen displays (braille display).
Or worse, the text alternative could ruin the user experience as, for instance, replacing easy-to-read text like "FBI" with "Federal Bureau of Investigation".
You can be tempted to express a date format expressed like "09/11/01" with the following tag:
<div role="img" aria-label="September 11th, 2001">09/11/01</div>
It will work in screenreaders. It might help blind people not living in America, but it won't help 99,9% of the worldwide english speaking users where the full text could help them to understand the date format (is it "November 9th, 2001" or "November 1st, 2009"?).
Another way to do this is:
<p><span aria-label="something else" role="img">Lorem</span>ipsum blah blah</p>
... NVDA announces this as "graphic something else ipsum blah blah".
The img role tells the AT not to look inside the element for further accessible names, which is somewhat similar to aria-hidden so it is especially useful for accessibly labelling 'dingbat' type glyphs and emojis (i.e. 'graphic' icons represented as 'text' characters), or when a sequence of characters may be interpreted (especially by a speech synth) in multiple ways, or not announced at all. This will allow you to lock into a single interpretation.
Example: The single quote character ' might mean minutes or feet, depending on context. NVDA doesn't announce it at all, unless punctuation is enabled in the prefs.
Now, unlike the default semantic-free span, the img role allows you to treat arbitrary character sequences as a graphic, and use an aria-label.
A disadvantage is that the role is announced (e.g. as "graphic" or "image"), and the element will appear in any image list UI offered by your AT.
You may or may not be happy with the role announcement. (In this case, it's not a graphic at all). You can tweak that with aria-roledescription, thus:
<p>You turned over the 5<span aria-label="hearts" role="img" aria-roledescription="suit">♥</span></p>
... NVDA announces this as "You turned over the 5 suit hearts".
Not perfect, but this pins down the glyph as the card suit "hearts", rather than (say) the word "love" (as in "I ♥ NY"). Other special role names may be more appropriate in your situation. Note that empty aria-roledescription attributes are not valid in ARIA, so you can't do away with them altogether with this technique, and you can't predict exactly how different ATs will insert the role announcement into the speech stream. Therefore, use the aria-roledescription attribute with extreme care.
And Graham's caveats remain important. The valid use cases for these kinds of approach are where the AT-only content would be superfluous or disruptive for sighted users. These cases are rarer than you might think.
Consider also that some screen reader users are not partially sighted - they may be dyslexic, for example.
Another less-than-obvious point is that not all ATs are screen readers!
Some 'creative' solutions for text variants may work well with screen readers but poorly with (say) Braille devices. This is especially true if you try to 'second guess' how a screen reader will pronounce something, and are tempted to provide some kind of phonetic hack, which Braille users will then struggle to understand.
As a general rule, hiding stuff from ATs or offering stuff only for ATs should be avoided.
If you absolutely must do it, consider dyslexic screen reader users, braille device users, and (preferably) get a second opinion about your implementation from the accessibility community or some representative users, providing enough context (i.e. not just lorem ipsum) to allow your implementation to be judged appropriately.
