By Dani Belvedere
One of the things we hear about often from accessibility professionals is the expectation of HTML5 as the ultimate accessibility solution. While it can be approximately 80% true, CSS might also be introducing a number of accessibility issues that we must check.
1. The usage of property text-transform
Frequently used to capitalize words or change lowercase text to uppercase, this property causes problems by understanding capital letters as acronyms, so, instead of reading the word, a screen reader spells it.
A common example is “FOLLOW US” being read as “Follow U S” which appears as though we are guiding the user to follow the United States.
Possible solution
Use of aria-label with lowercase text or aria-labelledby pointing to the ID of one span (or another non semantic HTML element) with lowercase text.
<button class=”uppercase” type=”button” aria-label=”register”>Register</button>
2. The usage of property display
This property looks very innocent, but its most troublesome values are:
- inline-block
- inline-flex
- table
- flex
Inline blocks
When the value for the display CSS property is inline-block, the screen reader will read all content at once, (e.g., when reading buttons, it will read “accept” and “cancel” in the same sentence.) This is problematic and confusing for users, as they won’t know which of the two buttons is activated when pressing the space bar or enter key (by default, both keys should activate a button). Furthermore, this alters arrow navigation with the use of the screen reader.
Flex
This is a recurring problem used frequently by developers without discretion. Often, they’ll change the arrangement of elements using the properties flex-direction and align-self to match the designers’ expectations. The visual result is very easy to achieve – only a few lines of code in our CSS and it’s done – but it breaks the navigation sequence for people with motor impairments who use keyboard-only interaction. For both navigation systems, using the TAB key or the arrow keys, the screen reader follows the arrangement in the document object model (DOM) and not the order in which the elements are displayed on the screen.
Table
This value causes the screen reader to interpret that there is a table. Depending on the content, using this value can cause problems, but sometimes it comes in conjunction with the use of display:table-cell in the child HTML elements.
The usage of “content”
In the pseudo-elements ::before and ::after, the value inside the property content is read by the vast majority of screen readers. This element is generally used to add iconographies or change the design of an input type checkbox or radio. The best solution (in my honest opinion) is to simply add those iconographies or emojis in a span hidden for the screen reader.
<!DOCTYPE html>
<html>
<head>
<style>
.icon-mail::before {
content:’?’
}
</style>
</head>
<body>
<p><span class=”icon-mail” aria-hidden=”true”></span> Contact</p>
</body>
</html>
3. Usage of list-style-type
This is a problem that occurs only with Safari and VoiceOver. Removing the bullet using the “none” value for this attribute removes the list semantics, and the screen reader does not annotate the items as a list. If we can avoid removing them and instead change the color (use something from your brand guidelines), that would be best.
If keeping the bullet is not an option, consider adding aria role=”list” to the <ul> tag.
Conclusion
It’s not always easy finding the time to test for accessibility, but it is important. Whenever possible, test code using assistive technology such as NVDA or test focus interaction using the TAB key to ensure all users will have the ability to interact with your content.
Why it Matters
According to the World Health Organization:
- Globally, at least 2.2 billion people have a vision impairment or blindness
- More than 7 million people lose their vision each year
Small CSS changes can simplify and improve life for so many. Why not take the time to do it right?
