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

Re: summary="" in HTML5 ISSUE-32

From: Matt Morgan-May <mattmay@adobe.com>
Date: Thu, 26 Feb 2009 14:29:40 -0800
To: Maciej Stachowiak <mjs@apple.com>
CC: Dan Connolly <connolly@w3.org>, Jonas Sicking <jonas@sicking.cc>, David Poehlman <poehlman1@comcast.net>, Sam Ruby <rubys@intertwingly.net>, Robert J Burns <rob@robburns.com>, Ian Hickson <ian@hixie.ch>, "Gregory J. Rosmaita" <oedipus@hicom.net>, Leif Halvard Silli <lhs@malform.no>, James Graham <jgraham@opera.com>, Joshue O Connor <joshue.oconnor@cfit.ie>, Steve Axthelm <steveax@pobox.com>, Steven Faulkner <faulkner.steve@gmail.com>, Simon Pieters <simonp@opera.com>, HTMLWG <public-html@w3.org>, "wai-xtech@w3.org" <wai-xtech@w3.org>, "wai-liaison@w3.org" <wai-liaison@w3.org>, "janina@rednote.net" <janina@rednote.net>, Julian Reschke <julian.reschke@gmx.de>, W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>
Message-ID: <C5CC57D4.1930F%mattmay@adobe.com>
On 2/26/09 1:48 PM, "Maciej Stachowiak" <mjs@apple.com> wrote:
> 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?

If that's the case, then @alt would be an exception, no? It only appears in
auditory or low-bandwidth situations; not visually or in print. I don't see
a significant functional difference between @alt and @summary for non-visual
users, so I don't see a reason to treat them differently here.

> 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.

Two points:

1) Then @alt should also be presented visually, no? From the research I've
seen, there's more good @alt content than good @summary content, so it'd
make more sense to present that visually.

2) There is assistive technology for people with cognitive disabilities, as
well, and if the makers of those ATs saw a need to present @summary visually
(or aurally), they can do that (but not if it doesn't exist). This is a user
preference. Author proposes, user disposes. That's good design.

>> 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 also note that you're pretty close to saying that those who
> disagrees with your technical position here are against accessibility.

No, I'm really not. I don't see how my statement would be parsed that way.
I mean to point out a logical fallacy, to wit: removing a feature intended
for non-visual users somehow aids accessibility. It does not follow.

> 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.

My bias in favor of universal design is amply documented:


But a part of universal design is providing affordances so certain user
groups (say, mobile users) can still play along. Sometimes that information
(like a handheld style sheet) is hidden from other modes of interaction
because it's superfluous in those modes.

I think the divide we're dealing with here is more like this:

1) @summary is content that is restricted non-visual users, and our design
principles dictate that it should be available to all users.

2) @summary is alternate content for visual information, and our design
principles dictate that it should be presented to non-visual users.

I'm still a 2. I'm happier with it doing a lot of work for non-visual users
than I am with it kinda sorta maybe someday doing a little work for

> 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.

When @summary was removed, accessibility to non-visual users was reduced.
That's not an accusation meant to blame individuals, that's a statement of
fact. I'm happy that we're making some progress toward filling the hole that
was left behind, but the hole's still there.

Received on Thursday, 26 February 2009 22:31:17 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:44 UTC