Re: Request to Strengthen the HTML5 Accessibility Design Principle

Ian Hickson wrote:
> On Wed, 24 Jun 2009, Laura Carlson wrote:
>>> Is that what you mean by collaboration?
>> I mean real debate.
> I presume, from your e-mail, that you do not consider this to be debate:
> Could you elaborate on why?

I believe that the following:

   > * We need summary for backward compatibility.

   HTML5 supports implementing the summary="" attribute for backwards
   compatibility as currently written.

... is an example of what Laura describes as "selectively choosing those 
points in a subject which happen to favor a position, while ignoring the 
rest".  Another, more recent, example is "The browser vendors are the 
ultimate gatekeepers, of course".

  - - -

The topic at hand is making a summary attribute conforming, where the 
attribute is not displayed by browsers to users with no visual or 
cognitive disabilities, but is available to assistive technologies.

Having read quite a bit of "debate" on the subject, I believe that the 
statement that "We need summary for backwards compatibility" is more 
than a bit of an overstatement.  I don't believe that the following 
supports that statement:

Item 23 in that list comes closest, but explicitly talks about a 
replacement, from which I infer that "something better" has more weight 
than "backwards compatibility" in this case.

Item 20 in that list is even more compelling, though I would suggest 
change the first word from "Reinstating" to "Including" to avoid 
triggering yet another unnecessary discussion on "yanking".

[tangents: I see no value in #19: at best it reiterates, at worst it 
distracts; #22 seems to be not only missing a word or two, it doesn't 
seem to belong in this list; finally, I'm also unclear why #10 is an 
item in the list in the *next* section: perhaps applicable design 
principles should be a section of its own?]

  - - -

If there could be agreement on "something better" that agreement would 
have the effect of reducing the period for which a summary attribute 
would need to be conforming, perhaps even down to the span useful life 
of HTML 4, something that is likely to outlive us all.

If we are talking about plain text which should not routinely be 
displayed to users with no visual or cognitive disabilities, making it 
an attribute (vs an element) would require the least change by browser 
vendors.  Renaming the attribute shouldn't be done simply because the 
current attribute has been misused; if there are other reasons to rename 
the attribute that would be fine, but it would make sense to understand 
and address the reasons why the current attribute has been misused.  If 
we are talking about an attribute, it need not be on the table element. 
  Perhaps an attribute whose name starts with "aria-" and ends with 
something that suggests "holistic overview" and is placed on the caption 
element would have less problems, but that's a subject of language design.

I am not as familiar with ARIA as I should be, but my understanding is 
that there currently isn't an attribute defined by ARIA which meets this 

Even this approach doesn't address all of the issues in the following list:

In particular, bullets #3, #4, and #9.

- Sam Ruby

Received on Wednesday, 24 June 2009 10:46:00 UTC