headers attribute Issue

Issue

Vision impaired screen reader users listen to outputted information, without any visual cues, and HTML 5 currently lacks a mechanism to create accessible complex data tables that sufficiently meet their needs. Screen reader users currently rely on the headers/id mechanism to be able to interrogate complex table data, partly due to poor user agent support for the scope attribute. A machine-recognizable association between cells in a table and their in-the-table critical context is therefore needed. Currently it is impossible to define most complex data tables accessibly in HTML 5.

The purpose of the attribute is to specify the headers for a particular table cell so that they can be queried by a user or announced to provide context when the user navigates along a particular axis. WCAG 2 explains the headers/id technique this way:

"This technique is used when data cells are associated with more than one row and/or one column header. This allows screen readers to speak the headers associated with each data cell when the relationships are too complex to be identified using the th element alone or the th element with the scope attribute."

Status

Closed

The headers algorithm in HTML5 adopted all proposed improvements with respect the headers="" attribute. Testing issues can are being tracked in Bugzilla Bug 7260: Create testsuite for table headers association.

Advice Request to PFWG and their Response

• Request to PFWG: headers attribute debate - Laura Carlson, May 27, 2007.
  • WAI and the PFWG Response (Summary Al Gilman, June 6, 2007): "The genuine requirement that html4:td.headers addresses is broader than just for table cells; a re-engineered solution could deliver both superior usability and authorability. But we are not starting from scratch. There is a disability constituency that currently uses and depends on this feature: anyone offering to remove it should be expected to demonstrate that the replacement works better and is in service. So from an accessibility perspective, dropping 'headers' because 'scope' could afford the same semantics in 'most of the cases' is a wrong decision; now or, taken in isolation, for the future. But 'scope vs. headers' is not the right frame of reference for the future. As the requirement isn't limited to tables, we look forward to a better solution, gracefully migrated to, once the requirements get looked at in the right breadth of view. And if we can together set up the sampling capability, we'd be glad to work on alternative strategies in terms of how one would recode current 'live' examples."
  • PFWG report on @headers status - Joshue O Connor, November 24, 2008.
  • details on report of PFWG HTML5 actions & issues status - Gregory J. Rosmaita, February 12, 2009.

Proposed Solutions

1. Allow headers to reference a td

Reinstate headers/id AND their functionality into the spec by specifically stating that headers are allowed to reference a td. Reword the current definition of the headers attribute so that each of the space separated tokens must have the value of the ID value of a th or td element. For full request visit ACTION 72: @headers rewrite deliverable.

• The constraint that the headers attribute can only reference the id attribute value of a header cell is of very little use, and makes it impossible to define most complex data tables accessibly.
• A mechanism to associate data cells with conceptual/nested/chained header cells and pure headings is required to determine content relationships. As conceptual/nested/chained headers are not allowed in HTML5, this means that conceptual/nested/chained headers (cells that contain data and have their own header, but act as a header for other cells in the table) must be marked up as a td.
• Current thinking is that only pure headers should be marked up with a th.
• Headers attribute referencing a td works today in AT. See:
  • headers/id Testing - Gez Lemon
  • Other research
  • User Agent Working Group comments
• Headers attribute referencing a td will be needed tomorrow for backwards compatibility.
• A concern was raised that cyclic header references may result in an infinite loop. Implementations do not accumulate headers for headers, so although cyclic references should not be considered conforming, cyclic header references do not cause issues with implementations.
• More rationale:
  • Why Headers Should be Included
  • Why Headers Should Not be Included

2. Hierarchical headers with Smart Algorithm

Write hierarchical/conceptual/nested/chained headers into the spec and use a smart headers algorithm. Reference: Table inspector.

• The headers attribute can reference a th, so if tds are changed to this, the relationship would be complete.
• Simplifies authoring.
• It isn't clear at the moment whether the algorithm can successfully determine the orientation for compound data, but that could be overcome with the introduction of a scope attribute to remove ambiguities if it is a problem.
• Not demonstrated that the replacement works better and is in service.
• Doesn't work with irregular tables, as irregular data tables have headers in a different row or column from the data cell in question, so that would have to be marked up explicitly.
• Doesn't work with current AT, as we know it. The smart headers algorithm is an extension of the current algorithm for scope, and AT have very poor support for scope.
• Not backward compatible.

3. New Element to Act as a Label Instead of a Pure Header (A Magic Cell)

Introduce a new element that acts as both a header and data cell (as the editor proposed in bug 5822) - for example, <tl>. The scope attribute would work with both <th> and <tl>. The smart headers algorithm could be applied to this new element. If determining the orientation of scope is problematic with the new element, then the scope attribute could either be a required attribute, or have an implicit orientation (such as row), which can be overriden by the scope attribute. It would also reduce the complexity of the smart headers algorithm if it continued to assume that headers were either at the start of a column or start of a row.

• Negates the need for nested headers.
• Removes any ambiguity, if used with the scope attribute.
• Doesn't work with current AT.
• Not backward compatible.

4. aria-labelledby

Write aria-labelledby into the spec.

• This would provide the needed machine-recognizable association to make complex tables accessible (example of aria-labelledby).
• The associations are not announced at all in the example with Firefox 3 and JAWS 8.
• IE currently doesn't support ARIA.
• Part of the intention of ARIA is to be replaced by host-language functionality once the @aria-* attributes are no longer necessary. @headers may end up being the native host language equivalent for @aria-labelledby in some cases, but it would be better to have a more general global equivalent attribute that allows a list of IDREFs to label an arbitrary element.

Issue, Actions, Bug History

• May 1, 2007: Issue raised on list - Roger Johansson.
• May 27, 2007: Request to PFWG to advise on headers attribute debate - Laura Carlson.
  • June 6, 2007: PFWG Review and Advice - Al Gilman.
• June 7, 2007: This Wiki page created to document issue - Laura Carlson.
• November 2007: The accessibility "when possible" escape clause removed from the Design Principles.
• November 21, 2007: ISSUE-20 - Raised by James Graham (improve alogrithm).
• March 23, 2008: Editor's message saying headers/id is in the spec.
• April 28, 2008: ACTION-63 created to ensure HTML WG response to 6 Jun 2007 PF WG msg - Dan Connolly
  • June 16, 2008: ACTION-67 created to propose a test case regarding table headers/id - Dan Connolly. Note: The WCAG 2 technique (H43) used for this action has nested headers, which doesn't conform to HTML 4.01 or HTML 5 (although the W3C's HTML validator doesn't pick it up).
    • June 26, 2008: @headers on th too or just td? (Test Results) - Dan Connolly email.
• June 20, 2008: Bug 5822 - Reported by Gez Lemon. (Closed February 11, 2009. No longer relevant now chained headers are allowed.)
• July 17, 2008: ISSUE-57 @headers raised by Joshue O Connor.
  • July 17 2008: Teleconference discussion regarding ISSUE-57 not being a dup of ISSUE-20. Also 7 July 2008 Teleconference minutes.
• July 18, 2008: ACTION-72 created to reword the current definition of the headers attribute so that each of the space separated tokens must have the value of the ID value of a th or td element - Joshue O Connor.
  • August 21 2008: ACTION 72: @headers rewrite deliverable Laura Carlson, Gez Lemon, Joshue O Connor.
    • August 21 2008: headers/id Testing (Bug 5822) - Gez Lemon.
• August 28, 2008: Chris Wilson - Update on action 72. Chris "took action item assigned to josh and will figure out how to ensure edit gets made in timely fashhion".
  • August 29, 2008: Editor's comment <Hixie> "fwiw my plan with this tables stuff is to do exactly what i was going to do anyway, which is to get to it when i get to it, and when i get to it, read all the arguments and research, and come to a conclusion based on that"
• September 11, 2008: Chris Wilson - Next steps for action 72 "still need to shift through all info; either declare consensus or post a poll; collect issues into 1 email to send to list -- hope to get to it very soon...yes, I need to collate and distill, then ask a question to the group. Still assigned to me."
  • September 25, 2008: Chris Wilson - update on action 72 - "I will follow this up. Get the issues into the wiki and continue discussion until there is a consensus. If opinion is very entrenched then we will have a poll."
• October 23, 2008: Ian Hickson - Bug 6181: "Process table feedback (including headers='" issue)" "Severity: blocker".
  • December 24, 2008: Ian Hickson - Bug 6181: "Process table feedback (including headers='" issue)" "Status: RESOLVED Resolution: FIXED."
• November 13, 2008: Joshue O Connor - Action 84: "Prepare status report on @headers discussion by next week".
  • Action 84 Deliverable: PFWG report on @headers status - Joshue O Connor (Monday, 24 November)
• November 14, 2008: Ben Millard - Action 85: "compare Smart Headers with HTML5 algorithm".
• November 20, 2008: Michael(tm) Smith - Action 87: "Ensure Ian Hickson follows up on semantics-tables messages".
• January 15, 2009 teleconference discussion on ISSUE-20.
• January 15, 2009 Bug 6438 Error in step 9.4 of the internal algorithm for scanning and assigning header cells.
• January 21, 2009 Bug 6462 Self-reference and cyclic references in headers="".
  • Spec updated. But may need discussion. How B and C contribute to A seems complicated. But the statement "A th element must not be targeted by itself." is a good edit.
• February 12, 2009 Bug 5822 Closed No longer relevant now chained headers are allowed.)
• August 11, 2009 Bug 7260 Create testsuite for table headers association

Rationale: Why Headers Should be Included

1. The headers/id technique may seem irrelevant to those with good eyesight because they have access to content relationships at a glance. However, for users with visual impairments, it is vital for comprehension. 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 complex and irregular data tables.
2. The headers/id technique provides needed functionality in more cases than scope/group. Screen readers do not support scope very well. (See the Research section and the User Agent Working Group comments in the Use Case section below.)
3. No set number of use cases proves a feature should be included or excluded from the spec. The W3C requires that technologies must be accessible. By definition, people with disabilities are a minority. Accessibility features address failure modes that are infrequent, but critical when they occur.
4. Despite being rare, it's still important to provide mark up so that data cells can unambiguously be associated with their header cells. It's inevitable that there will be complex relationships that must be able to be modeled with markup alone.
5. In order to apply the new scope/group technique, tables must be restructured. You can't just add markup to an existing table as you can with headers/id. As for rearranging the data table to simplify the problem - this is can not be done with USER generated table created on the fly. The USER wants to view the table like he wants to view it, as it allows them to quickly get an overview in order to make timely decisions.
6. The headers/id technique may sometimes be used incorrectly but that is true of all markup. Failure by some to implement a standard is not in itself sufficient justification for getting rid of that standard.
7. On a pure language-complexity basis, 'scope' is more heavyweight than headers. It adds several new terms, an attribute name and multiple values. 'headers' adds just one term and otherwise re-uses core features (ID).
8. The headers/id technique provides functionality today. It also works in legacy AT. If it is to be worked out of the system, it should not be an abrupt drop. Transition it out with something better in an orderly and graceful manner.
9. Anyone suggesting not including headers/id should demonstrate that the replacement works better and is in service.
10. Applicable Design Principles
    • Accessibility
    • Support Existing Content
    • Degrade Gracefully
    • Do not Reinvent the Wheel
    • Evolution Not Revolution
    • Solve Real Problems

Rationale: Why Headers Should Not be Included

1. The scope/group technique handles the majority of use cases.
   • Is there concrete evidence for this? scope/group serves a distinct purpose from headers/id, which are far more widely supported by assistive technologies; the use of one, the other, or both is often necessary, depending upon the complexity of the TABLE.
2. An insufficient amount of use cases exist to justify headers/id.
   • Where are the statistics to back up this claim? headers/id bindings in TABLEs do exist in the wild, and the scarcity of the use of binding mechanism is not due to a defect in the headers/id or scope and axis models, but merely a lack of implementation by "mainstream" developers and document authors.
3. Complex tables are very rare on the Web. If something is rare, then it shouldn't be supported.
   • Again, where is the concrete evidence for this claim? Following the argument "If something is rare, then it shouldn't be supported" to its logical conclusion is an extremely troubling and dubious design "principle" -- this markup serves precisely to provide access for a specified user group -- the blind, the legally blind, those with low vision, and those with cognative difficulties whose comprehension is aided by supplemental speech. No, this user group is not statistically overwhelming, but is this (and other) user groups to be punished for a lack of sheer numbers? Persons with disabilities exist, and the W3C has made a commitment to them to ensure that existing barriers are eradicated and that new barriers are not constructed. Even if the number of persons who depend upon the binding of data cells to their headings is not statistically large, markup was added to HTML 4.01 expressly to increase accessibility, and hence the number of disabled individuals who can use the web for educational, informational, and fiduciary reasons will also increase. What constitutes the numeric threshold for "something" which is "rare" to be supported, and who is to decide where that threshold is located? The end product of such logic is that persons with disabilities don't matter, because, in the overall scheme of things, their presence on the web is "rare". In order for an attribute expressly designed for a specific purpose to be deprecated, a superior mechanism than that defined for TABLE accessibility in HTML 4.01 must be retained. The onus isn't on those who depend upon such explicit bindings to "prove" to the HTML WG that they are necessary -- the onus lies squarely on the shoulders of the developers of authoring tools, user agents, and document authors to prove that a superior mechanism, providing an equivalent or enhanced functionality, exists, thereby justifying the consideration of deprecating markup expressly designed to assist persons with disabilities.
4. The headers/id technique is complex for authoring. Scope/group is easier and less error-prone.
5. The headers/id technique is sometimes used incorrectly.
   • Author errors/ignorance is not a reason to deprecate an attribute or element.
6. Adding headers to the specification will cause code bloat.
   • headers were already in HTML 4.01, even if unevenly supported; the claim that it will cause code bloat is a non-sequitor; there are plenty of other newly introduced elements and attributes in the HTML5 draft that actually do cause code bloat. The headers/id binding is not merely just another piece of code, but a mechanism providing essential information to anyone who cannot -- for whatever reason -- perceive the TABLE, which is a purely visual and presentational construct when stripped of the accessibility elements and attributes defined for TABLE.
7. By the time HTML5 becomes widely used, one would hope assistive technology would support scope/headers. HTML5 actually goes some way towards helping with this, by providing exact algorithms for associating table header cells with data cells, resulting in exactly the same data structures as headers="" provides.
8. People suggesting including headers/id haven't demonstrated that it is needed. More research is required.
   • Again, where is the evidence for this claim? Simply attempt to read the table-ized results of WBS straw polls and surveys -- a TABLE is the worst means of expressing the information contained therein, due to its inordinate length and the space limitations of individual table cells. If more research is required, then it should be research that proves the contention that headers/id are not needed.
9. Applicable Design Principles
   • Avoid Needless Complexity

Advice from Accessibility Authorities

• User Agent Working Group comments "The 'headers' attribute is supported by the major screen readers used in the world (JAWS, WindowEyes, HAL/SuperNova-still waiting for a reply). WindowEyes uses the headers and id attribute combination. WindowEyes does *not* use the scope attribute. JAWS has support for headers/id, row and column span, and the 'axis' attribute. Assistive technologies, browser extensions, and tools that use DOM access also support the headers attribute and expose that information through their accessibility APIs and to their end users with disabilities and to developers. Examples of this include Firefox extensions like FireVox and the University of Illinois Firefox accessibility extension, and developer tools like Parasoft's WebKing and IBM's RAVEN tool. In addition, platform accessibility APIs such as IAccessible2 on Windows, ATK/AT-SPI on Linux, and the Java accessibility API all have functions for getting the row and column headers. The headers attribute, scope attrte, and TH all provided explicit, engineered ways for browsers to get row and column headers and expose that information to assistive technologies through the accessibility APIs. Without these, the browsers and assistive technologies are forced to resort to heuristics such as font styling and location (topmost and leftmost cells), which is insufficient for complex tables with spanned and multiple row/column headers." - Jim Allan.
• Headers attribute - "It may be true that it is possible to restructure many complex data tables by adding rowgroup or colgroup elements to the table and by altering the spans of cells in such a way that the scope attribute can specify the header cells for all data cells. I am not convinced but it is true for some of the "classic" examples. That process is complicated and cumbersome. It basically requires rewriting the table. Compare that with the headers/id approach. ANY Table with ANY relationship between heading cells and data cells can be defined directly by adding id attributes and headers attributes to the cells - not touching the structure of the table. ANY table ANY relationship. That is part of the reason why you see many examples of simple tables marked up with headers/id when they are not necessary and simple scope would work. The simple and algorithmic aspects of headers/id is why the screen reader vendors all now support it and none support rowgroup and colgroup. The algorithm the AT vendors would have to implement for the scope/group approach is much more complex to the point that I think it unlikely they would ever support it AND it would not catch everything." - Jim Thatcher

Research

• headers/id Testing (Bug 5822) - Gez Lemon
• Support for scope and headers attributes in assistive technologies - HTML Working Group.
• User Testing footage of header/id combinations, @summary and @longdesc for HTML5 WG - Joshue O Connor
• Data table accessibility test - Roger Hudson and Russ Weakley. "At this stage, it appears that id and headers are the most effective way to make complex data tables accessible. Although id and headers are slightly more difficult to code than scope, the apparent poor screen reader support for scope means that this is probably not an effective accessibility option."
• Techniques for Accessible HTML Tables - Stephen Ferg.
  • Headers Example Recommendation - Stephen Ferg.
• Collections of Interesting Web Pages - Ben 'Cerbera' Millard
• Feedback on accessibility concerns in HTML5 - Catherine Roy

Examples

• Sample Data Table - Gez Lemon
• Sample Data Table Alternate - Gez Lemon
• Joe does the Movies
• Estimating Heat Pump Swimming Pool Heater Costs and Savings
• Old versus New Insulation Standards
• Summary of Eye Disease Prevalence Data
• Table 7. Coal Production by State, Mine Type, and Union Status
• Table 13. Productive Capacity and Capacity Utilization of Underground Coal Mines by State and Mining Method, 2008 (Thousand Short Tons)
• Table A-2. Employment status of the civilian population by race, sex, and age
• Occupational Injuries and Illnesses and Fatal Injuries Profiles (need to fill out form info to retrieve particular data tables)
• Tide Tables - Broads Authority
• University of Wisconsin - Madison Facts: Budget
• Black & White Copies greyscale
• WebAIM: Media Player Accessibility
• An Overlaid Table Example
• Techniques for Accessible HTML Tables
• California Zephyr
• Basel I Risk-Weights for Externally Rated Long-term Positions
• TABLE Using headers/id and axis (based on CSS2, Section 17 example)
• TABLE Using scope, axis, and speak-headers (based on CSS2, Section 17 example)
• Online Workshops
• More examples and discussion on the Accessify forum.
• Data Table Accessibility Test Update - Roger Hudson and Russ Weakley
• 2003-2007 Security Services Unit Agreement Appendix A - Salary Schedules - New York State Governor's office.
• NYSCOPBA Salary Schedules - New York State Governor's office.
• Actual Department of Justice FY 2005 Vehicle Acquisitions (example of a table with at least one headers/id cycle)
• Going Beyond Compliance: Survey report
• Analysis
• height attributes
• Untangling Bad Tables
• Age of Consent

Use Cases

• Oracle's web-based solutions "all use the headers= attribute and have since roughly 2001/2002. In fact that has been one of our requirements for making our software section 508 compliant."
• TPG uses dynamically generated output tables from web application for corporate clients. - Steve Faulkner
• XStandard "arguably the most standards compliant WYSIWYG editor, automatically inserts the headers attribute to associate headers with data cells. Personally, I would rather it didn't, as it unnecessarily bloats the markup for simple data tables, but they've made the decision based on the fact that assistive technology traditionally has very poor support for the scope attribute, and very good support for the headers attribute. I'm also aware of a few companies that have style guides that insists that data cells are associated with their headers using the headers attribute for the same reason. - Gez Lemon
• Yahoo table widget implements headers
• Fidelity Investments depends heavily on complex tables for displaying product and customer account information. Portions of the web site have been using complex table markup for years to improve accessibility. Unfortunately, most of the examples I am familiar with are behind the customer password. For those with personal Fidelity accounts, look in the Accounts and Trade section...headers/id are used in dynamic tables for grouping rows and/or columns (e.g. Large Cap Funds, International Funds, etc). Id headers are used on dynamic tables with irregular shapes, where the table provides a "total" row in a larger, more prominent font that will not fit in the regular cell. Cells are then merged in that row, breaking the standard connection to the TH for that column..." - Jeanne Spellman. (Jeanne is in the process of getting permission for us to see samples.)

HTML 4 Reference

A comment in the HTML 4 specification DTD fragment for td and th was clear that if a cell was both a header and contained data, then authors should use td:

This is also clarified in the section on associating header information with data cells:

"Note that it's not always possible to make a clean division of cells into headers or data. You should use the TD element for such cells together with the id or scope attributes as appropriate."

Policies, Guidelines, and Law

• Official United States Postal Service policy (AS-508-A Section 508 Technical Guidelines) are used in statements of work, vendor requirements, both internally and externally. - Norman B. Robinson.
• National Science Foundation Policy and Standards manual
• National Oceanic and Atmospheric Administration: National Weather Service, Section 508 policy
• University of Wisconsin Accessibility policy
• California State University Policy
• WCAG 2.0
• WCAG 1
• Section 508
• Dutch Accessibility Law see section R-pd.11.5 (English Translation via Babel)

Related Blog Posts and References

• Help keep accessibility and semantics in HTML - Roger Johansson
• HTML 5, microformats and testing accessibility - Bruce Lawson
• The HTML Scope/Headers Debate - Gez Lemon
• headers Issue 'Resolved' by Ben Millard
• Untangling Bad Tables by Ben Millard
  • Mozilla Bug 441445 - Andrew Downie, June 23, 2008.

Related IRC Discussion and Teleconference Minutes

• 28 Aug 2008 Teleconference Minutes. Chris Wilson "took action item assigned to josh and will figure out how to ensure edit gets made in timely fashhion"
• <Hixie> "fwiw my plan with this tables stuff is to do exactly what i was going to do anyway, which is to get to it when i get to it, and when i get to it, read all the arguments and research, and come to a conclusion based on that
• 17 July 2008 Teleconfernce (Rough IRC minutes only) regarding ISSUE-57 not being a dup of issue 20. Also 7 July 2008 Teleconfernce minutes.
• "html5 doesn't have the concept of chained headers...a cell is either a data cell with headers, or a header cell" - Ian Hickson, June 20, 2008.
• I will add @headers issue to tracker shortly (Buzilla 5822) - Josh O Connor, July 10, 2008.
• currently implemented in such a way that complex tables cannot be created using the headers attribute. - Laura Carlson, July 10, 2008.
• Issue 20 addresses only one half of the headers problem - Josh O Connor and Laura Carlson, July 17, 2008.
• Next steps on action 72 "action on CW about headers and header functionality; still need to shift through all info; either declare consensus or post a poll; collect issues into 1 email to send to list -- hope to get to it very soon...yes, I need to collate and distill, then ask a question to the group. Still assigned to me." - Chris Wilson, September 11, 2008.
• Update - "I will follow this up. Get the issues into the wiki and continue discussion until there is a consensus. If opinion is very entrenched then we will have a poll." - Chris Wilson, September 25, 2008.
• Update - "I will follow this up. Get the issues into the wiki and continue discussion until there is a consensus. If opinion is very entrenched then we will have a poll." - Chris Wilson, September 25, 2008.
• The Wiki was updated - Laura Carlson, September 26, 2008.
  • Update announced at teleconference - Laura Carlson, October 2, 2008.
  • Call for Wiki page review - Al Gilman, October 4, 2008.
• Discussed at the Face-2-Face meeting October 23, 2008 - HTMLWG/PFWG Joint meeting
  • Mike Smith's Summary of Face-2-Face meeting
• Joshue to prepare status report - Joshue O Connor, November 13, 2008.

Related E-mail Threads

May 2007

• Rationale for removing the summary and headers attributes from tables? - Roger Johansson (Tuesday, 1 May)
• Re: (was Support Existing Content) - Henri Sivonen (Wednesday, 2 May)
• Use of headers and summary attributes (was : (was Support Existing Content) - WebConforme (Friday, 4 May)
• Accessibility is for everyone (was : Use of headers and summary attributes) - Philip Taylor (Friday, 4 May)
• Testing Accessibility Re: Accessibility is for everyone - Charles McCathieNevile (Monday, 7 May)
• Re: Complex Table Examples - Laura Carlson (Thursday, 17 May)
• headers attribute debate - Patrick H. Lauke (Saturday, 26 May)
• Fwd: RE: headers attribute debate - Patrick H. Lauke (Thursday, 31 May)