Re: "tableinfo" Change Proposal and status of WCAG2 supporting documents

On Thu, Mar 5, 2010 at 12:29 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>> So I suggest redrafting your proposal to make it clear where
>> your argument depends on clear WCAG2 normative requirements,
>> where it depends on debatable interpretations of those
>> requirements informed by Understanding WCAG2, and where it
>> depends on wider purported (and ideally documented)
>> accessibility benefits.
>
> I am sorry, but this is a bit too lofty for me.

Essentially, all I'm saying is:

People regularly confuse WCAG2 with the informative, non-standard
supporting documents so I suggest you follow how WAI ask one to
cite their documents and explicitly distiguish between the two,
rather than using "WCAG2" as a synecdoche for both.

There's a history of such confusion in the context of @summary.
If accessibility luminaries like John Foliot can make this
mistake -

"the WCAG 2 Official Recommendation says that authors should use
@summary"

http://lists.w3.org/Archives/Public/public-html/2009Aug/0052.html

- then so help the rest of us. Your proposal need not make this
mistake in thought to make it in appearance - and that
/appearance/ adds noise to the debate.

I think the distinction is important in this case because:

   * It doesn't intrinsically matter if WCAG2 techniques cannot
     be deployed as conforming HTML5. (It might matter for some
     indirect reason, but let's be explicit!) Your Proposal seems
     to set out the inapplicability of a technique as something
     that needs fixing. But it seems more costly to add an element
     to HTML than to update the technique.

   * The Understanding document does not change the actual
     conformance requirements of WCAG2. Authors are not limited
     in their use of <caption> or @summary in HTML4 (let alone
     HTML5) by anything in the Understanding or Techniques
     documents.

   * WCAG2 does not (AFAICT) *require* a distinction between
     table caption, media-independent table info, and non-visual
     table info. "Information, structure, and relationships
     conveyed through presentation can be programmatically
     determined or are available in text" says WCAG2. This is the
     hard requirement, and the "or" is important here. (I don't
     mean publisher responsibilities end with what WCAG2
     requires. Accessibility is bigger than that. I'm just
     talking about the specific requirements WCAG2 lays on
     authors.)

Because implementor, author, and even end-user effort is limited,
judgement must be exercised about which relationships (or
fine-grained distinctions between relationships) require features
to enable programmatic determination to significantly increase
accessibility. For example, "label for this field" is obviously
critical, "verb of this sentence" not so much.

It may well be the distinction between table caption,
media-independent table info, and non-visual table info is one of
those distinctions that deserves explicit feature support.

As an interested onlooker, what I'd personally hope to see from a
Change Proposal like yours is:

   1. A user-centric argument about why it is important to carve
      up the semantic space "text associated with this table as a
      whole" the way you suggest, as opposed to making no distinction or
      finer-grain distinctions (e.g. distinguishing a recipe for
      how to use the table from a summary of the table's
      information).

    2. A breakdown of why HTML5's existing features like <figure>,
       <details>, and ARIA annotations are insufficient to enable
       the same functional benefits. You do mention @aria-labelled
       as an option, though I'd have thought it's a closer fit for
       designating part of the caption for table identication than
       for associated content outside the caption with the table
       as table info.

Your proposal mentions "AT and other user agents gains a way to
discern between table identification string and other table
related content" as a benefit, but does not explicitly state
*why* this is a significant benefit. (It's a bit like reading a
proposal for a <verb> element that didn't suggest how it could
actually be used.)

I suppose user-agents /could/ exclude non-caption table info when
listing tables and /could/ disable non-visual table info on user
request. I don't know if this is what you had in mind.

In terms of today's behavior:

   1. Popular screen readers that support @summary, read <caption>
      *and* @summary by default when listing tables and when
      entering a table.

   2. Window-Eyes allows users to disable @summary. (Note it's
      not unusual for screenreaders to allow users to disable
      surfacing of some HTML feature or other. For example, you
      can also stop Window-Eyes reading table header cells as you
      move through the table data cells.)

Because there hasn't been a firm distinction in practice between
the type of information put in <caption> and @summary, and
because in practice @summary values are often worthless, it's not
clear how much support these behaviors provide for making the
distinctions you suggest. That is, it's not clear to me that
users want to exclude such information from table lists or when
reading through the page.

In terms of support from existing HTML5 features, does the addition
of "tableinfo" enable any new functionality over:

<table summary="The first group of columns contains a breakdown
                of sales by product.  The final column contains a
                total sales figure.  Each row group contains the
                figures for one year. The first row in each group
                states the year, the final row contains annual
                totals, and the rows in between contain monthly
                sales figures."
       aria-labelledby="sales-table-label">
  <caption>
    <p id="sales-table-label">Sales
2005-2009.</p>
    <p>Sales increased by 32% between 2005 and 2009 to reach
       a total of $82 million. Superduper Widget saw its
       percentage of sales fall to 10% while Luxury Widget saw
       its percentage of sales increase to 80%.</p>
    <p>Sales figures are listed in thousands of dollars.</p>
  </caption>
...
</table>

Or is this more a matter of pushing accessibility support into
the ARIA host language or making an easier syntax for authors to
use?

Anyhow, it's your Change Proposal. Feel free to take this
feedback or leave it. :)

--
Benjamin Hawkes-Lewis

Received on Friday, 5 March 2010 09:08:18 UTC