Importance of CSS for accessibility and semantics

(Read 1339 times)

Semantics is how things reflect structure and meaning and Cascading Style Sheets (CSS) can change all that. So CSS can have huge impact on accessibility as well. Be mindful about it and forget about pixel perfect first – think user first, pixel second.

First things first – semantics is how things reflect structure and meaning. So why are Cascading Style Sheets (CSS) important for semantics then? Do they change the meaning or structure? We can easily confirm that CSS can define structure, especially with floating or flexbox ordering and grid’s named areas and so on. But meaning – can CSS also change meaning? Short answer is yes, let’s check what does that mean.

CSS can change meaning of HTML elements

The display property in CSS is quite powerful and also important in accessibility. It’s display:none can for example hide whole parts of the page from assistive technology like screen-readers. That is well known and should not came as a surprise – a really good universal design property – hidden for all users. The same goes for visibility:hidden. Hiding it for all users.

But it may come as a surprise that setting display:block or display:flex or even display:grid on a HTML table can remove all of it’s semantic meaning for assistive technologies. That can easily break the experience for the screen-reader users. No more automatic table rows and headings mappings. No more navigating through tables alone.

The other surprise, for me at least, was lists items. List items are supposedly useful also in navigation, because screen-reader users get number of items in navigation and may give them better overview. Different users have different opinions, as always, but I think it sounds sane – to be able to perceive the dimension of navigation. But setting list-style to none is used quite often, to remove bullet points from such lists and to make them horizontal. It may come as a surprise that some screen-readers then ignore the list and therefore we miss the semantics of list in navigation. I thought this was a bug but authors responded that they wanted to help with preventing overuse of lists, arguing that lists are used too often and adding to clutter for screen-reader users.

Another example related to CSS causing changes for accessibility is manually setting content with CSS. It does not change semantics but adding textual content with CSS should be avoided. Some screen-readers do get the text that is set with content but some do not. So better to avoid it and just use it in the HTML. As you may know – CSS can easily be changed or removed by the browser, user settings and all. Or even maybe not loaded or changed by some operating system feature (like high-contrast-mode).

Ordering of elements should be done in HTML and avoided in CSS

Sometimes we must change the order of elements. It can easily be done with CSS, in these days of CSS grid we can simply move all parts even by name. But that breaks the natural flow for keyboard navigation. So this means that we introduce potential barriers for end-users. That’s why it can fix the visual positioning but break keyboard experience and introduce challenges for sighted screen-reader users.

That’s why it really is better to avoid changing of order with CSS. Visual order should respect logical ordering to really make things work for all kind of users.

Users may want to set their own CSS, so do we need pixel perfect designs

This one is easy to forget about. Designers and developers invest a lot of effort to make webpages feel and look nice. Sometimes they can get too detail oriented and we can say they want to make their work pixel perfect. Designers think more and more about mobile first and literally millions of different screen-sizes, but quite often still deliver briefs and plans defined in pixels. Developers then take the pixels literally into CSS and make their work as much pixel perfect as possible.

This pixel perfect ambition can introduce barriers for user settings. If developers lock-in the main CSS in absolute values, like pixels are, it may be difficult or even impossible for users to take over with their custom settings. That’s why WCAG specifically mention text spacing possibilities in the 1.4.12 success criteria – text spacing (opens in new window).

I will not go into details in this post but Windows High Contrast Mode (HCM) is actually also changing CSS behind the scenes. So in theory – our pixel perfect designs can easily become something quite custom. And that is the right of the user – setting their own text properties, or even custom fonts and colors. Anything that can help them use the internet.

We can conclude – CSS can reach beyond visual presentation

CSS is not only for visual presentation, although it is it’s main role. But when we think about the diversity of users and devices we should make the pages work without locking them into CSS. So it is useful to check the page with CSS turned off and check if everything is working well. Maybe even use HTML attribute hidden instead of CSS class based display:none when we would like to really hide something from the user.

CSS is a presentation layer on top of HTML, it’s render blocking by default (browser waits for it to be downloaded and interpreted before it can continue with rendering), so it is also adding to complexity for assistive tech. Ideally would each site only download and process CSS it really uses and by doing so offer the page more quickly, but that goes beyond the scope of this post and accessibility aspects.

Be mindful about your CSS and remember that user can take full control and your pixel perfect design should rather be robust than limiting.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as Agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work.

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: