====== Tables and Grids ======

While it is possible to to use CSS flexbox and grid layouts to make any set of elements look like a table, you should use proper tables whenever both the horizontal and vertical axes contain information that is relevant to a cell. 

As [[https://sarahmhigley.com/writing/grids-part1/|Sarah Higley puts it]], the clue is whether items can be reflowed at smaller screen sizes without losing relevant information. Items that are organized into a grid for layout purposes where the column location is arbitrary, like a set of photo cards, should not be marked up as a table. If the data is the sort of thing where you might run your finger down one column and across the row to find a specific piece of metadata, as in a spreadsheet, then you should use a table. 

Screen readers like JAWS have [[https://dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts#jaws-tables|special commands and keyboard shortcuts to help visually impaired people navigate tables]]. These tools are not available for ''<div>''s and other non-semantic elements that might be laid out in grids using CSS. See [[https://www.htmhell.dev/adventcalendar/2022/14/|How screen readers navigate data tables by Léonie Watson]] (YouTube, 2 minutes).

Use ''<thead>'', ''<tbody>'', and ''<th>'' tags as needed to distinguish column and row headers from body cells. You should create the row and column associations with ARIA roles, for two reasons. For tables containing form inputs, we can [[https://adrianroselli.com/2019/05/uniquely-labeling-fields-in-a-table.html|recycle column and row headers to create unique form field labels]]. Also, when rearranging the contents of the table visually via CSS display properties, [[https://www.accessibility-developer-guide.com/examples/tables/layout-changes/#lost-semantics-due-to-display-changes|the built-in column and row associations will be lost, and screen readers will rely on ARIA]] to preserve the special keyboard navigation features for tables.

Tables can get visually crowded, which can create cognitive overload. Steve Schoger of [[https://www.refactoringui.com/|Refactoring UI]] has tips on [[https://mobile.twitter.com/steveschoger/status/897849211110273024|reducing the use of borders]] and [[https://mobile.twitter.com/steveschoger/status/913062604540653568|using alignment and padding effectively]] to make tables look less overwhelming. 

**Further reading on tables**

  * [[https://sarahmhigley.com/writing/grids-part1/|To Grid or Not to Grid, Sarah Higley]] Explains when to use ''<table>'' vs CSS-based grid layouts
  * [[https://adrianroselli.com/2017/11/hey-its-still-ok-to-use-tables.html|Hey, It’s Still Okay to Use Tables, Adrian Roselli]] Demonstrates how to mark up a table for accessibility
  * [[https://www.w3.org/WAI/tutorials/tables/|Tables Tutorial, W3C Web Accessibility Initiative]]
  * [[https://2017.code4lib.org/talks/The-Most-Accessible-Catalog-Results-Page-Ever|The Most Accessible Catalog Results Page Ever, Kate Deibel]] A  Code4Lib conference presentation on using table markup while rearranging the contents of each row with CSS to retain accessibility affordances while achieving more compact visual layouts
  * [[https://adrianroselli.com/2017/11/a-responsive-accessible-table.html|A Responsive Accessible Table, Adrian Roselli]] Demonstrates how to reflow table cells within each row for small screens (a simpler example than Kate’s)
  * [[https://www.accessibility-developer-guide.com/examples/tables/layout-changes/#lost-semantics-due-to-display-changes|Changing a table’s visual layout, Accessibility Developer Guide]] See "Lost semantics due to layout changes"
  * [[https://sarahmhigley.com/writing/grids-part2/|Grids Part 2: Semantics, Sarah Higley]] 
  * Testing tables: see [[https://www.deque.com/blog/axe-devtools-extension-update-new-intelligent-guided-test-for-data-tables/|Axe DevTools Extension Update: New Intelligent Guided Test for Data Tables]]
  * Abbreviations in table headers:
    * [[https://adrianroselli.com/2022/08/brief-note-on-calendar-tables.html|Brief Note on Calendar Tables, Adrian Roselli]]
    * [[https://github.com/w3c/aria/issues/816|ARIA issue: Columnheader roles do not work with the ''<abbr>'' attribute]]
  * [[https://adrianroselli.com/2019/05/uniquely-labeling-fields-in-a-table.html|Uniquely Labeling Fields in a Table, Adrian Roselli]] 
  * [[https://inclusive-components.design/data-tables/|Using ARIA grid roles for interactive tables]] (but not read-only or read-mostly ones)
    * “WAI-ARIA provides a role, grid, that is closely associated with tables. This role is intended to be paired with specific keyboard behavior, letting keyboard users navigate table cells as they would be able via screen reader software (using their arrow keys).
    * You do not need to use the grid role to make most tables accessible to screen readers. The grid-related behavior should only be implemented where users not running screen reader software need to easily access each cell to interact with it. One example might be a date picker where each date is clickable within a grid representation of a calendar month”
    * Another example: [[https://react-spectrum.adobe.com/react-aria/useTable.html|Adobe’s React ARIA UseTable]] (supports keyboard movement like a spreadsheet even though the examples are read-only)
    * Conclusion: role="grid" is for Excel-like web apps: Google Sheets, AirTable, etc.
  * TODO: Column widths and rendering vs. Bootstrap:
    * table-layout: auto vs fixed
    * Colgroups
  * [[https://adrianroselli.com/2023/02/avoid-spanning-table-headers.html|Avoid spanning headers]]
  * [[https://adrianroselli.com/2023/02/avoid-spanning-table-headers.html|Accessible sort controls - demo]]
  * [[https://frankieroberto.github.io/sortable-table/docs/|Sortable table with two-level grouped rows using multiple ''<tbody>''s]]


**Note**

[[https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sleary/grid-tables-and-column-widths|working branch converting eg-grid to tables]]