Re: summary="" in HTML5 ISSUE-32

Maciej Stachowiak 2009-02-26 22.48:

> On Feb 26, 2009, at 1:15 PM, Matt Morgan-May wrote:

>> "The structure of a table may not be visible to blind users, 
>> but that is a reason to provide summary information"

+1

@summary is for those for whome a few words say more than one 
table structure.

> I think everyone agrees that tables may be difficult to 
> understand for blind users, and that some additional 
> information may need to be provided. However, additional 
> information about table structure, or summaries of the tables 
> conclusions, may be needed by users with other disabilities, 
> such as cognitive disabilities. It may also be needed by users 
> of what we consider normal ability, but who nontheless have 
> trouble understanding.

Just a question: would @title be any better for those other users?
I mean: would @title be quite good to them?

> I don't have a strong position on the technical solution we use
>  to provide summary data. But I *do* feel strongly that we 
> should respect the Design Principles in stating the problem and
>  proposing solutions.

The only thing I have a really strong opinion on in this is the
semantical side: Authors, users, UAs must be ale to discern
caption from summary. It is not acceptable to join summary into
<caption> if we do not simultaneously allow <caption> to be
divided into title part and summary part (and possible other parts.)

> I think there is an underlying difference in design philosophy 
> here. Let me summarize what I see as the two core positions:
> 
> 1) Accessibility is best served by features that are 
> specifically designed for accessibility. In particular, 
> existing features that are meant to aid accessibility should 
> remain supported and conforming, or we are likely to harm 
> accessibility overall.
> 
> 2) Accessibility is best served by general-purpose features 
> that automatically improve accessibility as a side effect. We 
> should be willing to replace accessibility-specific features 
> with general-purpose but accessibility-friendly features to 
> improve adoption and correct usage.
> 
> I think both sides have a point, and more importantly, both 
> sides share the goal of improving accessibility. So let's keep 
> the conversation focused on reasons we think one approach or 
> another better aids accessibility, rather than accusing each 
> other of reducing accessibility.

The problem with @summary, in my view, is not the lack of
visibility per se, but that authors do not undersstand where in
the map it belongs. I proposed caption@title precisely because I
thought that this would help authors to draw a link - as well as 
to discern - between a caption and the summary.

As for position 1: I think it does hurt the usefullness of 
otherwise well-intended features, if a feature is difficult to 
test, such as @summary has been. When normal authors do not get to 
see it, and when authors do not see the link from @summary to 
something they can relate to (<caption> - though not all authors 
know about <caption> either, I think), then they are bound to make 
errors.

As for position 2: It seems that we do not have any strong 
advocates for that in this group because I do not consider lumping 
summary and caption together without any disctinction whatsoever 
as a general-purpose position. It reminds more about the atheist 
happy evangelium that "there is no sin and no hell either". At 
least it is a position that asks us to swall not one but two chamels.
-- 
leif halvard silli

Received on Friday, 27 February 2009 00:59:29 UTC