[META] Improve context in admin UI tables for accessibility.

Problem/Motivation

Drupal core's admin UI makes extensive use of tables to list content and configuration.

There are a number of things we could do to improve the semantics of our admin tables, which will benefit users of assisitive technology.

Row-level table headers

Screen-readers can annouce the row + column headers for the current cell, but currently we only use column-level headers. In the abscence of row-level headers, some screen readers will treat the first cell in the row as a header, but in Drupal this is often a checkbox or tabledrag handle. Explicit row-level headers would be clearer.

Table captions

These help a user understand the point of the table, without having to explore inside it:

• On entering a table, a screen reader user is given the caption. Helpful to confirm you have the right table, or if you want to skip the table entirely.
• Screen readers have tools to let users skip from one table to the next, or identify all tables on the page (e.g. the macOS VoiceOver WebRotor). This is especially important on pages that have more than one table. Current examples of these include:
  • Views UI listing - enabled and disabled views are listed in separate tables.
  • Workflow UI - content moderation has 3 tables, for states, transitions, and eligible content entity bundles.
  • Display modes - There are 5 tables on the View modes page after a standard install. This could grow to quite a lot of tables, if as more modules are enabled which provide entity types (Commerce, Registrations, CRM, Media, ECK, etc.).
  • The Modules page. There's a table for every package group, so there's really no limit to how many tables could end up on this page. I checked a modest D8 site and it already had 20 tables. Captions would be enormously helpful for finding the right package group, as there aren't any headings for them.

Proposed resolution

Add row-level table headers to tables in the admin UI.

• #2962585: Treat entity label as a row-level header in entity list tables - this can fix most listings of configuration entities.
• #2770835: Add support for tables with two headers in views table display - this is needed to enable row-level headers in most of our admin views for content entities. Since it's a general purpose feature for Views table displays, it will also provide lots of flexibility for site builders to improve tables on front-end pages.
• Individual content entity views will need installation config changes.
• Some existing Drupal sites will already have customized their admin views. Don't change those, only change installation config for new sites.
• Style for row-level headings in Seven theme. NEEDS CHILD ISSUE? Already had some discussion in #2770835: Add support for tables with two headers in views table display
• Style for row-level headings in Bartik theme. NEEDS CHILD ISSUE? Already had some discussion in #2770835: Add support for tables with two headers in views table display

Add table captions to most (probably all) tables in the admin UI.

• Decide what captions to use for individual tables. Fix these in child issues?
• Views table displays already support captions, but we aren't using any for core admin UI tables yet.
• Tables from EntityListBuilder subclasses can have captions added via Form API properties.

Miscellaneous other improvements

Make sortable columns easier for all users to understand.

We need to convey the "sortable" column behaviour, and "currently sorted" column state, to all users.

• Currently in Seven, sortable columns are identified by colour alone (if they aren't currently sorted, focused, or hovered). Level A WCAG failure of success criterion 1.4.1 Use of Color. NEEDS DESIGN CHANGE.
• #3038386: Improve accessibility of Views table sortable columns
• #2782111: Add aria-sort attribute to Views table output

.

Remaining tasks

Most work is in child issues.

User interface changes

Adds explicit labeling to tables in the admin UI, in a way that can be identified programatically by assistive technology. Screen reader users are the main group to benefit from this, but some other assistive technology may beneift too, e.g. switch access or speech control.

This won't necessarily mean any visual changes to the UI. Table captions can be visually-hidden in most cases.

API changes

None.

Data model changes

None.