- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 26 Feb 2009 13:48:01 -0800
- To: Matt Morgan-May <mattmay@adobe.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>
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