Published in · 6 min read · Jul 28, 2022
Two common ways to add screen reader only content are the aria-label attribute method and the CSS method. When I was first learning about web accessibility, I struggled with deciding which approach to use. In this post, I am going to explain the difference between the two, how they work, and when to use them.
Sometimes while building a web page, it is necessary to add visually hidden content that screen readers can present to users. Usually, the accessible name is created by the text content of an element, like <button>Send Email</button>. However, sometimes it is generated by attributes or associated elements.
Let’s say the page includes a close button that contains an SVG that looks like an X.
<button>
<svg>...</svg>
</button>The problem with the element is that it is missing an accessible name. To a sighted user the purpose of the close button might be clear, but a screen reader would not vocalize an accurate value for the button. For instance, VoiceOver, the Mac OS X screen reader, announces the element as “button.”
Similarly, if you use the letter X to signify that it is a close button, a screen reader would not present a clear name for the button. VoiceOver announces it as, “X, button.”
<button>X</button>In cases where the interactive element is missing an accessible name or an accurate accessible name, there are different ways that it can be labeled, such as with aria-labelledby, aria-label, or screen reader only text. The two I most often got confused about when I started learning about accessibility were aria-label and screen reader only text. In this post, I am going to focus on how to give an element an accessible name by using these methods, and I will test the elements using VoiceOver with Safari 15.4.
CSS Off-Screen Text
The CSS off-screen text method visually hides the element from the screen but makes the element accessible to screen readers. Using CSS styling such as display: none; or visibility: hidden; hides content from both the screen and screen readers. Bootstrap has a screen reader-only class called .sr-only that is defined as:
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
border: 0;
}Several CSS properties are included in the class in order to ensure that the class works properly across browsers. In my experience, this class is a reliable way to hide content visually but still have it be read by screen readers. Let’s see how this would work with the examples discussed earlier.
<button>
<span class='sr-only'>Close dialog</span>
<svg>...</svg>
</button><button>
<span class='sr-only'>Close dialog</span>
X
</button>
VoiceOver in Safari announces the button with the SVG as, “Close dialog, button,” so using .sr-only solved our problem, but only for Safari users. In Chrome it is announced as, “Close dialog, button, group.” The browsers do not consistently handle SVGs. In Safari, the example with the letter X is announced as, “Close dialogX, button” and in Chrome it is announced as “Close dialogX, button, group.” The .sr-only class does not prevent the screen reader from announcing other elements inside the button. If a screen reader were to vocalize visual indicators, like icons and characters, it could cause a confusing experience for users. When you use the .sr-only class to add accessible text, you should hide the visual indicator that reveals the purpose of the element. Now let’s update the buttons, by adding the aria-hidden attribute to the SVG and the X.
<button>
<span class='sr-only'>Close dialog</span>
<svg aria-hidden='true'>...</svg>
</button><button>
<span class='sr-only'>Close dialog</span>
<span aria-hidden='true'>X</span>
</button>
The aria-hidden attribute hides the element from the accessibility tree. Since the icons are not meaningful to screen readers, you can hide them with aria-hidden='true'. Once we add aria-hidden='true', VoiceOver in Safari and Chrome announces both elements as “Close dialog, button” and ignores the SVG and letter X.
On a web page that has a link that says “Learn more,” a sighted user might be able to use visual cues to understand the purpose of the link. However, since screen readers are able to present to users a list of links on a web page, links with unclear names can make it challenging for users to choose from the list. In order for a link to pass the WCAG Success Criterion 2.4.4, the purpose of the link must be able to be determined by the link text. When the purpose of the link is unclear, the .sr-only class can help make the link meaningful, thus helping users select a link without needing to understand the page.
<a href='accessibility.html'>
Learn more
<span class='sr-only'> about web accessibility</span>
</a>VoiceOver announces the element as, “link, Learn more about web accessibility.”
Aria-label
When an HTML element has the aria-label attribute, screen readers present the value of the attribute instead of the element’s content. Like the .sr-only class, the value of aria-label is not visible on the screen.
Using the aria-label attribute, the buttons in the first examples can be written as:
<button aria-label='Close dialog'>
<svg>...</svg>
</button><button aria-label='Close dialog'>X</button>
Labeling the buttons with the aria-label uses less markup than the screen reader only text method since it is not necessary to add aria-hidden='true' to the icons. VoiceOver in Safari announces both elements as “Close dialog, button.”
The aria-label values in the examples do not include the word ‘button,’ because including ‘button’ is redundant since screen readers announce the name of an interactive element.
A link can be given a meaningful accessible name with the aria-label attribute.
<a href='accessibility.html' aria-label='Learn more about web accessibility'>Learn more</a>Like the link example that uses .sr-only to visually hide text, with the aria-label attribute VoiceOver announces the link as “link, Learn more about web accessibility.
The aria-label attribute is strongly supported on interactive elements like links, buttons, and form controls, such as input. However, aria-label is not well supported on static elements for different screen readers. Furthermore, the aria-label attribute is not supported on various HTML elements, including code, caption, emphasis, paragraph, strong, subscript, and superscript.
MDN states that the aria-label attribute is only meant for interactive elements. The documentation explains that using the aria-label attribute on non-interactive elements can cause a confusing user experience or the label may not be announced by assistive technology. In the article “What happens with aria-labelledby, aria-label and aria-describedby on static HTML elements?”, David MacDonald shows that Microsoft’s screen reader, JAWS ignores aria-label on all static content except for content with “an interactive role, img role, or nav, main, search roles.” Additionally, the article shows that the aria-label attribute is not announced consistently by screen readers across browsers.
Based on my research, aria-label on interactive elements and landmark roles, is well supported. If you are adding a visually hidden accessible name to these types of elements, aria-label should be fine to use. However, it is important to test your web page with different screen readers across different browsers in order to check how screen readers are announcing the page.
I recommend using the .sr-only class whenever possible when adding accessible visually hidden content to a web page. Screen readers are not required to support ARIA. By using the CSS off-screen text method, you can ensure that the visually hidden content can be encountered by people using screen readers.
