Re: DRAFT Re: headers attribute debate

I use headers in Fire Vox both to provide context information and to 
determine whether the current table is a data table or a layout table.

-Charles
http://firevox.clcworld.net

>
> <note
> class="inDraft">
>
> This is a quick draft of a possible statement on the accessibility
> value of the 'headers' attribute as found in HTML4.
>
> PFWG participants and colleagues from across the WAI are asked
> to consider what our response should be to this request for
> information.
>
> Al
>
> </note>
>
> <answer
> class="draft forDiscussion">
>
> Reference:
> http://www.w3.org/mid/1c8dbcaa0705271606o7ba8f4e7ybbbdfd9bc6f0559a@mail.gmail.com 
>
>
> ** summary
>
> The function provided by the 'headers' attribute is to associate
> table cells with information required for the understanding of the
> cell contents; information that is provided 'centrally' in header
> cells because it applies to more than one cell. Tables are different
> from the bulk of web content where there is one path to ancestors and
> such common information. In tables, there are common characteristics
> both by row and by column.
>
> 1. The function is needed.
>
> Metadata for Content Adaptation Workshop:
>
> <quote
> cite="http://www.w3.org/2004/06/DI-MCA-WS/execreport.html">
>
> The relationship between (fragments of) content should be captured in 
> metadata.
> [...]
> Where possible, metadata should be derived from the existing markup,...
>
> </quote>
>
> WAI-ARIA States and Properties:
>
> We would consider most related headers to fall within the meaning of
> the aaa:labelledby attribute (occasionally aaa:describedby). The
> existing 'headers' attribute provides this function in the context of
> HTML tables.
>
> http://www.w3.org/TR/aria-state/#labelledby
>
> 2. The markup works.
>
> An independent review by the U.S. Department of Justice for the Federal
> Statistics workshop on accessible tables found that 'headers' was 
> effective
> in getting needed header information to consumers, as compared with
> 'scope' which was not well supported.
>
> http://workshops.fedstats.gov/Nakata_Fedstats.ppt
>
> 3. The path forward.
>
> Starting from scratch, the broader @labelledby and @describedby
> relationships are still needed. And leaf-by-leaf markup with this
> bottom-up facility, while still needed to cover corner cases, could
> be used less frequency if structural reforms were introduced such as
> nestable row-groups in place of the present awkward 'tbody' at one
> level only. @headers doesn't meet the full requirements across the
> board (in and out of tables). @labelledby and @describedby could
> convey all the information currently handled by @headers.
>
> But we are not starting from scratch. There is an immense user base
> of many sources as well as many sinks for HTML. So a measured
> migration at the fastest would be appropriate.
>
> In any case, the function is needed, and this current markup is
> delivering the needed function. If we are to work this attribute out
> of the system, it must be because it is being replaced with something
> better, and via an orderly transition.
>
> ** details.
>
> 4. AT have small markets; they can only afford easy algorithms.
>
> The reason that 'headers' got picked up rapidly and 'scope' didn't
> was in part the following peformance comparison:
>
> The screen reader had a table cell in its sights, and had received
> a 'hunh?' query from its user.  It needed to contextualize this table
> cell.  To answer this query by 'scope' the AT would have to search
> the table for TH cells (often misused for styling) and then check
> the 'scope' on each.  If the author used 'headers' there was an
> attribute on the object at hand pointing to a short list of what
> more to say.  Need I say more?
>
> 5. Yes, more could be done with algorithmics.  At the FedStats
> workshop I was surprised to realize that what they characterized
> as 'complex tables' were not, in my over-math-educated mind,
> complex.  They were fully regular relations, with tree-form indices
> associated with the rows and/or columns.  There was a hierarchical
> structure to the categories represented by rows or columns and
> groups of rows or columns.  There was no irrregularity in the structure.
>
> On the other hand, the 'irregular tables' that we forced 'headers'
> into the markup do exist in the wild.  These tables have "variant
> record structure" where some of the fields are re-cast to new
> headers on the fly within the table.  Also cases where two triangular
> arrays are packed into one rectangular display, and there is a critical
> diagonal -- on one side one refers to the left hand header, on the
> other side to the right; and similarly for top/bottom headers.  There
> were also train timetables that were weirder than this.  They overlaid
> two mathematical relations (Eastbound and Wesbound timetables, for
> example) re-using some fields.  These can be modeled by casting
> cells in the roles of data and headers, but not with the coarse 
> granularity
> afforded by 'scope.'
>
> Rationale at the time of HTML4:
> http://www.w3.org/WAI/PF/guide.html#TABLE
>
> Philosophy behind 'headers' as 'lowest level language' that covers the
> corner cases:
> http://www.w3.org/2002/Talks/06/24-US_FedStatsWorkshop/slide1-0.html
>
> Train timetable with some interior header data that applies to the 
> left, some
> to the right:
>
> http://lists.w3.org/Archives/Public/www-archive/2007May/att-0083/czsched.htm 
>
>
> 4.  There's room for further normalization in the space of required 
> information
> See in particular the strong appeal for anywhere-in-the-page LINK and 
> META
> capability.
>
> http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/0063.html
>
> 5. (recap)
>
> The genuine requirement is broader; a re-engineered solution could
> deliver 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.
>
> </answer>
>
> At 6:06 PM -0500 27 05 2007, Laura Carlson wrote:
>
>> Patrick H. Lauke wrote:
>>
>>> With regards to the recent debate over the (removal, or
>>> non-inclusion,  or "not-yet-included-until-proven-useful") headers
>>> attribute: in areas  where potential impact on accessibility has been
>>> identified by a group  member, further advice should probably be
>>> sought from WAI and the PFWG,  as per charter (see email below from
>>> Judy Brewer).
>>
>>
>> The HTML 5 working group is indeed questioning the usefulness of
>> marking up id/headers in complex tables. In fact the headers attribute
>> is not currently in the HTML 5 specification.
>>
>> Advice from WAI and the PFWG on the potential accessibility impact of
>> the absence of the headers attribute for HTML 5 would be appreciated.
>>
>> The following are related HTML 5 public-html and www-html
>> posts/threads by HTML 5 working group members:
>>
>> http://lists.w3.org/Archives/Public/public-html/2007May/0012.html
>> http://lists.w3.org/Archives/Public/www-html/2007May/0426.html
>> http://lists.w3.org/Archives/Public/public-html/2007May/1032.html
>> http://lists.w3.org/Archives/Public/public-html/2007May/1036.html
>> http://lists.w3.org/Archives/Public/public-html/2007May/1069.html
>>
>> Related Working Group member blog posts:
>>
>> Bruce Lawson:
>> http://www.brucelawson.co.uk/index.php/2007/html5-microformats-accessibility-testing/ 
>>
>>
>> Roger Johansson:
>> http://www.456bereastreet.com/archive/200705/help_keep_accessibility_and_semantics_in_html/ 
>>
>>
>> Thank you,
>> Laura
>>
>>> -------- Original Message --------
>>> Subject: Re: WAI mandate to work with other WGs?
>>> Date: Thu, 24 May 2007 00:49:53 -0400
>>> From: Judy Brewer <jbrewer@w3.org>
>>> To: Patrick H. Lauke <redux@splintered.co.uk>
>>> CC: WAI Interest Group <w3c-wai-ig@w3.org>,    Al Gilman
>>> <alfred.s.gilman@ieee.org>, Michael Cooper <cooper@w3.org>
>>>
>>> Patrick,
>>>
>>> Here is additional information on your question about what role WAI
>>> has in working with other W3C Working Groups to ensure the
>>> accessibility of W3C specifications currently under development.
>>>
>>> WAI's Protocols and Formats Working Group (PFWG) has, as part of its
>>> mission, reviewing specifications under development in other W3C
>>> Working Groups in to ensure consideration of accessibility-related
>>> needs. PFWG's home page is at
>>>          http://www.w3.org/WAI/PF/
>>> Its charter, describing its scope of work is available
>>>          http://www.w3.org/WAI/PF/charter200612
>>> and there is a page describing participation
>>>          http://www.w3.org/WAI/PF/participation.html
>>>
>>> For the purpose you describe, participation on the wai-xtech list
>>> (see the PFWG participation page above) would be a good place to
>>> discuss accessibility issues that you are tracking in the HTML
>>> Working Group. Because of the volume of work that PFWG needs to
>>> monitor, it is helpful to have people on wai-xtech monitoring the
>>> HTML WG traffic, and catching issues that need discussion.
>>>
>>> In addition, the HTML WG has requirements in their charter to work
>>> with WAI, and
>>> PFWG in particular:
>>>          http://www.w3.org/2007/03/HTML-WG-charter.html#coordination
>>>
>>> I've copying Al Gilman, Chair of PFWG; and Michael Cooper, Staff
>>> Contact for PFWG; so that you can also be in touch with them as
>>> needed.
>>>
>>> Regards,
>>>
>>> - Judy
>>>
>>>
>>> -- 
>>> Patrick H. Lauke
>>
>> ___________________________________________
>> Laura L. Carlson
>> Information Technology Systems and Services
>> University of Minnesota Duluth
>> Duluth, MN U.S.A. 55812-3009
>> http://www.d.umn.edu/goto/webdesign/
>
>
>

Received on Wednesday, 30 May 2007 16:56:13 UTC