Re: summary="" in HTML5 ISSUE-32

Hi Matt,

I'll try to clarify what I mean, although at this point I'm risking  
dominating the thread and repeating the same arguments, so I'll try to  
lower my participation after this.

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

> On 2/26/09 11:16 AM, "Maciej Stachowiak" <mjs@apple.com> wrote:
>> Limiting the problem scope to non-visual media would, at first  
>> glance,
>> violate our Media Independence and Accessibility design principles:
>>
>> http://www.w3.org/TR/html-design-principles/#media-independence
>
> I don't see any relevance to this principle.

The Media Independence principle says that when possible, features  
should be designed to work with all media. Thus, setting out to solve  
a problem only for non-visual media and explicitly excluding other  
media would be in conflict with this principle. That doesn't mean the  
principle is absolute, but I think our going-in assumption should be  
to *try* to solve problems for all media types, and only resort to  
media-specific approaches if we can't come up with a good media- 
independent solution. Does that clarify?

>
>> http://www.w3.org/TR/html-design-principles/#accessibility
>
> But on further reflection, one should see the parallels between what  
> is
> written in that second link:
>
> "The image in an img may not be visible to blind users, but that is  
> a reason
> to provide alternate text(...)"
>
> ...and what we're dealing with here:
>
> "The structure of a table may not be visible to blind users, but  
> that is a
> reason to provide summary information"

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.

So the question is: do we try to solve this problem only for users who  
will be using a non-visual rendering (voice or braille) or for all  
users? That is the crux of the disagreement. No one thinks it's ok to  
make tables that are difficult for blind users to understand, without  
providing some form of additional info. The question is how to provide  
that info, and whether it should be available to everyone.

Does that clarify? Note, I'm not saying the Accessibility design  
principle demands that we remove the summary attribute. But I think it  
requires us to consider the problem in a general way that applies to  
all users, before settling on particular solutions.

>
>
>> If there is a specific reason that a feature only for non-visual  
>> media
>> would be more effective than a feature for all media, perhaps because
>> trying to be fully general hurts the non-visual case, then it might  
>> be
>> appropriate to have a feature for non-visual users only.
>
> There is a very specific use case for non-visual users that @summary  
> serves.
> When a screen-reader user navigates in table mode (at least in  
> JAWS), the
> user can hear the summary of each table in a document with one  
> keypress.
> This is an affordance equivalent to the visual user scanning the  
> document
> for navigation. Without it, those users need to enter a table and  
> progress
> linearly, cell by cell, until they determine whether the content of  
> that
> table is relevant to them or not. It's a very time-consuming process  
> for
> documents with lots of tables.
>
> It would be simple to provide comparable functionality to sighted  
> users, but
> they don't experience anything near the same obstacles that screen- 
> reader
> users do.
>
> Could this be done in a way that aids universal design? Sure: you  
> could
> present a UI component to users that mimics the feature that's so  
> useful to
> screen-reader users. The iCab browser did similar things with  
> accesskey, for
> example. Anyway, after 11 years of HTML 4.01, no user has found it  
> valuable
> enough to even extend a browser to offer that functionality to sighted
> users, much less add a +1 to making @summary available to them.

That's an interesting idea, as is the proposal to display "summary" as  
a tooltip.

> It's all well and good that HTML5 has design principles. But it's
> indefensible to claim accessibility as one of them, and then make (or
> defend) a design decision that _reduces_ accessibility to people with
> disabilities on the premise that able-bodied users are being left  
> behind.
> It's a red herring.

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.

I also note that you're pretty close to saying that those who  
disagrees with your technical position here are against accessibility.  
I think that is unfair and unhelpful. Pretty much everyone here wants  
to improve accessibility and is proposing solutions that they think  
will best promote it.

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.

Regards,
Maciej

Received on Thursday, 26 February 2009 21:48:58 UTC