I came across a bizarre experience while testing a Styled-Component prototype with VoiceOver and Chrome. This simple panel had an H2 in the code, but I couldn’t navigate to it with the screen reader. I opened the accessibility inspector in Chrome and sure enough, the H2 had no semantics. It was being rendered to the Accessibility API as if it was a div.

HTML code with an h2 heading
This code snippet shows an H2 using styled components
Accessibility inspector in Chrome

Could this be a Styled Component Issue?

This led to a lot of research to see if Styled Components were stripping the semantics from HTML. Nobody else had seen this and I couldn’t find any relevant details of Styled Components breaking accessibility.

Testing the CSS

With the exception of display:none and visibility:hidden, CSS shouldn’t affect the accessibility of an element. But we started to evaluate this item and removing the classes restored the semantics of the H2. After breaking it down, we realized display:content was the culprit.

With the exception of display:none and visibility:hidden, CSS shouldn’t affect the accessibility of an element. But we started to evaluate this item and removing the classes restored the semantics of the H2. After breaking it down, we realized display:content was the culprit.

Display:contents is meant to make it easier to use grid layout. It’s removing the display properties of an element and allowing its children to be styled. However, there’s a bug in various browsers that also strips the semantic value of the element, not just the display. This is best described by Hidde de Vries in the article More accessible markup with display: contents.

With display: contents, we can have our markup and our grid placement. This property makes the element so that it no longer seems to exist. It does not generate a box, so backgrounds, borders and other box-related properties will no longer work on it. Grid placement properties will also no longer work. But all of these things will work for the element’s children. The spec says the element behaves ‘as if it had been replaced […] by its contents’. If that sounds weird, I can recommend Ire Aderinokun’s detailed explainer.

Hidde de Vries, More accessible markup with display: contents

I’ve created a test page to see how display:contents will affect different HTML tags, such as h3, label, button, etc: Display:Content stripping semantics

Hidde has also created bugs for the major browsers. It looks like this has been solved in Firefox, is close to being solved in Chromium, and is still an open bug in WebKit.

Firefox 61

The list gets a role of text leaf (Firefox bug). Update: this is now fixed; it will ship in Firefox 62 in August 2018

Chrome 66

The list shows as ‘accessibility node not exposed, element not rendered’ (Chromium bug).

Safari

The list shows as ‘no accessibility information’ (Safari bug, Webkit bug)


No Responses to “Display:Contents and the Impact on Accessibility”  

  1. No Comments

Leave a Reply