- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 25 Feb 2009 10:26:24 -0800
- To: David Poehlman <poehlman1@comcast.net>
- Cc: 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-liaison@w3.org, janina@rednote.net, Dan Connolly <connolly@w3.org>, Matt Morgan-May <mattmay@adobe.com>, Julian Reschke <julian.reschke@gmx.de>, W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>
On Feb 25, 2009, at 9:23 AM, David Poehlman wrote: > Maciej, > > This is something with which I agree but what I was wondering about > is something quite narrow in scope. I take it for granted that folk > wouldn't be doing this work if they were not interested and am not > fluent in many languages but am aware that they are out there and > that others are fluent in languages both singly and multiply that I > am not. > > What actually mystifies me and I've been following every nuounce of > the conversation over a long span on several lists is that there has > not been shown to be anything satisfactorily demonstrated to replace > what can be and has been used as such an accessibility enhancing > attribute as @summary. Many alternatives to summary have been proposed. At least the following techniques have been suggested as ways to provide additional information about tables: 1) Use the table caption. 2) Use a separate piece of explanatory text above or below the table. 3) Use the title attribute on the caption. 4) Use a details element inside the caption. 5) Use a separate piece of explanatory text above or below the table, using media-specific CSS rules to hide it from visual users. 6) Variants of 4 and 5 using ARIA to associate the information with the table. You may not think that these have not been satisfactorily demonstrated to replace summary, but I think that is a debatable point, not a blindingly obvious truth. There has also been discussion about whether different techniques might be appropriate to different kinds of additional information: A) Descriptions of the table's data layout, making it easier to navigate the table. B) Conclusions that summarize the data in the table, so one could skip the table entirely if not interested in the details. C) Additional information not found in the table at all, but relating to its contents. D) Indications that this table is a layout table. I think there can be honest disagreement over whether summary is the best technique to convey some or all of these kinds of information. For example, it seems clear to me that (C) is information that should be presented to all users, even those not using assistive technologies; and cases could be made for (A) and (B) as well, depending on the context. (D) seems like information that would only be useful for non-visual rendering. Ian thinks we don't need any mechanism for (D) because layout tables are nonconforming. Some, for example Henri, strongly disagree and think we need to adapt to the de facto reality of layout tables. Perhaps there are other kinds of information that might be conveyed in the summary attribute and that are useful for use of tables with assistive technologies. It seems to me that we can have a lot of productive discussion about what kind of information needs to be conveyed, who might find it useful, and what markup best meets those goals. > I'm not saying that ideas are not welcomed or discouraged but that > there are some hard facts that need to be considered if we are ever > going to move toward striking @summary from need. I am all for consideration of hard facts. Regards, Maciej > > > > On Feb 25, 2009, at 12:02 PM, Maciej Stachowiak wrote: > > > Hi David, > > On Feb 25, 2009, at 7:24 AM, David Poehlman wrote: > >> in that event, it can be ignored, however, one does wonder why the >> resistance to something so obviously benefitial is so *strong*. > > I think the disagreement is over whether summary is, on the whole, > beneficial, and whether other approaches might be more beneficial to > all users. Your framing of the disagreement assumes the answer, and > makes it sound like those who disagree with your technical position > hate accessibility. Even though it is phrased more courteously than > Robert's statement, I don't think it's helpful to discussion. > > I don't have a strong opinion one way or another on summary. But it > seems that discussion of accessibility features often gets very > emotional and heated. I think nearly all of us in this group want to > see a Web that is accessible to everyone. What we sometimes disagree > on are the best means to achieve these goals. So let's try to think > like this: "Person X has a different idea of how to best achieve > universal access, how can I persuade them to my point of view? Or do > they perhaps have a good point?" instead of like this: "Why is > person X against accessibility?" That's the way we try to discuss > other technical issues, even though often equally important goals > are at stake. And that gives us the best chance of coming up with > good solutions. > > Regards, > Maciej > >> >> >> On Feb 25, 2009, at 9:20 AM, Sam Ruby wrote: >> >> Robert J Burns wrote: >>> I say malicious since the continued repetition of the fallacious >>> arguments seem directed at ensuring such information is not made >>> available to visually and cognitively disabled users. >> >> The above statement is neither productive nor acceptable. >> >> - Sam Ruby >> >> >> -- >> Jonnie Appleseed >> with his >> Hands-On Technolog(eye)s >> reducing technology's disabilities >> one byte at a time >> > > > > > -- > Jonnie Appleseed > with his > Hands-On Technolog(eye)s > reducing technology's disabilities > one byte at a time >
Received on Wednesday, 25 February 2009 18:27:08 UTC