Born accessible table summary

[LaZay]

What problem are you trying to solve?

HTML5 has removed plain text @summary attribute on tables.

Accessibility tables summaries and general tables summaries should be different:

• An accessibility summary is dedicated to AT users. It must describe the organization into columns, and lines. In the first place, it will help people decide wether they can risk diving into the table, or not (on a quantity base: number of lines and columns). In the second place, knowing what information is designed in columns, and what information is designed in rows, it will help understand the AT reading order, and the keyboard navigation into the table (with left, right, up and down keys). Such a summary should be invisible, as columns and lines organization is already visible from people without a visual impairment. It can be automatically generated on the base of table's structure.
• A general table summary interests everybody, including AT and non AT users. It either provide the key information represented as a table, or the intent underlying a complex table to help reading/understanding it. It should be visible, and accessible from everybody. It is written by a human (or an AI).

As consequence, both tables' summaries should be distinguished, which is still not possible in HTML5.

An accessibility summary is always a plain text (this includes table's summary). The so called <summary> tag under a <details> tag is rather a label for what follows. As a matter of fact, the table's summary should not be put in the <summary> tag, but in its following <p> tag.
https://kb.daisy.org/publishing/docs/html/tables-summary.html

What solutions exist today?

When no general summary is needed, we now need to create a highly complicated HTML structure for a simple accessiblity summary:
<table> / <caption> / <details> / <summary> + <p>.

When two summaries are needed, we are forced to merge both summaries into one, which is not satisfactory for people without a visual impairment.

How would you solve it?

The complex hierarchy of <table> / <caption> / <details> / <summary> + <p> is perfectly suitable for general summaries.

For accessibility summaries, why not simply add an @alt attribute on tables?! That would be much easier for everybody, i.e. HTML authors, and AT developpers.

Anything else?

No response

[annevk]

cc @whatwg/a11y

[LJWatson]

• An accessibility summary is dedicated to AT users. It must describe the organization into columns, and lines. In the first place, it will help people decide wether they can risk diving into the table, or not (on a quantity base: number of lines and columns). In the second place, knowing what information is designed in columns, and what information is designed in rows, it will help understand the AT reading order, and the keyboard navigation into the table (with left, right, up and down keys). Such a summary should be invisible, as columns and lines organization is already visible from people without a visual impairment. It can be automatically generated on the base of table's structure.

Your use case seems to be screen reader users who cannot see the table structure. If so, the information you describe is already generated automatically by the browser and screen reader via the accessibility tree, so it's not immediately apparent what you're proposing?

[patrickhlauke]

+1 to what @LJWatson said - information about the overall structure is already conveyed programmatically and exposed by screen readers/AT (whether or not SRs have then idiosyncratic ways of how they announce this structure is a topic to discuss with the respective SR developers). while SRs don't (currently/generally) go into much more detail (such as listing the full set of column and row headers, in isolation), that's generally (from my experience anyway) something that an SR user will explore for themselves once they're in the table.

if, as an author, you want to convey this extra information though, there are various other mechanisms already available - such as using aria-describedby pointing to a container with more explicit description of the structure (which, if purely intended for SR users, could be visually hidden). though arguably any extra description/hint about how the table is organised, if you feel that it's necessary to understand the table, would probably serve all users, not just SR users (e.g. users with cognitive disabilities, low vision users that don't use SRs, etc)

[stevefaulkner]

Also aria-description can be used to provide SR only text

[patrickhlauke]

Also aria-description can be used to provide SR only text

hah, snap, I just updated my previous comment (mentioning aria-describedby but same applies to this)

[LaZay]

Thanks for your answers.

My usecase concerns screen readers that see the HTML DOM tree, but do not calculate any accessibility summary (as far I know).

The aria-description attribute sounds the best solution for authors to statically provide this plain accessibility summary.
All screen readers could eventually provide such a service one day, and dynamically calculate such a summary for every structured table. But who is responsable for what today, to make tables fully accessible? The WCAG v2.2 1.3.1 still considers it is on the authors' side.
Technique H73: Using the summary attribute of the table element to give an overview of data tables.

PS: I am still puzzled with the alt attribute on some HTML elements only (area, img, input), when others need ARIA descriptions. Historical?

[aardrian]

As noted, the structural aspects of the table are already conveyed (number of columns and rows) and authors do not need to state that information.

Since a summary would (or should) be tailored to the audience as much as the data, creation is rightly left to authors. All H73 does is tell authors which attribute to use (for HTML4 and XHTML) for that summary, not that the browser creates the summary.