- From: Jon Gunderson <jongund@uiuc.edu>
- Date: Wed, 30 May 2007 12:06:17 -0500 (CDT)
- To: wai-xtech@w3.org
The Firefox accessibility extension and screen reader like JAWS use header information to provide header information for data cells in tabular data tables. The HEADERS attribute is the only way to show complex relationships between header cells and data cells in tabular data and removing it form the spec would make it impossible to describe these important relationships in markup. Jon ---- Original message ---- >Date: Wed, 30 May 2007 11:44:46 -0500 >From: "Charles L. Chen" <clc@clcworld.net> >Subject: Re: DRAFT Re: headers attribute debate >To: wai-xtech@w3.org > > >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/ >> >> >> > > > Jon Gunderson, Ph.D. Director of IT Accessibility Services (CITES) and Coordinator of Assistive Communication and Information Technology (DRES) WWW: http://www.cita.uiuc.edu/ WWW: https://netfiles.uiuc.edu/jongund/www/
Received on Wednesday, 30 May 2007 17:06:22 UTC