CSUN Presentation, On-Demand: CSS Display Properties versus HTML Semantics
Presenter: Adrian Roselli
The work we do as accessibility practitioners is often anchored in the HTML structure of a page or screen. We provide guidance on which elements best map to the structure of the page or the semantics of the content, leaning on the designs, intent, and known behaviors in browsers and assistive technology.
What we often forget is that anyone can step in to work on the CSS and it can have devastating consequences for users. As responsive design has become the norm, as CSS Grid and CSS Flexbox have become more and more common, we are starting to see the consequences of browser bugs that have existed for years.
The CSS display property is arguably the most powerful and most risky CSS declaration any developer can include in a page. Browsers will take the values that you assign to an element and not just visually re-style the element (and probably its layout) but also override its value in the browser’s accessibility tree.
Something as simple as a table can be re-cast in the browser simply by changing its display to block. Responsive table efforts in particular are at the most risk, since all table navigation commands available to a screen reader user will be lost, and all structure imparting meaning between rows, columns, and headers are not conveyed.
The critical thing to understand through all of this is that, while it may be easy to blame the screen reader, this is the fault of the browser. Filing bugs is the first and most apparent step, but until the browsers catch up and fix these issues, the responsibility falls to developers to step in and code around these bugs.
We have some options in the form of ARIA. A developer can manually (or programmatically) assign ARIA roles to elements whose display properties have been changed. While is redundant and verbose to assign a table a role of table, a cell a role of gridcell, and so on, this can ensure the each HTML element’s semantics are re-assigned and passed along to the browser’s accessibility tree.
Sadly, ARIA alone will not work in all circumstances. Some browsers will ignore the roles you impart regardless of how you do it. The CSS will trump these values and you will be forced to decide between choosing new elements or undoing some styling that may be critical to the layout.
Ideally, the participants will leave better equipped with knowledge of the risks from CSS, better able to identify and file issues, and better prepared to perform testing to ensure these issues do not make it out into the wild. An even better outcome will be for participants to identify libraries and frameworks where they may have encountered these issues or which are at risk to do it, and file issues as appropriate with them as well.
Need help with your specific accessibility needs?