function and impacts (was: @scope and @headers reform)

Chris,

I hear you are 'collating and distilling' the debates on
HTML WG ISSUE-20 http://www.w3.org/html/wg/tracker/issues/20 .
Allow me to presume to contribute.

[background/aside] I would like to ask you and Mike to agree
with me on some joint-meeting time at the TPAC to discuss TABLE
markup reform (joint = including representatives of at least PFWG
and HTML WG).  [good-ish times for us: start with an allocation in
the PFWG meeting somewhere between morning break and lunch on
Tuesday; continue in the HTML WG meeting some time not Saturday.]

I am becoming increasingly convinced that to get the TABLE reform
topic back on a productive track we [HTML WG, PFWG, and related
stakeholders] *really* need to pursue both prongs of what you
offered to PFWG at or F2F as advice on how to help, to wit:

a) identify the functional requirement

b) gain the support or at least the understanding of those who
would have to code the implementation before attempting a decision
in HTML WG at large.

I actually lay a slightly different conceptual frame on this:
Let me call it "gathering the interests of stakeholders."
Talking functional _requirement_ sounds too much like we have
already reduced this to a black and white "enough" threshold.
Because there *are* tensions between the interests of different
stakeholders, we first need to identify the interests (qualitative
performance factors) of all stakeholders before we start talking
compromise on what is 'enough.'

Let me try to encapsulate some of the different interests I
can see:

* people with disabilities have an interest in
having a machine-recognizable association between cells in
the table and their in-the-table critical context.  The
critical context is comprised of the related facts and terms
(cell contents) that you would use if you "tell me what this
cell tells me, in a sentence."

* more generally, many users have trouble interpreting tables.
The trend in web content has been toward the use of transient
extensions of the display that trigger off the focus or the
mouse pointer location.  There is a market opportunity for
such transient displays to improve the effectiveness of table
presentation (quite broadly) but this would depend on the
transient display being totally canned or depending on the
associations discussed above if generated.

+ note: the 'functional requirement' is to be expressed in
terms of "what associations need to be captured."  Here 'captured'
means 'conveyed in machine-recognizable ways.'  'Machine
recognizable ways' includes syntax patterns such as <td> is
within @scope of <th> as well as more direct forms such as
"ID of <th> is in @headers of <td>."  Can't talk
about the functional requirement in terms of @scope, @headers,
<td> and <th> other than as examples, because the definitions
of these things are on the supply side.  Evolution in their
definitions is in the realm of reasonable proposals for how to
improve the present situation.

+ note: I think we should be able to come up with a definition
of header hierarchy where there is consensus that this is present
in the table genre that we have to cover.  It's widespread.

* [related general requirement] users and authors both have
an interest in the authors being able to input information
in terms they understand.

* authors have an interest in being able to input these
associations from 'general' to 'specific' (example: <th> to <td>)
or from 'specific' to 'general.'

* users have an interest in authors being able to check
the completeness of their associations from 'specific'
(cell to understand) to 'general' (critical context).

* there is a tension (competition) between performance
on these user and author interests.

+ note: That tension constitutes demand.  It creates business  
opportunities.

* Accessibility specialists have a business opportunity
in providing user-need satisfaction above and beyond what
the lay author would produce readily.  Organizations can,
by labor specialization in the content production workflow,
perform above and beyond what their content experts could
achieve without this outsourcing or additional workgroup.

* Authoring tool developers have a business opportunity
in providing WYSIWYG-dialog-to-markup transformation of
the association information above. They share the business
opportunity to mitigate the tension between user and author
interest that the consultants address.

* Servers and website sponsors have an interest in
byte-count efficiency in what goes over the wire.

+ note: this tends to favor @scope-like markup over @headers-like markup
where applicable.

+ note: @scope-like markup requires more burdensome processing on the  
client
side to get the associations to the user than does @headers-like markup.

+ note: @headers processing is part of the status quo on the client side
as available to users with disabilities; @scope processing is not

+ note: @headers uncouples the table organization and appearance from
the sufficiency of association, with an attendant cost in byte count.
The decoupling is helpful in both the consultant-mediated and tool- 
mediated
markup use cases.

+ note: there is division about whether scope-like markup can ever
offer enough coverage so as to make @headers-like markup unnecessary.

+ note: getting the association information out of indirect (scope-like)
markup involves processing on the client that isn't there now.  Browsers
and AT both have the opportunity to do (some) of this.  The past  
successes
with accessibility APIs (cf. WAI-ARIA) suggest we may do better with
some standard functional model for the division of labor between the
browser and the layered AT.  Example division of labor:

++ browser provides via DOM a method to learn the "immediate critical
context" (in bottom-up @headers-like direction) for cells that combines
the results of @scope-implications analysis with @headers data.  These
are cumulative; @headers does not cancel @scope.

++ AT is expected to chain critical context as appropriate, that is to
say if the cells cited as critical content for the focussed cell have
themselves non-empty critical context, the AT will follow and optionally
user their context in presenting content to the user.  In other words
the browser-supported method does not flatten the transitive closure
of the immediate critical context.

+ note: we need to learn how willing the affected code-developing  
parties
are to implement some such allocation of function.

+ note: the new <datagrid> element offers an alternative for some of
the "irregular tables" that formed the justification for @headers in  
HTML4.

+ note: @aria-labelledby may offer an alternative for some cases that,
before ARIA, would have to have been solved with @headers.

Received on Sunday, 14 September 2008 14:47:22 UTC