Adding Caption/Summary tags to Table/Grid display

This is an important issue in regards to accessibility and so I am changing this to a feature request.
Bumping to *-dev as well.

It is important to allow the user filling in the webform to populate the table caption and/or summary.

There is now a precedent in Core (in D8) to deal with this. Most of this isn't user focused though, right?

7.x-3.x is now receiving only critical bug fixes. Is this still an issue for 7.x-4.x? If so, patches are welcome.

I have attatched updated 2 versions of a patch I made a while back to support this.

While looking at the original patch, there seems to be some things that need review or need changes.

It appears that I wrapped the grid/table in a fieldset.
From what I managed to remember, when the values are associated with the grid and there could be multiple input fields, those fields all likely should be associated with the wrapping 'grid/table'. The only way to do that is a fieldset.
I do not believe using a table by itself will communicate the association between the fields.

I would be fine with not wrapping the grid/table in a fieldset.
My only concern then is whether or not users would realize that they likely should wrap the grid/table in a fieldset.

My patch also added the style: padding: 0px; margin: 0px; border: 0px none; to the added fieldset.
I am not sure why I did that instead of element-invisible.

What did D8 do? Would caption be better? It seems that summary is only to describe the structure of the data.

I found this at we aim.org:

The summary attribute of the

tag may be used to provide a summary of a data table structure (not content). Support for summary varies, but in general, it is screen reader specific (it's not accessible to anyone else) and is not well supported. Additionally, the summary attribute is not part of the HTML5 specification. In general, if a table is so complex that it needs an explanation of how it is structured, it probably is not very accessible and should probably be simplified. For these reasons, we do not recommend the use of summary. If it is used, it must never be used for layout tables.

"The summary attribute on the table element is obsolete." - http://www.w3.org/TR/html-markup/table.html

You can do a lot with Detail/Summary though:
http://www.developerfusion.com/article/136530/making-tables-more-accessi...

Looks 2 years later and they changed (or clarified) their wording on webaim.org.
Not having summary should make life easier and, in my opinion, the page itself tends to be the summary of the overly complex tables.

So the method in which the summary is added as an attribute is obsoleted.
Is adding a summary, such as via the mentioned HTML5 method, itself obsoleted (In terms of accessiblity standards like WCAG)?

In most cases I don't think that Drupal tables need a summary. It's useful though for some sites. It's geared for more complex data than is generally produced with a typical Drupal table.

Summary attributes are no longer supported, but the idea of adding a summary (using Details) isn't obsolete as far as I know. We've included it in D8, so I hope not.

My opinion is that a summary is not needed for a grid component because it has straight-forward row/column semantics. This is no non-standard / tricky layout which would require extra documentation of the structure to a screen reader.

We are presumably considering a screen reader using the component, primarily as a form and to a lesser degree as viewing a completed submission. For the form, it would seem to me that the description or a markup component could be used. For the display of the submission, the description isn't shown and by default markup components aren't show. Markup components can, however, be shown by overriding the theme function.

At this point, I think someone needs to present a compelling use case why this should add a feature in this area in the 7.x-4.x branch. I can see that maybe something might be added to the D8 version to take advantage of the summary and details tags.

@DanChadwick sounds like a good approach to me.

Closing to clear out the old Webform 8.x-4.x branch. See #2827845: [roadmap] YAML Form 8.x-1.x to Webform 8.x-5.x.