What Summary Tables Should Be Included in Core?

Thanks for the welcome and encouragement to contribute Cliff. :-)

I came across this yesterday in the Views issue queue and am throwing it out as one possible approach. It's a patch for views_plugin_style_table.inc so that if your display shows your data as a table, there is an additional field you can fill out for the summary of the table. It also changes views-view-table.tpl.php so the summary is printed out. (And as is noted in the issue queue, the patch still should be modified so check_plain is used for the summary.)

Add option to set summary attributes in the html table (Accessibility)

(As a side note, I'm going to think about this approach for adding the header tags in for columns/fields for tables as well. Modifying the table plug-in for Views might be a better approach to make the tables used to present forums more accessible than working with the Advanced Forum module via preprocessing functions and templates with my theme.)

@mgifford: Yes, I'd like to look at your sandbox. I'll look forward to it.

I should have been more specific when I mentioned headers. I meant the headers attribute in

tags. (Here's the WCAG technique reference: H43) I know there's great overlap with the "scope" attribute. I picked the headers attribute to start with just because I needed to dive in someplace. (I'm starting to think the implementation for each would be greatly similar, or even could be accomplished in the same few functions; the user [web designer] would decide which to display (or both), I'd think.) (I started to spin off thoughts about the "headers" and "scope" attributes, and how these could be accomplished in core 7.0 and beyond. But I think these comments should go in a different thread.)

I'm also learning about the differences between the different screen readers and different versions of each, what attributes they do and don't pick up on, etc. This is just like coding for browser differences, except it seems like the readers are in a less mature phase than where the browsers finally are -- meaning there's less standardization or agreement, so the variances are wider. And it seems to me that there are more likely to be users with older versions of readers, since, unlike browsers, it's not always free to upgrade. Is this right? (Since I'm relatively new in this particular domain.)

And I'm not aware of places where drupal core uses

when should be used. But I confess I haven't looked with any great focus... yet.

Are there already thoughts out there about the scope and direction of a summary attribute?

Forums are the most common instance of data tables in core. Are they the only instance?

Re a summary attribute for a forum: Is it true that adding a summary for a forum means we need to track a new piece of data ( = adding a new column to a table in the database)? The summary is not quite like the description of a forum, in that the description can be long and, as the user is prompted in the UI for editing a forum, should be "Description and guidelines for discussions within this forum." So really, there should be an element on the 'edit forum' form: a text field for the forum summary, with a prompt for the user along the lines of "Type the main purpose of the forum in one or two brief sentences." And there could be an additional text field where the forum creator/editor can enter their own description of the structure, or leave blank to have drupal core generate it based on the columns shown for the forum. The prompt for that field might be "Enter a brief description of the structure of the forum (the columns), or leave blank to have Drupal create this description for you. This will be appended to the summary purpose and be presented as the value of the "summary" tag."

Is that along the lines of what should be done and/or could be done?