I am working on adding accessibility to a website.
Now I know that aria-labels, aria-labelledby, etc are meant to give accessible names to interactive type of elements as clearly mentioned in this blog. Hence, they may not work consistently with elements of type p, span, etc.
I want to do two things:
- There is a text on the website "between 0-5m".
Currently the screen reader reads it as: "between zero five million"
I want it to be read as: "between zero and five million"
What I tried is the following:
.visually-hidden {
position: 'absolute';
height: '1px';
width: '1px';
padding: '0';
margin: '-1px';
overflow: 'hidden';
border: '0';
}
0<span aria-hidden="true">-</span><span class="visually-hidden">and</span>5m
Now the screen reader reads it as: "between zero and five m".
Hence, this approach is clearly not working.
- There are table headers in one of my table which are abbreviations: For example, table header is CAGR which is full form for Compounded Annual Growth Rate. Also to explain the meaning of these abbreviations the following thing has been done:
Table header is given as CAGR1 and then at the bottom after the table there is 1CAGR – definition of CAGR.
For accessibility I want that initially when table headers are read then table header along with its definition are read out and then as values are read out only the abbreviation is read.
Also, currently the screen reader reads CAGR as a word but instead I want it to be read as "C A G R".
Since above all are text elements using aria-labels will not work and using visually hidden text may cause other problems as shown above. What approach can I use to achieve these things to make the website more accessible?
2
Answers
There is a lot to learn about Accessibility. A good starting point is WCAG 2.1.
However, you can also overdo Accessibility which then has a negative impact. Especially creating element that will be visually hidden have a very negative impact on your accessibility score.
So be really careful with that. What you can do that works as you intend is the following technique:
Here you nest 2 spans inside each other. The inner span hides the content from the screen reader so that the outer span effectively will be empty to the screen reader. As such the
aria-label
value will then be read by screen readers. Screen readers will only read thearia-label
if the element has no content for the screen reader itself. That way you do not visually hide content but still can read the intended text correctly.Note that
m
in itself is not accessible as well.m
would normally refer to meter and not millions. In any case, abbreviations such asGB
(which could be Gigabyte or Great Britain) as well asMo. 1st Oct.
. are not accessible at all and should always written out completely! Most importantly accessibility guidelines require you to have text to be easily understandable. This also means to not name links such asclick here
but to give them a meaningful description such asread more about...
In the specific case of
CAGR
the same rules as above apply. As such you should not create a term for the screen reader to read it out asC.A.G.R.
(note that you use dots to create pauses between the letters for screen readers) but you can use the<abbr>
tag for that specific case that exactly exists for such cases:The abbreviation is written within the text while you use the
title
attribute for the screen reader to read out the actual meaning of the abbreviation.Last but not least the golden WCAG rule is:
As such remember not to overdo it and if you’re not sure if an aria-attribute would fit in a case then either ask or don’t use it at all.
Reference material to learn more about accessibility:
WAI-ARIA – Bad Practises
HTML Accessibility Guide of the Penn State University
For both questions, probably you shouldn’t do anything special for screen readers, and leave it presented as it is, unless you receive specific complains about it.
In general, it’s quite a bad idea to replace a text by another text specifically for screen readers.
Here are several reasons for that:
That’s the same for abbreviations like CAGR for which you can’t control if it should be read as a word or spelled out.
So by making a change, you may well improve accessibility for a minority while make it worse for the majority.
Also, braille users can have header cells kept on the same line as the cell content for easier reading, but space is very limited (40 characters and often less). With your longer label, you may prevent from using that quite useful feature.
By the way, maybe that the visually hidden technique doesn’t work in your particular case (your first question), but in general it works quite well.
I don’t see any issue using them in table headers for example, if despite the above arguments, you still want to do it. Watch out spacing, though, as unwanted words can be read glued together.
A note about the abbreviation "5m". You have certainly greater changes to have it read "5 millions" by using a capital M.
The lowercase m is generally rather used for meters, or sometimes for minutes.
If you are talking about money, it would also better to add the money symbol, for example "5M$". It will definitively remove the doubt that it might be meters or minutes, for screen reader users as well as for all users.