- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 4 Jun 2007 16:27:49 +0100
- To: "Al Gilman" <Alfred.S.Gilman@ieee.org>
- Cc: wai-xtech@w3.org
I have also read that the axis attribute is also being dropped [http://wiki.whatwg.org/wiki/Differences_from_HTML4#Dropped_Attributes ] The axis attribute is supported by JAWS. Refer to the "Employee Extensions and Departments" table and the explanation above it. [http://www.freedomscientific.com/fs_products/Surfs_Up/Tables.htm ] On 02/06/07, Al Gilman <Alfred.S.Gilman@ieee.org> wrote: > > <note > class="inDraft secondDraft"> > > Thanks to all who responded on this thread with evidence about > use in the wild. > > This is a draft for a 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. Please respond before noon Eastern time on > Wednesday, 6 June so that PFWG can take your input into > consideration. > > Al > > </note> > > <answer > class="second 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. > > This function is shared with a) an association algorithm, and b) the 'scope' > attribute. > > 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 > > The point is that the eye at nominal layout can rapidly identify the > headers that pertain to a data cell, whereas the ear cannot. People > operating without vision need their assistive technology to have > access to this information in a way they can mechanically recognize. > That is a job for markup. > > 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 > > 'headers' is systematically applied by sites developed with the > relevant Oracle tools. Oracle is a major presence in databases, > this is a big slice of the relevant user base. > > http://lists.w3.org/Archives/Public/wai-xtech/2007May/0072.html > > More 'yes we use it' responses: > > http://lists.w3.org/Archives/Public/wai-xtech/2007May/0063.html > http://lists.w3.org/Archives/Public/wai-xtech/2007May/0064.html > > 3. 'headers' vs. 'scope' > > 'headers' was placed in the language because it handles all tables, > regular and irregular. 'scope' handles only regular cases. > > http://juicystudio.com/article/html-scope-headers-debate.php#overlaidtable > > 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 > > 'headers' was taken up by assistive technology because the > client-side processing is simple. 'scope' is much more indirect and > hence didn't make the first round of adoption. This has prompted a > feedback loop of those authors who care using 'headers' and hence > user success and AT coding stick with that. > > There has been some related commentary on the need to constrain > featuritis, that the language not grow with overly-narrow features. > > It is strange that this be offered as a reason for preferring 'scope' > to 'headers.' On a pure language-complexity basis, 'scope' is more > heavyweight. It adds several new terms, an attribute name and > multiple values. 'headers' adds just one term and otherwise re-uses > core features (ID). > > It shold be made clear that the Accessibility Initiative does care > about both language simplicity and authorability of features. The > PFWG charter identifies both authorability and "small footprint" as > values to be sought in markup language designs. This is why we > advocate for the 'backplane' re-engineering efforts to distill common > functions and provide common solutions for them, and why we have > invested in developing Authoring Tool Accessibility Guidelines and > techniques. > > 4. 80%-rule-NOT > > Some commentors have suggested that in order to sustain a small > language there have to be some screening factors, and frequency of > use in the as-is Web is the screening factor to use. > > The WAI position on this is roughly "that is like saying that the > builder of a high-rise building should decide whether or not to > include fire-stairs based on whether the previous buildings at that > street address had burned down or not." > > We don't build fire stairs just enough to evacuate 80% of the occupants. > > Accessibility features address failure modes that are infrequent, but > critical when they occur. > > Popularity among authors should be used to select between _functionally > complete_ alternative strategies for supporting required functionality. > > 5. The path forward. > > Starting from scratch, the broader @labelledby and @describedby > relationships are still needed, even with @scope and/or @headers, > because the needed semantic information is not limited to table > cells. Inside tables, these together with better algorithms could > make either or both of @scope and @headers deprecatable, suitable to > migrate out of use. > > Leaf-by-leaf markup with a bottom-up facility, will still be needed to > cover irregular cases. Such schema-terse, instance-verbose technology > can certainly be used less frequency if structural > reforms are introduced such as for example nestable row-groups in > place of the present awkward 'tbody' at one level only. > > 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 is the fastest change that would be appropriate. > > In any case, the function is needed, and 'headers' markup is currently > 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. > > 6. summary: > (some more discursive details follow signature) > > 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. > > <to-be-signed-here/> > > ** details. > > 7. 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? > > 8. 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 data > structure. Just further structure above a flat list in the row and > column collections. > > 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. Regularity is a convenience of language; > less common in the wild. Consider the periodic table of elements in > Chemistry. It's not truly periodic, it is quasi-periodic with > progressively longer and longer rows. It's a blend of table and tree > with important properties from each. Similarly the tree-table > structure we are working on in WAI-ARIA that is a commonplace of file > browsing today. > > There are 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. > > http://juicystudio.com/article/html-scope-headers-debate.php#overlaidtable > > In the wild we also found 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.' > > 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 > > Rationale at the time of HTML4: > http://www.w3.org/WAI/PF/guide.html#TABLE > > Philosophy behind 'headers' as 'lowest level language' that covers all > cases: > http://www.w3.org/2002/Talks/06/24-US_FedStatsWorkshop/slide1-0.html > > 9. There's room for further re-factorization 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 > > One way to avoid language bloat is to build in effective metadata > capabilities. Let's not overlook that lever as we work to ensure that > what is easy *is* easy, but what is hard *is* possible. > > 10. Current awareness, demographic research. > > The WAI would benefit from better tools to gauge the state of accessiblity > in the as-is Web. Organizations active in the HTML WG have data and tools > that could make this possible. If possible, we should start an exploratory > conversation about methods of asking the Web questions of interest. > Raw feature presence or absence is too coarse, but searches that would > find a collection of table-bearing pages that had, say, 10% irregular examples, > would then with combined mechanical and manual screening, give us a much > better set of samples to try algorithmic proposals against. Algorithmic > proposals should include both user agent proposals as to how to extract > metadata from the markup *and* authoring tool algorithms as to when > and how to challenge the author so that the metadata extracted by the > user agent is more frequently accurate. > > There has been some suggestion that 'headers', where used, has mostly > been used wrong. Is there any way to see if the used-wrong vs. used-right > difference has a significant correlation with the tools used? This would > be of interest to the toolsmiths and WAI Education and Outreach. > > </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/ > > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org
Received on Monday, 4 June 2007 15:27:54 UTC