Skip to content

Instantly share code, notes, and snippets.

@coderkind

coderkind/table_accessibility.md

Last active May 16, 2018 21:30
Show Gist options
  • Save coderkind/fcdb3a057a6adf8e25dcf9c3bc40110a to your computer and use it in GitHub Desktop.
Save coderkind/fcdb3a057a6adf8e25dcf9c3bc40110a to your computer and use it in GitHub Desktop.
Download ZIP
Raw
table_accessibility.md

Table Accessibility spike

https://jira.dev.bbc.co.uk/browse/CONNPOL-4930

The high-level issue

We want to effectively communicate tabular data to all users across all devices

The low-level issues

Visual/UX

  • Large HTML tables don’t easily fit at narrow breakpoints (if at all… depending on the dataset)
  • At narrow breakpoints, the way visual users process tables changes (due to the need to scroll). Tables are likely to be read sequentially, with visual scanning and cross-referencing of table cells reduced
  • Historically in Elections, we’ve resorted to hiding certain columns at breakpoints to achieve a visual design. This approach leads to version disparity between visual and AT users (with visual users likely having less data available to them at lower breakpoints)
  • Visually, does tabular data remain “tabular data” at narrow breakpoints? Unless you vertically fix column headers on-scroll to remain at the top of the table, once you scroll down you subsequently lose headers and cell context and you’re only able to view a subset of the complete dataset. Hard-dedication towards always presenting tabular data as a HTML table might actually compromise our ability to communicate data effectively

Technology (Browsers/AT)

  • Conceptually, there should be a separation of concerns when it comes to table HTML code (semantics) and CSS (presentational), but in reality both have an impact on how AT processes and copes with tabular data
  • CSS support for HTML tables in AT is constantly changing (improving?). This is reflected in past Election table coding assumptions (being safe to alter display properties of table elements to achieve table layouts at lower breakpoints) not necessarily holding true any longer. We're attempting to make tables work against how things perform today
  • Table reliability, if anything, appears to be falling: https://www.powermapper.com/tests/screen-readers/tables/, dropping from 80% reliability in 2016 to 77% in 2017. Standout figures are VoiceOver iOS (40%) and NVDA IE (60%). Are we coding against internet standards, or potentially unreliable AT manufacturer implementations?
  • Limited scope to target specific AT to patch particular bugs or quirks - after we’ve semantically coded a table, applied aria rules if appropriate, and potentially added visually hidden text, ALL AT is subsequently free to deal with those as they see fit. Historically we’ve been able to feature-sniff in JS or apply certain CSS rules via a variety of techniques (CSS hacks, conditional comments, etc) in order to patch “problem” tech, but with AT it appears that whenever we attempt to code around issues, we’re left hoping each vendor deals with the workaround consistently (which isn’t the case, e.g. Read&Write and visually hidden text - unless this specific example is down to an issue with Grandstand's visually-hidden vh CSS rule)
  • Browser vendors employ arbitrary rules in determining if a table is a data table (https://vimeo.com/139062429, from 16mins), or a presentational table and subsequently applying no semantic value to the contents within. This is historical baggage we have to contend with as browser vendors don't want to "break the internet" for older websites that might've used tables for layout. Semantically coding tables with caption, thead, tbody should leave us controlling whether our tables are interpreted as data tables, but we should be aware of the hidden fallback decision tree that's used by browsers

Workflow

  • Traditionally we’ve adopted an insular, reactionary response when dealing with table accessibility quirks which in the grand scheme of things does little to fix user experience across the internet (i.e. we haven’t reported bugs we’ve discovered to AT vendors). This means we’re not helping to fix the internet, and we have no line-of-sight of when bugs are fixed

Suggested approach

  • Definition list at narrow breakpoint visually displayed (controlled via CSS media query)
  • Table displayed visually at wider supported breakpoints (controlled via CSS media query) - the first breakpoint where the dataset size and UX is able to be conveyed effectively as a table without CSS hacks to cells or columns
  • Option for user to switch between these two always available to those using AT (visually hidden, but selectable), and the option for the choice to be available for visual users (UX/Product decision)
  • If (big “if” - I would suggest we probably wouldn’t want to give visual users the choice 99% of the time) we visually provide the option to switch between lists and tables, to avoid large tables breaking layout at narrow breakpoints then we surround the table in a horizontally scrolling (overflow) wrapper DIV, along with visual clues that indicate that horizontal scrolling is possible (in case the table is cut off cleanly at a given browser width)
  • Switching between list/table view achieved without JS using a checkbox and associated :checked CSS to show/hide elements (rough demo is WIP - needs cleaning up)
  • Minimal JS required to assign aria roles when toggling between list/table views
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment