RE: CHANGE PROPOSAL: Table Summary

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