RE: second DRAFT Re: headers attribute debate

Thank you, Jim.

I folded your analysis into the message that I forwarded just now
to the HTML WG.

http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html

Hope I didn't break anything.

Al

At 10:27 AM -0500 6 06 2007, Jim Allan wrote:
>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 18:14:38 UTC