Re: second DRAFT Re: headers attribute debate

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