RE: second DRAFT Re: headers attribute debate

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
(http://www.alphaworks.ibm.com/tech/raven).

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 attribute,
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, Chair UAWG

> -----Original Message-----
> From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org]On
> Behalf Of Al Gilman
> Sent: Saturday, June 02, 2007 12:16 PM
> To: wai-xtech@w3.org
> Subject: second DRAFT Re: headers attribute debate
>
>
>
> <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/c
> zsched.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/c
> zsched.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-ac
> cessibility-testing/
> >
> >Roger Johansson:
> >http://www.456bereastreet.com/archive/200705/help_keep_accessibil
> ity_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, 6 June 2007 15:25:46 UTC