Many (most?) developers make the effort to choose HTML elements that best describe the structure and semantics of the content. They then use CSS to set the layout for the visual design. What they don’t know is how browsers use that CSS to break the HTML semantics. I will demonstrate issues and offer unfortunate workarounds.
2. • I’ve written some stuff,
• Member of W3C,
• Building for the web since 1993,
• Learn more at AdrianRoselli.com,
• Avoid on Twitter @aardrian.
About Adrian Roselli
4. HTML Tables
• We will use HTML tables as our proxy,
• They have a long history on the web,
• Used for layout and tabular data,
• Have a specific DOM structure,
• Have their own navigation features in assorted tools.
5. Basic HTML Table
• Just make a valid HTML <table>.
• Avoid spanning cells,
• Make sure you use <th> for headers,
• Add a useful <caption>.
6. Basic HTML Table
<table>
<caption>Books I May or May Not Have Read</caption>
<tr>
<th>Author</th>
<th>Title</th>
<th>Year</th>
</tr>
<tr>
<td>Miguel De Cervantes</td>
<td>The Ingenious Gentleman Don Quixote of La Mancha</td>
<td>1605</td>
</tr>
[…]
<tr>
<td>George Orwell</td>
<td>Nineteen Eighty-Four</td>
<td>1948</td>
</tr>
</table>
7. Complexity #1: Row Headers
• Continue to use <th>,
• Add the scope attribute using the values (as appropriate):
• row,
• col,
• rowgroup,
• colgroup.
• Conforms to WCAG technique H63: Using the scope attribute to
associate header cells and data cells in data tables.
9. Complexity #2: Spanning Cells
• Continue to use <th>,
• Every <th> gets an id,
• Every <td> gets a headers attribute
• The headers value is the id of the <th> you want it to use,
• Conforms to WCAG 2.0 technique H43: Using id and headers
attributes to associate data cells with header cells in data tables.
12. Responsive Tables
• Specifically talking about viewport width,
• Just let it scroll off-screen:
• Add tabindex="0" for keyboard users,
• Add role="region“ so screen readers announce it,
• Add aria-labeledby so screen readers give it a name,
• Set the aria-labeledby value to the id of the <caption>.
13. Responsive Table
<div role="region" aria-labeledby="Cap1" tabindex="0">
<table>
<caption id="Cap1">Books I May or May Not Have Read</caption>
<tr>
<th>Author</th>
<th>Title</th>
<th>Year</th>
<th>ISBN-13</th>
<th>ISBN-10</th>
</tr>
<tr>
<td>Miguel De Cervantes</td>
<td>The Ingenious Gentleman Don Quixote of La Mancha</td>
<td>1605</td>
<td>9783125798502</td>
<td>3125798507</td>
</tr>
[…]
<tr>
<td>George Orwell</td>
<td>Nineteen Eighty-Four</td>
<td>1948</td>
<td>9780451524935</td>
<td>0451524934</td>
</tr>
</table>
</div>
22. CSS Display Properties
• The following override native semantics in the browser:
• display: block
• display: inline
• display: grid
• display: flex
• display: contents
• Nothing in the HTML / CSS specifications mandates this,
• Does not work in reverse:
• display: table
• display: table-cell
23. Assistive Technology (AT)
• Browsers do not convey correct semantics to AT,
• Users who rely on these semantics can be stranded:
• Understanding content,
• Navigating a page.
26. Accessibility Tree
• A sub-set of the DOM tree,
• Includes UI objects of browser & objects of the document,
• Created in tree for every DOM element that:
• Fires an accessibility event,
• Has a property, relationship or feature which needs to be exposed.
37. ARIA Grid
• Do not use for simple data tables,
• Intended to mimic Excel-style spreadsheet,
• A grid is a composite widget so it:
• Always contains multiple focusable elements,
• Has only one focusable element in the page tab sequence,
• Requires the author to provide code that manages focus movement inside it.
• Ignoring for the purpose of this talk.
39. Assistive Tech Is Not at Fault
• Not screen readers’ fault,
• Accessibility information comes from browser,
• Screen reader needs more than DOM to understand page,
• Cannot ignore all but the DOM,
• Years of HTML tables for layout informed screen readers,
• Screen readers developed their own heuristics for dealing with tables.
40. Detecting AT Is Not Viable
• Users don’t want us to be able to detect screen readers,
• Not all screen reader users are blind anyway,
• Mouse actions are a poor proxy for sighted screen reader users,
• Disabling a site’s CSS for screen reader users is therefore impractical
(and a terrible, terrible idea).
41. CSS Is Not Blameless
• CSS already impacts HTML semantics — display: none,
• Using display: table does not impart HTML table semantics,
• CSS flex or grid makes it easy for content order and source order to
disagree,
• CSS grid to lay out an HTML table still won’t be a table semantically.
42. ARIA Is Not Ideal
• You must understand ARIA and the table structure,
• This will require you to keep current on screen reader and browser
support,
• You have to manage headers and other content you might hide,
• Consider how this scales with CSS does not load,
• This is not the purpose of ARIA,
• The technique here is a stop-gap.
43. The Browser Is Not Right
• The CSS spec does not state that semantics should be dropped,
• As display properties, there is no reason to remove them,
• The accessibility tree should not care about visuals.
45. Specific to Tables
• Only works with tables with tiny data,
• Keyboard navigation can be confusing,
• You have to re-rotate contents,
• There may be some mirroring involved,
• Generally not a good idea.
48. What is display: contents
• The element does not generate any boxes,
• Its children and pseudo-elements still generate boxes,
• Text runs as normal,
• For box generation & layout, element treated as if replaced in
element tree by its contents,
• As if opening and closing tags removed,
• Also yanks it from accessibility tree.
49. Why display: contents Is More Dangerous
• You cannot add it back to the accessibility tree with ARIA,
• You can give it an accessible name and properties,
• But these are not passed to screen readers,
• Browsers do not hand the information off,
• If used as a poor-dev’s CSS reset:
• Will hide elements from assistive technology,
• Will hide semantics from assistive technology.
56. Bugs!
• Firefox bug 1455357: Setting grid item to display:contents resets its
accessible role
• Chromium Issue 835455: Element not exposed to accessibility tree
when it is set to display: contents
• Safari bug 39630240 (which I cannot see because my AppleID may
not have the needed permissions to see it)
• CSSWG #2632: [css-display][css-aam][selectors-4] How elements with
`display:contents` get focused?
58. References
• It’s OK to Use Tables
• Hey, It’s Still OK to Use Tables
• A Responsive Accessible Table
• Tables, CSS Display Properties, and ARIA
• Tables, JSON, CSS, ARIA, RWD, TLAs…
• GitHub Contributions Chart
• Short note on what CSS display properties do to table semantics by Steve
Faulkner
• Data Tables by Heydon Pickering
• How display: contents; Works by Ire Aderinokun
• CSS3 — Appendix B: Effects of display: contents on Unusual Elements
In HTML5 they are referred to as term/description lists.
Description lists, dictionary lists, definition lists, damn lists, whatever.
These list types work together or separately.
We see them used for everything from navigation to panels in a carousel.
HTML has a great way to present information in two axes.
Coding them is easy, though it can be monotonous.
A series of rows, consistently coded.
A header.
A caption.
Sure, they can be a bit more complex, but that just adds some attributes.
Generally spanning is a bad idea, but it has its place.
Responsive design may have been the cause of some of this resistance to tables
Lists have fared much better.
Just let them be.
Tables are the bane of the typical responsive developer.
But there can be a much easier way.
That’s it, just let it scroll.
There are many cases where this is not ideal, but this is a good short term fix.
Response is not just about viewport width
Even if it were, a scrolling table may not cut it.
Print is a media query, just like width, so support it.
You likely will have to do nothing on a simple table.
Unless you are using background colors or images.
Perhaps you want to try a more novel way of adapting to a narrow width.
You can just rearrange the table cells using CSS.
CSS display properties just as block, grid, flex can all be powerful.
I convert everything in the table to block to make layout easier,
Dumps all the table, row, and cell styling,
I use grid on the cells to make it easier to add the ‘headings’ inline.
This is where things start to break
CSS as implemented in browsers today can remove semantics,
Conversely, you can not add it back with CSS
Using NVDA with Firefox
Hit T to get to the table
Using Ctrl + Alt + arrow keys to navigate the table
Announces column headings as I change columns
Tells me when at the edge
Using NVDA with Firefox
Hitting T will not bring me to the table
Using Ctrl + Alt + arrow keys will not work
Does not announce column nor row count
Does not tell me when I am at the edge
Table before CSS display properties on the left
Table after CSS display properties on the right
Note how the entire accessibility tree is gone
Caption before CSS display properties on the left
Caption after CSS display properties on the right
Its caption role is maintained
But it is not associated with a table
Th before CSS display properties on the left
Th after CSS display properties on the right
Not associated with the table
No computed properties
Td before CSS display properties on the left
Td after CSS display properties on the right
Not associated with the table
No computed properties
There is a long aversion to tables owing to their mis-use for layout.
So some people try to use other HTML elements,
They opt to “throw ARIA” at them.
Using NVDA with Firefox
Hit T to get to the table
Using Ctrl + Alt + arrow keys to navigate the table
Announces column headings as I change columns
Tells me when at the edge
ARIA grids are a terrible idea and are not for data tables.
How do you account for those with mobility impairments who do not use a mouse?
Or mobile screen reader users who rely on touch gestures
Think about how it used for vertical centering
Maybe not?
Use this as a quick aside.
Just a demo, the animation is there just to show what happens
The tab order can be confusing
A screen reader user will notice no difference
No need for ARIA
I am seeing this quickly become the new hotness.
I want to call this one out specifically.
Table before CSS display properties on the left
Table after CSS display properties on the right
Note how it is ignored in the accessibility tree
The role does not bring it back
ul before CSS display properties on the left
ul after CSS display properties on the right
Note how it is ignored in the accessibility tree
The role does not bring it back
button before CSS display properties on the left
button after CSS display properties on the right
Note how it is ignored in the accessibility tree
The role does not bring it back
h2 before CSS display properties on the left
h2 after CSS display properties on the right
Note how it is ignored in the accessibility tree
The role does not bring it back