W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2000

Re: Accessibility default settings ...

From: Jan Richards <jan.richards@utoronto.ca>
Date: Wed, 17 May 2000 10:22:38 -0400
Message-ID: <3922AB2E.85A23241@utoronto.ca>
To: w3c-wai-au@w3.org
In general, I do not think that the conformance of a tool should not be
conditional upon the default settings of the accessibility options.

However, I believe that in the context of our guidelines and our goal of
reducing the production of inaccessible pages on the Web,
configurability should refer to the scheduling and intrusiveness of the
accessibility features rather than an ability to turn the whole system
on or off.

I agree with Phill that we should not be talking about turning all the
accessibility features off.  If accessibility features are disabled by
default or may be completely disabled later on, it is a fairly good bet
that they won't be turned back on.  Therefore, I would argue that some
accessibility indicators should remain, even once the settings have been
set to their lowest level. If these indicators were instructional, but
inobtrusive, and allowed an easy method for enabling more accessibility
features, then the tool should comply.

At minimum, I think authors should be notified at "save" by an alerting
message (such as the one I sent out last week) that they are saving out
an inaccessible page and that the tool they are using has (currently
disabled) features to help them prevent that.

Jan Richards
Access Software Designer
Adaptive Technology Resource Centre
University of Toronto
(416) 946-7060

janrichards@yahoo.co.uk (when travelling)

pjenkins@us.ibm.com wrote:
> William:
> >THE VARIOUS ACCESSIBILITY FEATURES * does not affect the conformance
> >level of the tool. That is my understanding.
> Heather:
> >if the majority of the Authoring Tools working group feels
> >that the answer to the above question is "yes", then I will agree that
> >authoring tools came comply with guideline 3.1 as currently defined, but
> >will submit a request to include this example within the techniques
> >document.
> Why do you want to document a technique that says it is O.K. to have the
> default setting off?  I would support putting the "discussion" in a
> "compliance" section in the document to reach consensus, but I would not
> want to encourage tool developers to set accessibility prompting default to
> off.  I believe that the guidelines do a good job of pointing the
> developers to "Support the creation of", "Provide ways of", "Integrate into
> the overall "look and feel", and "Promote in help and documentation". So I
> am back to the definition of prompt.
> Prompt: requests a response from the user.
> Prompting is required by the fact that there is a guideline and
> checkpoints, but the guideline and checkpoints wording do NOT require that
> a prompt must always appear regardless of the path the author takes when
> using the tool. I believe it is worse to explicitly define the term to
> require prompts in each or any path and document the option to configure it
> off by default than to allow the so called "loop-hole".  Again, W3C
> recommendations, as with most standards, are to leave room for
> implementation differences upon which tool manufactures may compete.
> So I don't have a problem with the current definition of PROMPT [ref 1] in
> the Guidelines, nor with any of the text in guideline 3 [ref 2], and I've
> realized that I forgot why we want to change either ... I do NOT.
> Regards,
> Phill Jenkins, IBM
Received on Wednesday, 17 May 2000 10:23:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:44 UTC