Re: Head in the sand, driving a car

Michael,

Is there a "lists of techniques that work on certain setups or that you 
should avoid"?

I'm always looking for examples, and whilst I realise that this is 
problematical, it would be great to see something more specific to a 
particular example such as right clicking, after all this is a 
relatively minor problem compared with say popups. In fact people with 
severe learning difficulties are quite a useful group, because a small 
selection will inherently include a broad spectrum of needs, and unless 
proposed solutions really work they are unlikely to be adopted. back to 
the example in hand :

How can a novice computer user, who is independently learning to use a 
mouse with great difficulty, disable right clicking using the OS?

Assuming it is possible, then we would need to show the user how to do 
it, assuming that the user has the cognitive ability, which in fact 
they don't in this instance. This is similar to insisting that the 
driver has to learn how an engine works before driving. Usually any 
instructor creates environments suited to individual needs and 
abilities to motivate and encourage progression. If the instructor is 
not present then this must be possible via the browser, unless you 
allow direct access to the OS which is frequently considered 
undesirable. In this instance javascript provides a great solution. 
Perhaps John or Chaals could provide a written description of how they 
believe an accessible version should behave.

Alternatively one could argue that these training materials should be 
provided with the application.
It seems there is some fundamental misunderstanding here, work-arounds 
are essential in all walks of life.


On Thursday, June 5, 2003, at 03:44  pm, Michael Cooper wrote:

> Just so you know what the techniques group is up to, we are indeed 
> thinking
> of issues around browser support. For techniques that are only 
> supported in
> certain user agents, or that go awry in certain user agents, that
> information will be stored with the technique. It should be possible 
> to pull
> up lists of techniques that work on certain setups or that you should 
> avoid.
> We've also identified a potential need to create techniques that are
> specifically workarounds for user agent problems. How we'll do that 
> exactly
> is not yet determined and it could be an endless task, so we'll 
> probably
> narrow it down by restricting it to moderately recent versions of
> technologies, but hopefully that addresses the issue you're raising. 
> As far
> as architectural materials go, that is likely to be minimized in the
> techniques themselves, but we will explicitly link to relevant 
> resources. So
> the information should be available in context even though it's not 
> part of
> the substance of the techniques themselves.
>
> Michael
>
>> -----Original Message-----
>> From: Charles McCathieNevile [mailto:charles@sidar.org]
>> Sent: Tuesday, June 03, 2003 9:23 PM
>> To: Jonathan Chetwynd
>> Cc: w3c-wai-ig@w3.org
>> Subject: Re: Head in the sand, driving a car
>>
>>
>> I actually think it would be valuable to have a discussion in
>> the WCAG
>> techniques about ways to work around things the technology
>> does badly.
>> That should include workarounds even if they are only useful in some
>> cases (like Flash being able to work on one platform with a couple of
>> screen readers, but not necessarily being accessible in general).
>>
>> That information should also include, as a matter of course,
>> discussion
>> of the relevant architectural principles for the web. If there is a
>> workaround that lets some people move forward now, but will hold back
>> the development of the web as a whole (text alternatives as a single
>> attribute, or default text in form fields, for example) in
>> the future,
>> then that should be noted and people should be warned about the fact
>> that at some point they should expect to remove a work-around because
>> the manufacturers have tuned their software better...
>>
>

Received on Thursday, 5 June 2003 15:33:50 UTC