Re: Checkpoint 3.3 Research

I put a lot of time reviewing research I did not find anything new in the
last set of links.
 I am also forwarding the reviews of research to the list. I know you have
all already seen it, but it can be hard to find. They are on the end of this
email   Hope it helps. Wendy also had a good link at
http://usability.gov/guidelines/content.html#two

The last version of my proposal which Jo has offered to rewrite and make
better in at

http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/0263.html

Old stuff at:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/0110.html
cmn continues on this thread:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/0118.html
ls again:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/0263.html
cmn on diff thread:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/0265.html


The research reviews



----- Original Message -----
From: Lisa Seeman
To: _W3C-WAI Web Content Access. Guidelines List
Sent: Monday, December 03, 2001 10:57 AM
Subject: Part 1 - Telecommunications Problems and Design Strategies for
People with Cognitive Disabilities


I have been looking at Telecommunications Problems and Design Strategies for
People with Cognitive
Disabilities:
Annotated Bibliography and Research Recommendations by Ellen Francik, Ph.D.

http://www.wid.org/archives/telecom/Telecom.pdf

I assume that many people will not download it (although I am sure that some
people will :) )

hear are some highlights:



I am splitting it into two emails this one is on checkpoints that are useful
for cognitive disabilities.

I have taken that I ones were most useful for our inclusion or that the
wording seemed better then what we have. Please take a look at the original,
there are many more. Also note. This is biased on hard research. These are
proven successful techniques.



and now to the main .... part 1:



provide a mode with minimum functionality. - Eliminate or hide what isn't
essential.

Provide self-paced training and consider an adaptivetrainer. Briefly, they
block certain errors, diagnose others, suggest effective responses, and fade
into the background as users' skills increase.

Use simple screen layouts or one thing at a time presentation.

Use prompts for procedures and support decisionmaking.

Avoid functions that require simultaneous actions to activate or operate.

 Use a two-step "select and confirm" to reduce accidental selections,
especially for critical functions.

 Structure tasks, cue sequences, and provide step-by-step instructions.

 Provide definite feedback cues: visual, audio, and/or tactile.

 Provide concrete rather than abstract indicators. Use absolute reference
controls rather than relative ones.

 Use goal/action structure for menu prompts.

 Support "wizards" which offer help, simplify configuration, and assist with
sequences.

 Automate complex sequences like system backup, application launch, and user
registration.

 Provide defaults and make it easy to re-establish them.

Provide calculation assistance, or reduce the need to calculate.

 Provide a Web site map plus path information to the current page.

 Structure text for easy scanning; provide headings. Use sequential numbers
for numbered menus or lists.

 Keep language as simple as possible. Highlight key information.

 Use highly descriptive words as hypertext anchors. Avoid the "click here"
syndrome.

 Search engines should support spell check.

 Searches should support query by example and similarity search.

"use goal/action structure for menu prompts,"

 Users should be able to use word prediction and grammar and spell checkers
in conjunction with all text entry.



Next email.....



More highlights from Telecommunications Problems and Design Strategies for
People with Cognitive
Disabilities:
Annotated Bibliography and Research Recommendations by Ellen Francik, Ph.D.

http://www.wid.org/archives/telecom/Telecom.pdf

In this email are points that practically interest me, in view of recent
discussions.

formatting in mine and anything in a <Lisa comment>.

And now to the main .... part 2:



<Lisa comment>I find this a "holistic" approach to accessibility, It may be
better then checkpoints.... </Lisa comment>

" First, assay individual differences. Find out which ones correlate with
performance on the chosen task. Many plausible factors may
be irrelevant. Egan and Gomez found that only age and spatial memory
mattered for the text editors they studied; education,

typing speed, verbal aptitude, job experience, associative memory, and
logical reasoning had no effect on performance.

Second, isolate task components. Do a task analysis and determine which
components individual differences affect. This is admittedly

an art. Egan and Gomez verified their analysis by creating new tasks with
the same components and obtaining the same pattern of

correlations, but this additional test is impractical for design teams.

Third, accommodate the differences by redesigning the interface to minimize
performance differences. Measure user performance

again. Egan and Gomez compared a line editor to a newer display editor. The
newer design simplified command syntax, reducing age

differences in performance, but the changes related to spatial memory
ability were mixed (and cancelled each other out).


<Lisa comment> This one is a list of steps to achieve the above</Lisa
comment>

<Lisa comment> identify:</Lisa comment>
  a..  Distinct groups of people with cognitive disabilities.
  b..  Real-world tasks or functions with which these various user groups
have difficulty.
  c..  Underlying cognitive factors creating those difficulties.
  d..  Specific design changes that compensate for the cognitive deficits
and improve task performance.



<Lisa comment> This I think is an interesting quote, and could be adopted or
at least remembered by our group</Lisa comment>
The EITAAC report (1999) is notable for two things. First, it

contains some technology-specific standards and implementation

details. Second, it sets an accessibility goal. A person with a

disability should be able to "perform the same tasks, access the

same information, with the same approximate ease and in the same

approximate time and at the same cost" as someone without a

disability



<Lisa comment> for the discussion on checkpoints and conformance</Lisa
comment>



some of the strategies are a matter of degree. Without some

form of user testing or human performance modeling, a designer

would not know to what extent people with cognitive disabilities

actually benefit from overly generalized suggestions such as: "use

simple screen layouts," "keep language as simple as possible,"

"reduce the number of choices."



Re-use familiar, well-learned organizational schemes.

In fact, a designer might use several strategies, even measurable

ones, yet miss the combination that makes the product accessible

to people with particular cognitive disabilities. Verifying accessibility

depends on knowing the characteristics of distinct user groups, and
assessing their performance with the complete product.




----- Original Message -----
From: "Jo Miller" <jomiller@bendingline.com>
To: "Kynn Bartlett" <kynn-edapta@idyllmtn.com>
Cc: "Lee Roberts" <leeroberts@roserockdesign.com>; "WCAG List"
<w3c-wai-gl@w3.org>
Sent: Saturday, February 09, 2002 5:00 PM
Subject: Re: Checkpoint 3.3 Research


> The proposal for 3.3 is being reworked following last week's telecon.
>
> Since 3.3 aims to address, among other things, barriers that might prevent
> people with disabilities from comprehending and using web content, it
> would be especially helpful to have input from people with expertise in
> cognitive disabilities that affect reading comprehension.
>
> We have a wealth of current material on general usability, rules of
> composition, and best practices in web writing (thanks, Lee, for
> your most recent contributions!). But I, for one, am far less familiar
> with research on cognitive disabilities. If someone with knowledge of that
> area of research  would like to summarize the conclusions that are most
> relevant for 3.3, it would help us as we work on the next draft of that
> checkpoint.
>
> I also like Kynn's suggestion and would be interested to hear the online
> writers' thoughts on 3.3.
>
> Jo
>
> On Sat, 9 Feb 2002, Kynn Bartlett wrote:
>
> > I was thinking about running whatever draft proposal we have for
> > checkpoint 3.3 (guidelines, techniques, etc.) past the
> > online-writing mailing list; these are primarily content authors
> > and not markup/techie people necessarily, so it would be helpful to
> > get their advice.
> >
> > What is the current proposal?
> >
> > --Kynn
> >
> > --
> > Kynn Bartlett <kynn@idyllmtn.com>                 http://kynn.com
> > Chief Technologist, Idyll Mountain            http://idyllmtn.com
> > Web Accessibility Expert-for-hire          http://kynn.com/resume
> > Next Book: Teach Yourself CSS in 24       http://cssin24hours.com
> >
> >
>
>
>

Received on Monday, 11 February 2002 02:23:37 UTC