W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1998

Re: visibility of features

From: Ian Jacobs <ij@w3.org>
Date: Sat, 31 Oct 1998 15:39:01 -0500
Message-ID: <363B7565.2D1D4A7D@w3.org>
To: Kitch Barnicle <kitch@afb.org>
CC: w3c-wai-ua@w3.org
Kitch Barnicle wrote:

Hi Kitch,
> Current Guideline - 7.1.1 Priority 2  Allow users to configure
> accessibility features easily and directly.
> I am afraid this is wording is too vague and I also wonder if it should be
> given a priority 1 rating. After all, if the user cannot configure the
> access features the application may be unusable. I also don't want to
> implicitly suggest that someone else would have to configure the
> application for a user with a disability. So here are some suggestions. As
> always, I am interested in your thoughts on the topic.

The above guideline was removed in the 30 October draft. Your
comments that follow will be integrated into the ntext draft.
> Suggestion - 7.1.1 Implement user agent all windows, menus, controls and
> toolbars using the general principles of accessible design.
> Users should be able to navigate to and interact with controls using
> multiple input and output methods.
> I suppose something like this should go in the "general principles of
> design" section but I want to make clear that not only to the features have
> to be there, but the features themselves have to be accessible.

> 7.1.2 Allow users to reach all configurable features that impact user agent
> accessibility
> via a single, prominent point of entry.???(Are there too many options for a
> single dialog?)
> Users should be able to discover and reach configurable options in a single
> location such as a menu, dialog box or a property sheet???

At the face-to-face meeting there seemed to be consensus that
there should not be a single point-of entry in the interface
(since accessibility should be integrated) but that all accessibility
features should be documented in a chapter dedicated to accessibility.
The 30 Oct draft reflects this.
> 7.1.3 Provide for quick access to key accessibility features.
>  Users should be able to use shortcuts or menu items to modify certain
> accessibility features.
> What I am trying to say is that users should be able to configure all the
> "access" features in a single location, but certain features such as
> loading and unloading images should be easily reachable from a menu and or
> short cut.  Does that make sense? Can someone say it better? I know that
> almost any feature can impact accessibility. Can we give any guidance on
> what features should be grouped together.

We need to discuss this further, I think.
> Next guideline - "Furnish predefined accessibility profiles for common
> disabilities"
> I'd like to suggest some new wording for this one. Hopefully I have
> interpreted the meaning correctly. It may already be changed in the new
> version but I'll comment anyway.
> Suggested replacement - Furnish predefined profiles of user agent feature
> settings applicable to users with common disabilities

> Sample profiles of features settings can assist users in the initial set up
> of the user agent. These profiles can serve as models and may be copied and
> fine-tuned to mean an individual's particular needs.

> Right now this guidelines also states "As much accessibility configuration
> as possible should be
> done through CSS, if the user agent supports CSS." This statement confuses
> me a bit. I almost think this should be separated from user agent features.
> Any thoughts?

Gone from the 30 October draft.

Thanks for the comments Kitch!

 - Ian

Ian Jacobs (jacobs@w3.org) 
Tel/Fax: (212) 684-1814 
Received on Saturday, 31 October 1998 15:38:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:21 UTC