This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5822 - The headers attribute should be able to reference a td
Summary: The headers attribute should be able to reference a td
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 major
Target Milestone: ---
Assignee: Michael[tm] Smith
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11y_table_headers
: 5823 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-06-30 20:17 UTC by Gez Lemon
Modified: 2010-10-04 13:55 UTC (History)
10 users (show)

See Also:


Attachments

Description Gez Lemon 2008-06-30 20:17:56 UTC
The headers section of the specification states that each token in
the headers attribute should have the value of an id of a th element
[1]:

"The headers attribute, if specified, must contain a string consisting
of an unordered set of unique space-separated tokens, each of which
must have the value of an ID of a th element ..."

Cells that are both headers and contain data should be marked up as td, so the values should match the value of an ID of a th or a td element.

[1] http://www.w3.org/html/wg/html5/#headers

Thanks,

Gez
Comment 1 Ian 'Hixie' Hickson 2008-06-30 20:23:41 UTC
This was intentional, based on research into what tables on the Web actually looked like and what the expected UI of headers currently is and ideally should be.

Basically, it turns out that while one would intuitively think that hierarchical headers are a good design, they end up being more of a pain than a gain. By forcing a two-level structure, we make authors who are using headers="" think more carefully about what they want each cell to do and be in the table.
Comment 2 Rob Burns 2008-07-01 16:59:33 UTC
(In reply to comment #1)
> This was intentional, based on research into what tables on the Web actually
> looked like and what the expected UI of headers currently is and ideally should
> be.
> 
> Basically, it turns out that while one would intuitively think that
> hierarchical headers are a good design, they end up being more of a pain than a
> gain. By forcing a two-level structure, we make authors who are using
> headers="" think more carefully about what they want each cell to do and be in
> the table.
> 

Ian as usual you're confusing two different things here. Hierarchical headers allow one header cell to reference another header cell so that the data cells associated with the first header cell are then associated with both headers (and so on). This bug is meant to address the issue that the headers attribute sometimes needs to associate a data cell with another data cell (a TD element) that is then serving as both a data and a header cell. These are clearly areas way outside your comprehension and it would be good to ask for some help with these issues.
Comment 3 Joshue O Connor 2008-07-01 20:52:26 UTC
I don't this issue has been adequately dealt with and the resolution is unsatisfactory. 
Comment 4 Gez Lemon 2008-07-02 17:25:10 UTC
I've included an example of a data table from one of our clients (changing the names and using dummy values) [1]. These kind of tables are not overly complicated, and common. It's perfectly reasonable to be able to show split data data within aggregate data, to reduce the cognitive load on users expected to drill in and out of data.

With HTML 4.01, this is done using the headers attribute to point to a td (such as a cell containing the data "budgeted"). How should this be done in HTML5?

[1] http://juicystudio.com/wcag/tables/complexdatatable.html

Comment 5 Ian 'Hixie' Hickson 2008-07-02 17:46:10 UTC
Make the "Budgeted", "Actual", and "Forecasted" cells into <th>s, and remove all the headers="" and scope="" attributes. The automatic header association algorithm will automatically make the table work correctly. If you really want the first column to be repeated for every cell, you can make "Partner Portal" and "Partner Portal 2" into <th>s too, that will similarly work fine.

(Note in particular that users don't gain anything by hearing "Property" -- they only need Budgeted, Running cost, and the date. Indeed, hearing "Property" over and over again would probably be detrimental to the user experience.)
Comment 6 Gez Lemon 2008-07-02 18:04:06 UTC
(In reply to comment #5)
> Make the "Budgeted", "Actual", and "Forecasted" cells into <th>s, and remove
> all the headers="" and scope="" attributes. The automatic header association
> algorithm will automatically make the table work correctly.

So a data cell can have more than one header in scope (chained headers), and a cell containing data can be marked up as a header cell, and can also appear in the middle of a data table?

> If you really want
> the first column to be repeated for every cell, you can make "Partner Portal"
> and "Partner Portal 2" into <th>s too, that will similarly work fine.

We would want it repeating, as the context would be gone without it (if the user navigates by column, they need to know which portal the value belongs to). If it can be a th (considering it has a header), that would be fine.

> (Note in particular that users don't gain anything by hearing "Property" --
> they only need Budgeted, Running cost, and the date. Indeed, hearing "Property"
> over and over again would probably be detrimental to the user experience.)

The user wouldn't hear "Property" over and over again, other than when they query the cells "Budgeted", "Actual", and "Forecasted", which is where they would be required.

Comment 7 Ian 'Hixie' Hickson 2008-07-03 08:42:57 UTC
> So a data cell can have more than one header in scope (chained headers), and a
> cell containing data can be marked up as a header cell, and can also appear in
> the middle of a data table?

Indeed. See:

   http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular.html

...for complete details.


> The user wouldn't hear "Property" over and over again, other than when they
> query the cells "Budgeted", "Actual", and "Forecasted", which is where they
> would be required.

Ah, ok. I misunderstood the request, my bad.

Even here, though, I'm still skeptical that the user would ever need to know that "Budgeted" was a "Property" or that "Partner Portal" was a "Child Investment". Certainly one could remove those two headers ("Property" and "Child Investment") from the table in the visual rendering without any loss to the reader, and I don't see any reason why that would differ for non-visual users.
Comment 8 Ian 'Hixie' Hickson 2008-07-03 08:44:14 UTC
*** Bug 5823 has been marked as a duplicate of this bug. ***
Comment 9 Gez Lemon 2008-07-03 09:46:20 UTC
(In reply to comment #7)
> > So a data cell can have more than one header in scope (chained headers), and a
> > cell containing data can be marked up as a header cell, and can also appear in
> > the middle of a data table?
> 
> Indeed. See:
> 
>    http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular.html
> 
> ...for complete details.

That would definitely solve this particular problem, as the table isn't irregular. Allowing hierarchical headers seems to contradict your first response to this bug. It's not clear from the specification that hierarchical headers are allowed, and that header cells can contain data as well as being pure headers. The closest thing I could find was the definition of a cell:

http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular.html#cell

"Cells can either be data cells or header cells. Data cells correspond to td elements, and have zero or more associated header cells. Header cells correspond to th elements"

In light of your response here, should that be updated to say:

"Cells can either be data cells or header cells. Data cells correspond to td elements, and have zero or more associated header cells. Header cells correspond to th elements, and have zero or more associated header cells"

> > The user wouldn't hear "Property" over and over again, other than when they
> > query the cells "Budgeted", "Actual", and "Forecasted", which is where they
> > would be required.
> 
> Ah, ok. I misunderstood the request, my bad.
> 
> Even here, though, I'm still skeptical that the user would ever need to know
> that "Budgeted" was a "Property" or that "Partner Portal" was a "Child
> Investment". Certainly one could remove those two headers ("Property" and
> "Child Investment") from the table in the visual rendering without any loss to
> the reader, and I don't see any reason why that would differ for non-visual
> users.


The tables are generated automatically, and the headers change depending on what options the analyst selects. As analysts trawl through hundreds of these tables a day, they often need to remind themselves of context. They can quickly do this by querying any cell, such as reminding themselves what kind of investment a particular portfolio was part of. This does in fact cause a problem visually too. We allow users to opt into having a fixed height on the tbody and set the number of records they receive per page, or they end up having to keep scrolling back to the top of the page to remind themselves of the context.
Comment 10 Gez Lemon 2008-07-03 09:48:55 UTC
(In reply to comment #9)
> In light of your response here, should that be updated to say:
> 
> "Cells can either be data cells or header cells. Data cells correspond to td
> elements, and have zero or more associated header cells. Header cells
> correspond to th elements, and have zero or more associated header cells"

Correction - I forgot to mention that they may contain data:

"Cells can either be data cells or header cells. Data cells correspond to td
elements, and have zero or more associated header cells. Header cells
correspond to th elements, may contain table data, and have zero or more associated header cells"
Comment 11 Ian 'Hixie' Hickson 2008-07-03 16:23:42 UTC
The header cells aren't associated with other header cells, sorry if that wasn't clear in my earlier comments.

It sounds to me like the actual data cell here is the top-left one. Maybe that is the cell that should be included in every line. What would happen if a table included multiple types of investments?
Comment 12 Gez Lemon 2008-07-03 16:54:19 UTC
(In reply to comment #11)
> The header cells aren't associated with other header cells, sorry if that
> wasn't clear in my earlier comments.

I'm sorry, that's my fault - I misread what you said.

> 
> It sounds to me like the actual data cell here is the top-left one. Maybe that
> is the cell that should be included in every line. What would happen if a table
> included multiple types of investments?
> 

The problem is when a user is in a particular cell. For example, if a user is in the data cell containing the value 32,321.11, they should be able to query the cell to get the context for that cell. For example, it's the running cost (that's not a static value, so could change in similar tables) for the 19th December 2005 and is the actual value for Partner portal 2. If a user can't query these details, they have to query the whole row and the whole column, which is too cumbersome.

As these tables are generated on the fly, it's simple to provide the headers attribute to ensure context is available. If hierarchical headers were allowed (which I misread in your previous reply), that would also allow the association to work, except current screen readers wouldn't work with that. I'm not so keen on hierarchical headers, as it doesn't make sense to mark data up as a header, but I could live with it. I would prefer that the headers attribute could also reference a td element, as that very neatly solves the problem, and also allows us to markup irregular tables.
Comment 13 Gez Lemon 2008-07-04 00:30:33 UTC
I've reopened this bug, as I don't think the issue has been considered properly. The data table provided as an example is reasonably simple, and there should be a way of marking it up so that the headers can be queried by a non-visual user agent. With the current specification, only very simple tables can be made accessible. Whilst I would champion simplicity, analysts need to be able to review data at least as complicated (which is pretty simple) as the example provided [1].

If the issue is again dismissed as WONTFIX, could someone please provide a reasonable explanation as to why this request is unreasonable, and why it can't be fixed.

Bug 5823 is not a duplication of this bug, but I'm leaving it closed until I know how this issue is going to be resolved.

[1] http://juicystudio.com/wcag/tables/complexdatatable.html
Comment 14 Ian 'Hixie' Hickson 2008-07-04 05:33:37 UTC
I don't know what to tell you don't think the earlier comments are reasonable or if you don't think I've considered this properly. IMHO the table you provided can be quite adequately represented with the current markup, and while it is certainly the case that not _all_ tables can, certainly more than 80% can, and that's all we generally aim for with any feature in HTML5, in the interests of keeping things manageable and simple.

Historically headers="" has been terribly badly used by authors. This leads to worse accessibility than no headers="" attributes at all. If the goal is to improve accessibility overall, rather than increase the maximum possible level of achievable accessibility, then we _must_ consider the impact of making the feature more powerful (and complex). In any case it isn't at all clear to me that it is possible to have good hierarchical UI for table headers, and it isn't clear to me that headers-of-headers are a good design.

Furthermore, given that the current HTML5 algorithms allow one to accessibly mark up the sample data you provided without _any_ explicit accessibility attributes, it seems to be that we have made significant strides in the accessibility of tables in HTML already. Before we build on this, we should gain implementation experience and perform detailed studies of how people use the new markup, so that we know what we need to do to make things better. For example it may be that a new type of table cell which automatically acts as both a header and a data cell without any explicit accessibility attributes or without any explicit associations would be better than headers or scope.

Reassigning to Mike for arbitration.
Comment 15 Gez Lemon 2008-07-04 08:57:35 UTC
(In reply to comment #14)
> I don't know what to tell you don't think the earlier comments are reasonable
> or if you don't think I've considered this properly.

I don't think the issue has been considered properly to this point, as the reasons for closing the bug have been based on misunderstanding the purpose of the request. I'm happy for you or anyone else considering this issue to contact me directly so I can explain why I believe this feature is required, so the issue can be considered reasonably, rather than dismissed based on a misunderstanding. 

> IMHO the table you
> provided can be quite adequately represented with the current markup,

There is no way with the current specification to indicate which headers are associated with the cells in the running cost section. The headers attribute in the current specification is of little use, as it can only reference a th, and the th cannot be a hierarchical th.

For clarification, header cells are not repeatedly announced when the user navigates through a table. For example, if a user queries a row or a column, the data for all cells in the row or column is announced without header information. If a user navigates horizontally from one cell to another, only column header cells are announced, as that is the context that has changed. If a user navigates vertically through a table, only the row header cells are announced, as that is the context that has changed. It's only when a user queries the current cell that all headers for the cell around announced, to help orientate the user.

For cells that have more than one row or column header, such as the cells in the running cost section of the sample table, there has to be a way for the user to query the cell to determine what headers apply to help orientate themselves. 

> and while
> it is certainly the case that not _all_ tables can, certainly more than 80%
> can, and that's all we generally aim for with any feature in HTML5, in the
> interests of keeping things manageable and simple.

The 80% rule doesn't, or shouldn't, exclude accessibility features. It's not reasonable for accessibility features to be dropped because the feature isn't used in more than 20% of implementations. Also, these types of tables are typical to web applications that are unlikely to be published publicly.

> Historically headers="" has been terribly badly used by authors. 

Historically, the whole of HTML has been used terribly badly by authors.

> This leads to
> worse accessibility than no headers="" attributes at all. 

That certainly hasn't been our experience. Do you have data to back up that claim?

Without being able to associate header cells to data cells, screen reader users will either have great difficulty, or find it impossible, to orientate themselves in data tables. That is an accessibility problem that isn't solved by not providing the feature without an alternative mechanism.

> If the goal is to
> improve accessibility overall, rather than increase the maximum possible level
> of achievable accessibility, then we _must_ consider the impact of making the
> feature more powerful (and complex).

I would fully support any effort to come up with a better design, but there isn't a better design currently under discussion. The headers attribute works, and it works with current AT.

> In any case it isn't at all clear to me
> that it is possible to have good hierarchical UI for table headers, and it
> isn't clear to me that headers-of-headers are a good design.

It's the arrangement that some financial analysts prefer. The alternative is to drill in and out of tables, which makes it more difficult for them to get an overall picture of the data.

> Furthermore, given that the current HTML5 algorithms allow one to accessibly
> mark up the sample data you provided without _any_ explicit accessibility
> attributes, it seems to be that we have made significant strides in the
> accessibility of tables in HTML already.

Automatic scope on headers cells is a good design feature. But we do need to address tables where a column and/or row has more than one header.

> Before we build on this, we should
> gain implementation experience and perform detailed studies of how people use
> the new markup, so that we know what we need to do to make things better.

I think we're in a position to discuss the basics of how people can use the markup now, but agree there are cases where further research is required.

> For
> example it may be that a new type of table cell which automatically acts as
> both a header and a data cell without any explicit accessibility attributes or
> without any explicit associations would be better than headers or scope.

That's a good idea, and would work for example provided. There might be an issue with the "paving the cowpaths" concept, as it wouldn't work with current AT, whereas what we have now does. But I like the idea of introducing something as simple as this.

Further research would be required on irregular tables (where headers aren't in the same column or row).
Comment 16 Gez Lemon 2009-02-12 15:03:47 UTC
No longer relevant now chained headers are allowed.
Comment 17 Michael[tm] Smith 2009-09-04 14:51:07 UTC
(In reply to comment #16)
> No longer relevant now chained headers are allowed.

moving to Closed per above comment

Comment 18 Michael Cooper 2010-02-11 17:26:19 UTC
Per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html, the HTML A11Y TF does not plan to formally work on this issue at this time. This does not mean the TF has no interest in it, but does not have immediate plans to work on it. The TF may review the issue in the future.