RE: Proposal for 4.2, Ensure that user interfaces are accessible

Joe Clark wrote:
<blockquote>
Well, that rules out Lynx for anything that relies ineluctably on 
JavaScript.
</blockquote>
Might be better to put it the other way around: if the developer has to
support the minimum baseline, which requires that content work when
scripting is not supported or is turned off, then the developer has to
provide options that work in that context.

If the developer is "free" to write to a baseline assumption that
scripting is supported and enabled, then the scripts must be accessible.

In other words, if the developer has to assume that his intended
audience includes Lynx users, then the developer has to provide content
that works without rcourse to scripting.


"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Joe Clark
Sent: Wednesday, April 27, 2005 12:19 pm
To: WAI-GL
Subject: Re: Proposal for 4.2, Ensure that user interfaces are
accessible



> [1] Definition of baseline:
> <proposal>
> The minimum set of technologies that must be supported by user agents

so that people can use and gain access to all the information and 
functions of the Web content.


> Developers must ensure that all information and functionality 
> comprising the Web content conforms to WCAG;

developers may assume that user agents

> support only this minimum set of technologies. Developers may also 
> choose to use technologies that are not in the minimum set provided 
> that the following are true:
>
>     The Web content is still accessible using user agents that only 
> support the technologies that are in the minimum set (i.e. the use of 
> technologies that are not in the minimum set does not "break" access 
> to the Web content by user agents that don't support them).

Well, that rules out Lynx for anything that relies ineluctably on 
JavaScript.

> [2] Definition of technology
> <proposal>
> "Technology" means a data format, programming or markup language, 
> protocol or
> API.

I think this would be clearer as:

"Technology" means a data format; a programming or markup language; a 
protocol; or an applications programming interface (API).


>
> 4. WCAG 2.0 conformance at level Triple-A means that all level 1, 
> level 2 and level 3 success criteria for all guidelines are met 
> assuming user agent support for only the baseline technologies.

There won't be a Level 3.

> [4] Reading order
> <proposal>
> Promote the following success criteria of GL 2.4 to level 1:
>     * When content is arranged in a sequence that affects its meaning,

> that sequence can be determined programmatically.

The Working Group needs to heed my advice on floated layouts and other 
layouts created by CSS. This isn't a trivial matter.

Valid, semantic HTML takes care of that problem for the most part, but
not 
always.

>     * When a page or other delivery unit is navigated sequentially, 
> elements receive focus in an order that follows relationships and 
> sequences in the content

That seems to be nothing but a user-agent issue. We can't expect authors

to put tabindexes on everything they ever write forevermore; among many 
other issues, tabindex applies only to a few elements.

> [5] authoring applications (part of conformance?)
> <proposal>
> Web applications that are created for the sole purpose of assisting 
> users to create content intended for publication on the web must 
> conform to at least Level A of the ATAG 2.0 Guidelines.

Sole purpose or primary purpose?

This is pretty good, though. Do we want to say "Web applications or 
interfaces"?

> [6] New GL 1.3 Level 1 SC
> <proposal>
> The role, state and value of every element of the web content can be 
> programmatically determined. Elements whose states and values can be 
> changed via the user interface can also be changed programmatically.

Well, I don't get this. You mean everything I style with :hover has to
be 
undoable by something else? And what is that something else? Is it not
the 
same thing that is rendering the :hover behaviour-- the browser?

Why is this not an issue of user stylesheets, dead-end though those are?

--

     Accessibility <http://joeclark.org/access/>
       --This.
       --What's wrong with top-posting?

Received on Wednesday, 27 April 2005 18:17:12 UTC