When Chris Coyier presented his approach to responsive data tables, I wondered about the implications for accessibility, particularly for screen readers. This was especially so since the approach involves replicating each of the table's column headers as CSS-generated content for the relevant table cell, and presenting each data cell, together with this generated header text, as a block-level element. In this way, the table's data is presented in a single column, as it were, with each data cell appearing on a new line alongside its associated, CSS-generated header text.
I wondered, assuming that the CSS-generated column headers were read by screen readers, if the screen readers would repeat the header text when navigating the table using their table navigation commands, once for the actual column header in the HTML, and once for the CSS-generated header text.
NVDA and VoiceOver
It turns out that NVDA with Firefox and VoiceOver with Safari both read the CSS-generated content. More importantly, in both cases the responsive data tables are not registered as tables at all. In the end, interacting with and reading responsive tables like this seems fairly straightforward with these screen reader and browser combinations.
From what I can tell, because the responsive version of the table, as well as its thead, tbody, th, td, and tr elements, are all set to display:block;, the table isn't recognised as an actual table. In fact, this seems to be the case even if just the table element itself is set to display:block;.
I don't fully understand the ins and outs of accessibility APIs, so what follows is my best effort. In Firefox, the regular data table that is not set to display:block; is identified to the IAccessible2 API with a role of "table", while the responsive version of the table with display:block; seems to end up with a role of "paragraph".
In Safari, things are a little stranger. Even the non-responsive regular table doesn't get registered as a table by VoiceOver for some reason. That is, VoiceOver doesn't recognise that there is a table present, and the Control+Option+Command+T keystroke for moving to the next table on a page does nothing.
Checking Apple's Accessibility Inspector, the regular table's cells are identified to the Mac Accessibility API as having an "AXRole" of "AXGroup", presumably some more generic and non-tabular type of role. However, after adding a caption to the table, all of a sudden VoiceOver is able to find it. In this case, Safari identifies each table cell to the Mac Accessibility API as having an "AXRole" of "AXCell", which makes sense, and the table itself has an "AXRole" of "AXTable", whereas previously I was unable to determine what "AXRole" the table had, if any.
With the responsive data table set to display:block;, even after adding a caption, the table is not identified as such. So in Safari, the use of display:block; on a table seems to have the same effect as it does in Firefox.
I figure this is why, with those screen readers in those browsers, the responsive tables tend to work so nicely. The screen readers don't consider them tables and don't enable their table navigation commands. They simply read each (generated) header as text and then read its associated value, without identifying any tabular structure. There is no repetition of both the HTML and CSS-generated column headers when moving from cell to cell. For all intents and purposes, there are no data tables or cells to navigate.
So I'm impressed with the responsive table's behaviour in these screen reader and browser combinations. As far as I can tell, however, this has as much to do with how the browser is identifying the table with display:block; to the relevant accessibility API, as it does with the use of the media queries and CSS-generated content.
What About JAWS?
Note: Because of a problematic rendering issue in Internet Explorer 9 with tables set to display:block;, Chris' example does not work with IE.
JAWS 12 in Firefox doesn't behave the same. It appears to treat the responsive data table as a data table, and enables its typical table navigation commands. At the same time, JAWS doesn't seem to be reading the CSS-generated column header text. As a result, using JAWS' regular table navigation commands, the table's content is navigable as if it were a normal data table. This is probably fine for a blind user, who won't realise the disjunction between what is presented on screen and what JAWS is telling her. But for a sighted user working with JAWS, I imagine there could some confusion since the table's content is not visually laid out as a table, and the CSS-generated column headers that are visibly repeated for every cell will not be read out loud.
Obviously, in the case of an iPhone or iPad, or similar, for which the CSS media queries are largely intended, the behaviour of JAWS for Windows is not an issue. Still, for the admittedly very few users that might be using JAWS with Firefox set to a narrow enough viewport to engage the CSS media query that changes the table's layout, what's going on may not be very clear.