- From: John Foliot <jfoliot@stanford.edu>
- Date: Tue, 1 Dec 2009 18:32:54 -0800 (PST)
- To: "'Ian Hickson'" <ian@hixie.ch>
- Cc: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Ian Hickson wrote: > > > To clarify, you are arguing that explaining complicated information to > users who have trouble understanding complicated information will lead > to > them understanding the information _less_ than if that information was > not > explained to them? What I am saying is that the textual content that would go into the @summary value is *generally* seen as content targeted towards a specific user group - those that cannot see the complex associations inside of a complicated table, as they cannot process that information as a whole: screen readers must process the content inside of tables in a predominantly linear fashion. However, users with cognitive difficulties comprehend better when the information being presented to them is clear, simple and unencumbered by a lot of supporting 'distraction'. <supporting data> "Causes of distraction... are many including boredom, task demands, mental health issues, new technologies and most importantly BAD DESIGN." (my emphasis) http://newvaluestreams.com/wordpress/?p=908#more-908 "Distractions: Most developers are aware that people with certain cognitive or learning disabilities can be easily distracted. The usual suspects - ads, flashing images, very bright colors, high contrast, etc. are readily apparent. The more difficult distractions to avoid are those that are also learning aids. Lesson learned: Keep visual aids clean." http://webaim.org/projects/steppingstones/cognitiveresearch#distractions "The primary focus for designers producing any material for those with cognitive disabilities, whether it be new computer aided instruction, assistive technologies, or the World Wide Web should be to: --> * Avoid clutter <-- * Create modifiable software * Provide software with useful, informative, and frequent feedback * Provide multiple methods for access Developers might also want to consider the following suggestions made by Singh, Gedeon, and Rho (1998). They suggest that designers should: * _Remove the need for reading_ and writing skills in web exploration through graphic representations and point and click interfaces. * Reduce information overload, by simplifying text or providing options for abbreviated content." http://otal.umd.edu/UUGuide/erica/ </supporting data> One need not look any further than Google's home page to see this 'simplicity works' design perspective - why else would the Google designers *not* have an in-the-clear label for the search field? According to your assertions, this is what accessibility aware designers/developers should be doing, right? Should we presume then that the Google designers are *deliberately* creating a page design that discriminates against disabled users? That's a pretty big one to swallow... (and I for one don't buy it, however...) It comes down to two perspectives: Universal Design versus Accommodation features. In a perfect world, Universal Design would solve all problems, as the Design would be, well, Universal. However, when Universal Design fails is there another way forward? The answer is via Accommodation features. @summary is one such Accommodation feature - it exists when other 'solutions' are either not viable or wanted, for whatever reason. Matt May and Cynthia Shelly are two senior developers who have specifically noted in the context of *this thread* that they have experienced, first hand, the tug and pull of Accessibility Requirements versus other Business and Aesthetic considerations, and they, like I, have experienced more than once the defeat of Accessibility enhancements (or even basic needs) to the Trump Card of other voices at the decision table. Having solutions such as @summary in the developer's toolbox provides an additional option when options are required - it allows for a compromise solution that you have not offered in any other way. JF
Received on Wednesday, 2 December 2009 02:33:28 UTC