Re: [DRAFT] Heartbeat poll

On Sat, 1 Aug 2009, Sam Ruby wrote:
> Ian Hickson wrote:
> > 
> > The second request is:
> > 
> > | More importantly however, is to remove the author guidance that today
> > | explicitly contradicts existing, W3C approved Accessibility Guidance 
> > | as written in WCAG 2.
> > 
> > I don't know which author guidance that is. Could I request more 
> > specific feedback for this request?
> I believe that John is referring to this:

Specifically, this appears to refer to:

It appears this guidance was written before research regarding the misuse 
of summary="" was presented. I understand that there is a desire to avoid 
conflicts, but it appears that the right solution here would be to change 
the guidance to take into account the information that has since been 
collected, rather than to force HTML5 to suggest that authors follow 
guidance that has been shown to be less than optimally effective.

Procedurally, it seems that the WCAG20 document applies specifically to 
HTML 4.x and XHTML 1.x documents, and HTML5 is thus out of scope. As such, 
I don't think that there is actually a real problem here. It is also worth 
pointing out that WCAG 2.0 here explicitly contradicts US goverment 
documentation that the WAI presented to me [1], which, after discouraging 
the use of summary="", says "web developers who are interested in 
summarizing their tables should consider placing their descriptions either 
adjacent to their tables or in the body of the table, using such tags as 
the CAPTION tag", which is exactly what HTML5 recommends.

[1] (Last 
paragraph of section h.)

On Sat, 1 Aug 2009, Shelley Powers wrote:
> The decision about summary was based on an analysis of data pulled from 
> web pages scraped from the internet[1]. What's been ignored in the 
> discussions related to the incorrect use of the summary attribute is 
> that only about one in 1,000 HTML tables reflect correct HTML table use. 
> So, accuracy when it comes to past use of HTML tables is just something 
> that one can't "accurately" assess. The raw data is interesting, but we 
> can't draw conclusions from it.

We can if we have sufficiently large corpuses.

> I found that rather than looking at raw data use, if we look at 
> discussions people have had about the table summary attribute, instead, 
> we find that the summary attribute has been taken very seriously, but 
> its use isn't necessarily showing up on the web, or in Google.

It doesn't matter how seriously people take it, if users don't see an 
improvement in their user experience. The pages people look at _do_ end in 
on the Web; that is in fact the exact content we are concerned about.

> For instance, this bug report is for a CMS and is directly related to an 
> incorrect table summary. The summary use is accurate, but the table 
> structure was altered, and the summary needed to be changed to reflect 
> this alteration.

This is a very common problem -- a problem that would not occur with the 
same frequency if the explanatory information were visible to all.

> The table summary is also probably one of the better examples of why 
> something like summary is necessary, including the important note that 
> column 1 is not used. A sighted person would see immediately that column 
> 1 is not used, so this information is redundant to the visually enabled. 
> For those people who need to use a screenreader, though, if they didn't 
> know that column 1 is empty, they would end up getting some variation of 
> "blank" for every cell in that column. The information about the second 
> column is just as valuable, as it informs the person that column 2 has 
> checkboxes, again something that a sighted person would see immediately.

I do not believe anybody is suggesting that explanatory information is not 
useful. On the contrary, advocates in favour of encouraging alternatives 
to summary="" have argued that the explanatory information is useful to 
many people, not just users of ATs, and that we should not be limiting the 
information to specific groups of people, and should instead be making it 
accessible to all.

> Your sampling is flawed because it doesn't account for a significant 
> number of web pages that are not accessible to the public.

Pages that are not part of the Web do not need to use a standard 
interoperable across the entire Web, they can use proprietary formats. 
They can, for instance, use HTML with summary="" added back in, or the 
Word document format, or anything else. Controlled environments are not, 
and should not be, a particularly important concern in the development of 
a world-wide vendor-neutral standard.

> And you, yourself, have never answered the questions about why you're 
> eliminating summary because of its flawed use, when its been 
> conclusively demonstrated that HTML table usage is equally flawed, and 
> therefore any sampling is tainted.

We are eliminating all the aspects of tables that make it suitable for 
layout (all the presentational attributes) in an even stronger fashion 
than sumamry="". While <table summary> is conforming but discouraged, 
<table width>, <tr bgcolor>, etc, are all completely obsolete and not in 
any sense conforming now.

If you have an alterantive solution for tabular data that is less likely 
to be used for layout tables, though, I'm certainly open to suggestions. 

With summary="" we can improve matters. So we should.

> I don't believe that JAWS or other assistive technology applications 
> will immediately make changes to their tools based on a Working Draft 
> that is under a great deal of contention.

HTML5 doesn't require any change. It keeps summary="" in the 
implementation requirements unchanged. (In fact I would go further -- it 
introduces implementation requirements that HTML4 did not have.)

On Sat, 1 Aug 2009, John Foliot wrote:
> Maciej Stachowiak wrote:
> > 
> > The
> <em>editor's</em>
> > former position was that summary="" should be nonconforming.

That is still my position.

> > Your position (and that of other advocates) was that it should be 
> > conforming and recommended. I think making it conforming but 
> > discouraged is a middle ground.
> The language is not "discouraging": it is specifically stated not to use
> the attribute.

What it says is "Authors should not specify the summary attribute on table 
elements" which in RFC2119 terms is not a flat out requirement not to use, 
but is in fact just a discouragement.

> The current Draft text is not a compromise, as that infers that there 
> was a discussion and good faith proposal to arrive at that position.

The text _is_ a good faith proposal.

> Instead, it is language and status that has been imposed by one person, 
> and the 'solution' directly contradicts other W3C Recommendations with 
> impunity.

The WCAG 2.0 document listed at the top of this e-mail is not a W3C 
Recommendation, it's a non-normative Note. What Recommendations does it 

> Here's another compromise proposal: make @summary conformant but
> deprecated (not obsolete)

Could you clarify what you mean by "deprecated" and "obsolete"?

> If WHAT WG/HTML WG wishes to approach WAI PFWG with the suggestion of
> revising guidance surrounding @summary, based upon the evidence they have
> collected, then I am sure that PFWG would listen attentively and take the
> request seriously - and I would advocate just as loudly then to do so as I
> am now for acceptance of W3C protocol.

Actually, when I did that, the PFWG ignored me, and when I asked if a 
response from the WHATWG would receive any more of a reply, I was ignored 
again. I have tried repeatedly to work with the PFWG on this issue and 
gotten nowhere:

I am _still_ awaiting a response from the PFWG to my e-mail sent in June:

...or to my recent e-mail that showed that the "27 different bullet points 
addressing why @summary should be retained as a fully recognized 
attribute" actually consist of duplicate points, non-sequiturs, arguments 
that either apply equally well to the text in the HTML5 spec today as to 
the summary="" attribute, anda rguments that in fact argue for text that 
is in fact already in the HTML5 spec:

Instead of appealing to a process which is in fact exactly the process 
that I am following (with editors making proposals in documents that they 
edit, responding to technical feedback, reasoned arguments, research), I 
would encourage you to actually listen to the arguments being made, 
consider them, and if you disagree, counter them with equally valid 
arguments and research.

On Sat, 1 Aug 2009, John Foliot wrote:
> It is not Ian's place to overstep WAI, despite his best intentions 
> toward improving accessibility

Actually, it _is_ my place to make proposals that improve on the status 
quo. I am not required to blindly follow other documents, and will not do 
so. Any proposals I make are going to be based on reasoned arguments and 
data, and anyone who sends feedback will be held to the same bar. The PFWG 
is welcome to explain to me why summary="" is preferable to the techniques 
listed in the HTML5 spec (and recommended by the US goverment in documents 
cited by the PFWG!), but merely asserting the correctness of such a 
position will not get the PFWG anywhere.

> if he strongly believes that continued usage of @summary is harmful, 
> then he needs to make that case to WAI - just as he insists that others 
> state their case to him when advocating their cases.

I have done so, first in this e-mail to Janina (cc'ed to w3c-wai-pf and 
wai-liason), which never got a reply from the PFWG:

...then in this e-mail, also to Janina (cc'ing the same groups), which 
also never got a reply:

The latter also cited the following which includes all the references I'm 
aware of at this time:

> 1) the truthiness[1] of the 'proof of harm' has been disputed by many

Has it ever been disputed with reasoned and unrefuted arguments? If so, 
could you point me to those arguments?

> Sufficient examples of the proper use of @summary have been delivered to 
> the working group to prove that it serves a unique and needed function 
> today.

Actually, the examples delivered indicated that summary="" was misused 
even when used with the best of intentions, and as far as I can tell they 
didn't prove that summary=""'s function was in any way unique, since the 
techniques listed in the HTML5 spec can perform the same function.

> 2) the current draft simply replaced Ian's proposal with your proposal
> with zero consultation

The PFWG has been repeatedly consulted and has declined to reply.

On Sat, 1 Aug 2009, John Foliot wrote:
> >
> > The second request is:
> > 
> > | More importantly however, is to remove the author guidance that today
> > | explicitly contradicts existing, W3C approved Accessibility Guidance
> > | as written in WCAG 2.
> > 
> > I don't know which author guidance that is. Could I request more 
> > specific feedback for this request?
> Editor's Draft:
> 4.9.2 The table element
> Content attributes:
>     Global attributes
> ****New****
>     Content attribute: 
>     summary
> "This attribute is suggested in earlier versions of the language as a <a
> href="">technique
> for providing explanatory text for complex tables</a> for users of screen
> readers.
> <p class="XXX">It has been suggested that the summary="" attribute should
> be made obsolete in favor of other techniques, and the working group may
> vote on the matter at some future point.</p>
> (thoughts on conformance status - ideally validators would flag this as an
> unresolved issue.  User agents already render for backwards compatibility)
> ******
> Remove @ Line 68073: "Authors should not specify the summary attribute on
> table elements.  This attribute was suggested in earlier versions of the
> language as a technique for providing explanatory text for complex tables
> for users of screen readers. One of the techniques  described in the table
> section should be used instead."

I'm having trouble understanding what you are suggesting here. It appears 
you are asking for the following:

 * Move summary="" from "obsolete but conforming" to "fully conforming".

 * Remove all advice regarding how tables should be made accessible.

 * Add a reference to the WCAG 2.0 "Techniques" note for HTML 4.x and 
   XHTML 1.x.

Is that correct?

> Justification:
> WCAG 2:
>   Techniques for WCAG 2.0 - H73: Using the summary attribute of the table
> element to give an overview of data tables
> "The objective of this technique is to provide a brief overview of how
> data has been organized into a table or a brief explanation of how to
> navigate the table. The summary attribute of the table element makes this
> information available to people who use screen readers; the information is
> not displayed visually.
> The summary is useful when the table has a complex structure (for example,
> when there are several sets of row or column headers, or when there are
> multiple groups of columns or rows). The summary may also be helpful for
> simple data tables that contain many columns or rows of data."

I haven't made these changes. I consider disagreement with WCAG 2.0 to be 
acceptable; accessibility guidelines evolve over time, and that's fine. 
It's ok if a working draft of a new version of HTML contradicts some of 
the advice that was based on the previous version of HTML, if the 
contradiction is based on trying to improve accessibility based on data 
collected about how the aforementioned guidance is actually working.

If you want to make summary="" conforming and not obsolete, then we will 
need reasoned arguments and research to demonstrate why this is expected 
to improve accessibility. For example, as a start, the PFWG could respond 
to the questions in this e-mail:

...and could explain why the reasoning given in this e-mail is wrong:

I do not think that removing the guidance on how making tables accessible 
is wise; as with the alternative text section, I think we have a duty to 
put advice in the spec for how to make pages accessible. It's part of the 
language; farming out accessibility concerns to an entirely separate group 
would be a terrible way for us to act, and would likely lead us to making 
poorer decisions overall, since accessibility would no longer be always in 
our face. It would be like making farming out security to another working 
group -- not a recipe for good security practices.

I think that adding a reference to the WCAG 2.0 "Techniques" note for HTML 
4.x and XHTML 1.x would be inappropriate, since that note explicitly 
doesn't apply to HTML5 (not to mention that it makes suggestions that 
aren't supported by the available data).

In conclusion, I cannot in good faith make the changes you are requesting 
at this time. If there were solid reasoning or research to back up these 
requests, then I would naturally reconsider.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 2 August 2009 03:46:38 UTC