Forum Module Should add Scope attribute to <th> tags

I expect that scope is mostly useful when there is a

I'm not sure how this expresses itself in AT, but it's easy enough to find folks calling for the use of:

<th scope="col">

Veerle describes it here:

It gives you 2 advantages. It makes the table more accessible for people using a screen reader. Secondly, it makes it easier to style with CSS. You can give all th elements another styling that sets it appart from all other cells which are using the td element. Adding the scope attribute will help people with screen readers to understand the table better. We easily make the connection between the headers and the data cells, but people using screen readers can't if there are 2 kind of headers: one referring to a row and one referring to a column. We use the scope attribute to explain how the headers work and how they are connected with the data cells.

Then there's the Web Accessibility Tutoral's take on accessible table data and also going back to Section 508 (even though it is currently being reviewed). §1194.22 (g) Label Row and Column Headers:

Use the table header markup (th) for header cells of your data table and for corner cells where the scope in ambiguous add the scope attribute, with the value row or col. Instead, you may use a td element for header cells when you add the scope attribute, scope="row" or scope="col", to specify header cells.

There are articles like Use the scope attribute with table headers & others.

But really, this may not be either the best place to do it or might just be a nice idea that doesn't really provide direct benefits to users of AT.

Any additional thoughts on this?

So often the corner cell is left blank which is pretty useless. I've advocated for adding an invisible element here:
#821702: Replace Forum Icon Column with Topic Span

Please let us know what you find out about the use of scope in practice. And ya, good to code to a standard even if it isn't.

Bringing over comments from my sandbox generated by @jasonkiss - I'm bringing it over here because occasionally I have to restore the D7 sandbox and start from fresh.

headers attribute and/or scope attribute

This is really just a test post. But I'm going to type some "real" content in here.
It's really unclear if most screen reader software can use the "headers" attribute, the "scope" attribute, or both. And more than that, it's not clear if *users* look for and/or use the "headers" and/or "scope" attributes when examining tables and looking at the data.
I found an older study from a site in Australia: Accessible Data Tables
Prepared by Roger Hudson For the Web Essential Info Night in Sydney - 30 June 2005. It was a very, very small sample (n=5). But those users tended towards the "header" attribute over the "scope." (Their conclusions based on those few users are here.)

The larger question is -- why force a choice? (Beware false dichotomies!) Why not let the web designer decide about using the "header," attribute, the "scope" attribute, or both.

screen reader behaviour with table headings

I've always just considered the use of "scope" for simple data tables and "id/headers" for complex data tables to be good practice. That said, you are right in that support for these among screen readers varies, and in many cases they don't seem to be required, as long as proper table header (th) elements are used. At the same time, I don't believe there is any specific drawback to using these attributes in the proper context.

Testing the main data table in the "Content" admin overlay, JAWS 11 announces the relevant column header before it reads each cell when moving cell by cell through a row. It works quite well.

Window-Eyes 7.2, by default, does not read the cell's associated header, but can easily be set to do so using Ctrl-Shift-H and selecting the desired setting.

VoiceOver3 in Snow Leopard also reads the column header for each cell, though it appears to read the header's title attribute, when present, instead of the simple header text. I don't know how to change this setting, or if it is possible. At any rate, this behaviour seems problematic to me since the title attribute on the "Type" column header, for example, is "sort by Type", which means that each cell in this column is prefaced with "sort by Type" instead of just "Type". The same thing goes for each of the headers that are also links for sorting the table.

NVDA 2010.1, at the moment, does not support reading table headers, but should in version 2010.2 (http://www.nvda-project.org/ticket/361).

"select all rows in this table" header checkbox

Another issue with the headers in the main table on the "Content" administration page is that the checkbox in the top left header has a title attribute of "Select all rows in this table" and this gets read as the associated header for every checkbox in that column, no matter the row. For example, in JAWS 11 or Window-Eyes or VoiceOver, you hear something like "Select all rows in this table, checkbox, not checked", which implies a different functionality for the checkbox than that which it truly has, which is to select just the specific row.

A related issue is that the checkbox for each row has no explicit label associated with it. The relevant "Title" cell's content could be wrapped in an associated label element, which might help. Or a title attribute containing the relevant "Title" could be added to the checkbox input.

In reference to this last item I added issue #851174: Update options checkbox doesn't include labels & #851164: Tableselect: "select all rows in this table" header checkbox causing accessibility problems