W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2002

RE: Reconsidering the wording of our main guidelines

From: <goliver@accease.com>
Date: Fri, 01 Mar 2002 18:17:52 -0800 (PST)
To: charles@w3.org
Cc: gian@stanleymilford.com.au, paulb@cpd2.usu.edu, w3c-wai-gl@w3.org
Message-Id: <20020301181755.4316.c000-h014.c000.wm@mail.accease.com.criticalpath.net>
Hi Paul
Yes I really like this too (you've got the Australasian
contingent happy anyway!)
One suggestion

Alter
2.0 ALLOW FOR USER NEEDS AND PREFERENCES

to

2.0 ALLOW FOR USER NEEDS, ABILITIES AND PREFERENCES

My reasoning was set out in [1]

To summarise I think that it is easy for non-disabled
people to focus on what disabled people cannot do
rather on what they can do.
The inclusion of 'abilities' is meant to address this a
bit.

Great Job, thanks

http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/0900.html

Cheers
Graham

Charles McCathieNevile wrote

> 
> I like this too.
> 
> One of the things that I would suggest is that we
reinforce the ideas that:
> 
> 1. Order of checkpoints is not significant
> 2. We care about all kinds of accessibility
> 
> And I would suggest we do it by changing the order. I
think there is a
> general perception that WCAG 1 didn't provide a lot
of support for things
> which are clearly crucial to the accessibility, as
well as the general
> success, of a site - clear writing, usable navigation
structures,
> illustration, etc.
> 
> If we start with the things that designers realise
they are trying to do -
> communicate clearly - we get to point out that these
things are not strange
> requirements but normal parts of what people expect.
We should be clear in
> the introduction that some things are of this nature
- things we expect
> designers to be somewhat familiar with - and other
things are more technical
> requirements to make things work with specific
technologies.
> 
> I would also move the old 1.3 and 1.5 (3.2 and 3.3 in
Paul's proposal) into
> section 2, since they are about providing for user
preferences (by providing
> support for users to reconfigure as far as they want
and are able).
> 
> just my 2c worth
> 
> cheers
> 
> Chaals
> 
> On Fri, 1 Mar 2002 gian@stanleymilford.com.au wrote:
> 
>   This seems like a good idea.
>    
>      -----Original Message-----
>      From: paulb [mailto:paulb@cpd2.usu.edu]
>          
> 
>         1.0 MAKE THE CONTENT AVAILABLE to a broad
range of users and
>         technologies.
> 
>         1.1             Provide a text equivalent for
all non-text
>         content.
> 
>         1.2             Provide synchronized media
equivalents for
>         time-dependent presentations.
> 
>         1.3             *Identify the primary natural
language of text and
>         text equivalents and all changes in natural
language (previously
>         1.4).
> 
>         1.4             * Choose technologies that
support the use of
>         these guidelines (previously 4.1).
> 
>         1.5             * Use technologies according
to
>         specification(previously  4.2).
> 
>         1.6             * Design user interfaces
compatible with assistive
>         technology(previously  4.3) .
> 
>         1.7             * Use device-independent
event handlers
>         (previously 2.5).
> 
>         1.8             * Ensure that content remains
usable when
>         technologies that modify default user agent
processing or behavior
>         are turned off or not supported 
(previously  4.4)  .
> 
> 
> 
>          
> 
>         2.0 ALLOW FOR USER NEEDS AND PREFERENCES.
> 
>         2.1             Provide multiple site
navigation mechanisms.
> 
>         2.2             Provide consistent and
predictable responses to
>         user actions.
> 
>         2.3             Either give users control of
mechanisms that cause
>         extreme changes in context or warn them of
pending changes.
> 
>         2.4             Either give users control
over how long they can
>         interact with content that requires a timed
response or give them
>         as much time as possible.
> 
>         2.5             *Avoid causing the screen to
flicker (previously
>         2.6).
> 
>         2.6             *Handle input errors, such as
misspellings
>         (previously 2.7).
> 
>          
> 
>         3.0 MAKE THE CONTENT COMPREHENSIBLE.
> 
>         3.1             Use consistent presentation.
> 
>         3.2             *Use markup or a data model
to provide the logical
>         structure of content (previously 1.3).
> 
>         3.3             *Separate content and
structure from presentation
>         (previously 1.5).
> 
>         3.4             *Emphasize structure through
presentation,
>         positioning, and labels (previously 3.2).
> 
>         3.5             *Write as clearly and simply
as is appropriate for
>         the content (previously 3.3).
> 
>         3.6             *Supplement text with
non-text content (previously
>         3.4).
> 
>         3.7             *Annotate complex,
abbreviated, or unfamiliar
>         information with summaries and definitions
(previously 3.5).
> 
> 
> 
>         Paul Bohman
>         Technology Coordinator
>         WebAIM (Web Accessibility in Mind)
>         www.webaim.org
>         Center for Persons with Disabilities
>         www.cpd.usu.edu
>         Utah State University
>         www.usu.edu
> 
> 
> 
> 
> 
> 
> -- 
> Charles McCathieNevile   
http://www.w3.org/People/Charles  phone: +61 409 134 136
> W3C Web Accessibility Initiative    
http://www.w3.org/WAI    fax: +1 617 258 5999
> Location: 21 Mitchell street FOOTSCRAY Vic 3011,
Australia
> (or W3C INRIA, Route des Lucioles, BP 93, 06902
Sophia Antipolis Cedex, France)

AccEase Ltd : Making on-line information accessible
Phone : +64 9 846 6995
Email : goliver@accease.com
Received on Friday, 1 March 2002 21:18:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:18 GMT