W3C home > Mailing lists > Public > wai-xtech@w3.org > July 2007

Re: managing alternatives

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Mon, 16 Jul 2007 12:41:14 -0400
Message-Id: <p06110426c2c142cc8636@[10.0.1.2]>
To: wai-xtech@w3.org


I accidentally discovered a very important reference.  There is a 'feature
at risk' in WCAG2 conformance in this area:

<quote
cite="http://www.w3.org/TR/WCAG20/#conformance-reqs">

4.) Alternate Versions: If the Web page does not meet all of the 
success criteria for a specified level, then a mechanism to obtain an 
alternate version that meets all of the success criteria can ...

<snip/>

Requirement #4 is therefore "at risk" in its current form. If there 
are not sufficient techniques to meet the current language, it would 
have to change.

<snip/>

</quote>

At 7:33 PM +0100 14 07 2007, Gez Lemon wrote:
>Hi Al,
>
>On 14/07/07, Al Gilman <Alfred.S.Gilman@ieee.org> wrote:
>>One suggestion has been that we add an @equivalent attribute to the
>>WAI-ARIA vocabulary.
>
>An equivalent attribute sounds like a good idea. What data type would
>it accept? For something like a CAPTCHA, where there could be more
>than one alternative, it would need to be able to accept more than one
>value, with those options being exposed by the user agent.

Is such an attribute a good idea? let's look for pros and cons.

It's good to start with the operational requirement (there is a
mechanism that will get you what works for you) from WCAG and look at
different, including more short-term, ways of providing that.

One drawback of a multi-valued "equivalent" attribute is that the equivalent
relationship is symmetrical, so all of the individual things in the equivalent
set would have to list all the others in the set.  This is fragile code; many
if not most instances of this would contain inconsistent data.

An option is for anything that has a universal-access problem  to offer
a way to get to where you can choose among the options.  That there
be an options controller and the several options all connect back to
there with a "if you have trouble with me" voice-over.

The user needs to know going in that there are options.  Can't trust that
they won't give up when they encounter a brick wall.  Something that
comes later in the normal reading order that says  "Oh, there's a way
around this brick wall" does not count as making things friendly to all users.

>Could this also be implemented using content negotiation? People could
>configure their user agents to suggest the challenge most suitable for
>them, and the service could check the accept headers to choose the
>most appropriate version, and the author provides the option to allow
>the user to change the challenge at any time.

This would take some exploration.  You don't really want to shut down
the transmission of all images just so you get the CAPTCHA with an
audio prompt.

For one thing, you don't want the right answer to the visual and
audio challenges to be the same string,  for  security reasons.  It
just makes the attacker's job too easy.  So it's not a simple <object>
substitution.  You have to put an opaque key in the form reply that tells
the server what right answer to look for.

My rough take on this is that content negotiation is an idea the
market has rejected and it won't be back. Not until the mobile
version with more subtle user preferences in CC/PP is up and running.
The pieces of this technology are mostly in place.

User preferences:
http://ncam.wgbh.org/salt/

Selectable content responsive to preference metadata:
http://www.w3.org/2007/uwa/

Note: the predefined properties all deal with the characteristics of
mobile devices, but the architecture has been designed so that user
preferences can flow through it and could control content decisions,
too. At the moment that's in the "yet to be demonstrated" level of
maturity, as far as I know.

So it's not actually available to users enough to meet the WCAG sense
of 'widely supported' in their discussion of accessibility-supported
technologies

http://www.w3.org/TR/WCAG20/#cc5

My current expectation is that we should be looking for something
that is written out in a  scripted web page so as to work  in current
browsers as the near-term existence proof of feasible and sufficient
techniques.

Al

>Gez
>
>
>--
>_____________________________
>Supplement your vitamins
>http://juicystudio.com
Received on Monday, 16 July 2007 16:41:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:43 GMT