W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: summary attribute compromise proposal

From: Murray Maloney <murray@muzmo.com>
Date: Wed, 05 Aug 2009 17:49:05 -0500
Message-Id: <5.1.1.6.2.20090804173927.070e7010@mail.muzmo.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: HTML WG <public-html@w3.org>
Maciej, thank you very much for your proposal.

At 11:03 AM 8/4/2009 -0700, Maciej Stachowiak wrote:

>I believe there are two different value systems in conflict in the
>summary dicussion:
>
>A) HTML5 should guide authors toward choices that will result in the
>best accessibility outcomes, based on reasoning from the best evidence
>we have available. Argument that are not outcome-driven or evidence- based 
>are seen as irrelevant, from this point of view.
>
>B) If HTML5 provides advisory guidance on how to use HTML constructs
>to make accessible documents, it should not directly contradict other
>W3C guidance on accessibility. It's ok, from this point of view, to
>expand on guidance, but direct contradiction is seen as giving an
>inconsistent message.
>
>I don't think we can always reconcile these two value systems.
>Sometimes there is no solution that will meet both goals.

I don't agree with your characterizations, but if it helped you get here, 
good for you.

>In this case, I believe a solution may be possible which can satisfy
>everyone. Here is my proposal:
>
>1) HTML5 will continue to list and advise use of new techniques that
>can be alternatives to summary="".

I get this, but I think that I would say "HTML 5 will continue to include 
advice
on the techniques that may be used to ensure that documents are as accessible
as possible under the circumstances.

I don't think that we need to put emphasis on 'alternatives to summary'. 
Perhaps
that section should be co-written by someone who understands and appreciates
the value of @summary.


>2) HTML5 will not make any flat direct statements that summary=""
>shouldn't or can't be used. Instead, it will say that authors SHOULD
>use one of the other techniques when possible and appropriate. In
>particular, it should advise authors to consider:
>      (a) Is a particular piece of information useful to the blind or
>visually impaired? -- If not, it shouldn't be included in summary.
>Authors must not put useless text in summary to give a pro forma
>appearance of accessibility.
>      (b) Is a particular piece of information useful in a visual
>rendering as well? For example, is it useful to people of normal
>ability, or to other handicap groups, such as the cognitively
>disabled? -- If so, the information should be included in a way that
>is available to everyone, such as <caption>. If the information would
>be potentially useful, but possibly distracting, it can be made
>available to everyone but hidden by default, for example using
><details>. For example, describing the conclusions of the data in a
>table is useful to everyone. Explaining how to read the table, if not
>obvious from the headers alone, is useful to everyone. Describing the
>structure of the table, if it is easy to grasp visually, may not be
>useful to everyone.

I think that what you are aiming for is a bit of text that could explain the
many ways that a complex table could be made more accessible for all.
That's a good thing and I support that idea. However, I think that a bit
of text that explains when @summary is the best solution is also warranted.


>In other words, rather than focusing on what authors shouldn't do, the
>spec will focus on what they should do instead. I believe this
>achieves the goal of promoting better accessibility outcomes, without
>directly contradicting WCAG2.

Sure, so long as we include text that advises when @summary is the best way 
to go.


>3) HTML5 will continue to include a mandatory warning for summary="".
>The purpose is not to completely prevent authors from using
>summary="", but rather to bring alternatives to their attention, as
>described above.

As others have written, I am a bit uncomfortable about a mandatory warning.
I would be much more comfortable with the warning if it were issued
in the context of a category of warning about accessiblity, in which case
I think that there should be three levels of warning: 1) Silent, 2) brief 
mention
3) verbose, including possible advice.


>4) The goal of HTML5 in this case is to promote good accessibility
>outcomes based on evidence. Telling someone that the technique they
>are using is dumb or wrong, even by implication, is not necessary to
>serve this goal, providing relevant information is what serves the
>goal. Thus, the spec will be changed to avoid disparaging summary in
>unnecessary ways. For example, describing summary="" only in the
>"obsolete features" section and not in the "table" section gives the
>appearance of disparagement. There may not be an evidence-based reason
>to stop doing this, but I don't see an evidence-based reason to
>continue doing it, either. So, why needlessly give offense if the goal
>can be served either way?

Just so.


>5) HTML WG will propose a WCAG2 Techniques update to the appropriate
>working group of WAI (is it PFWG or WCAG WG?) to better reflect HTML5
>features for describing tables. I can draft a message to communicate
>this, but I'd like to request:
>     (a) John Foliot as a co-signer (assuming he agrees with the
>language), since he said he'd support an effort to update WCAG2, and
>I'd like to make clear that this is a coordination effort, not an
>attempt to pick a fight.
>     (b) I'd like to ask for some official blessing from the HTML WG
>for this message, since WAI apparently takes official input from
>Working Groups more seriously than input from individuals.

I fully support this.


Also, I have noted comments from various people including yourself about
the visibility of @summary. I would like to suggest wording...

"The summary attribute is intended primarily for use by Assistive 
Technology (AT).
The value of the attribute is intended to be text which describes or 
summarizes the table
for readers who may not be able to see it. Interactive screen readers and 
other AT software
can present the value of the summary attribute to the user to assist them 
in understanding
its structure or content. Visual user agents may also display the value of 
the summary attribute,
but are advised to do so only at user request or as a result or user 
preference settings, because
the information contained in the summary attribute is typically not useful 
to individuals
who can see the table."

I didn't spend a lot of time writing that, so it could certainly benefit 
from wordsmithing.

Regards,

Murray
Received on Wednesday, 5 August 2009 21:50:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:43 GMT