RE: UNS: Re: WCAG considering amending F65 to NOT fail missing ALT text if title or aria-label is present

>> Conformance Requirement #1 teorethically allows a page to be completely
inaccessible but still conformant, provided that there is an alternate
version that can be reached through an "accessibility supported mechanism".
But it does not specify where this mechanism must be placed, so in theory it
could be the last link of the webpage, making it completely unusable by real
users with disabilities.

I think the key word you use here is "theoretically". The techniques
provided for a conforming alternative say " G136: Providing a link at the
*beginning* of a nonconforming Web page that points to a conforming
alternate version"... Goven the guidance provided on conforming alternatives
I doubt one could justify placing the button at the end of the content
http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conforming-alt
-versions-head , in practical experience, I've never seen this error, and
WCAG I believe must be as practical as possible. Accessibility support is
the most difficult concept in WCAG, and it is still a bit of the Wild West
in practice, but I cannot think of another way to address the diversity of
web technologies, without going back to the old "use only W3C technologies"
concept of WCAG 1, which I think is untenable.

Cheers,
David MacDonald

CanAdapt Solutions Inc.
Tel:  613.235.4902
http://ca.linkedin.com/in/davidmacdonald100 
www.Can-Adapt.com 
   
  Adapting the web to all users
            Including those with disabilities

This e-mail originates from CanAdapt Solutions Inc. Any distribution, use or
copying of this e-mail or the information it contains by other than the
intended recipient(s) is unauthorized. If you are not the intended
recipient, please notify me at the telephone number shown above or by return
e-mail and delete this communication and any copy immediately. Thank you.

Le présent courriel a été expédié par CanAdapt Solutions Inc. Toute
distribution, utilisation ou reproduction du courriel ou des renseignements
qui s'y trouvent par une personne autre que son destinataire prévu est
interdite. Si vous avez reçu le message par erreur, veuillez m'en aviser par
téléphone (au numéro précité) ou par courriel, puis supprimer sans délai la
version originale de la communication ainsi que toutes ses copies. Je vous
remercie de votre collaboration.


-----Original Message-----
From: Ramón Corominas [mailto:rcorominas@technosite.es] 
Sent: November 26, 2013 6:28 AM
To: david100@sympatico.ca
Cc: 'Steve Faulkner'; 'Adrian Roselli'; 'Janina Sajka'; 'HTML Accessibility
Task Force'; 'WCAG WG'; public-comments-wcag20@w3.org; 'Gregg Vanderheiden';
kirsten@can-adapt.com
Subject: Re: UNS: Re: WCAG considering amending F65 to NOT fail missing ALT
text if title or aria-label is present

David wrote:

> This statement actually demonstrates a lack of distinction between a 
> validation error and a WCAG error, which concerns me because if an 
> accessibility expert misses this distinction, which James Craig 
> pointed out in the first post on this issue, what can we expect from 
> Johnny lunch box developers?

Indeed, SC 4.1.1 itself mixes the two concepts. A page can hava duplicate
IDs and/or duplicate attributes and/or nesting errors according to the
specs, and still be completely accessible. Many parsing errors in the Real
World have no influence on accessibility, although of course badly
constructed code can sometimes have accessibility implications.


> WCAG techniques are all
> about what works today rather than what should work... and it’s always 
> been that way, because if the technique is not accessibility supported 
> today ... it will not work... the place for experimentation, and 
> innovation is not in WCAG techniques... WCAG is about what works today 
> for accessibility and this how we make “web content more accessible” 
> so naturally we will follow trends in our techniques.

This is another big debate that in my opinion is unsolved...

Almost all PDF techniques are only accessibility supported on Windows
platforms and using Adobe Reader, and there is no statement in the
techniques reflecting this behaviour. This is a real big issue for many
blind users that cannot properly access PDF documents if they are not using
Windows. Some of the Flash techniques just do not work as they are
described, and probably several other techniques have partial support
without mentioning it.

My experience with developers is that they read the sufficient techniques as
"working under all possible circumstances", since most of them have no
accurate information (or no information at all) about their accessibility
support, thus ignores Conformance Requirement #4.

On the other hand, some people read failures as "they always lead to failure
of conformance", ignoring that the failing content could be "not relied
upon", and therefore it could conform meeting Conformance Requirement #5.

Moreover, Conformance Requirement #1 teorethically allows a page to be
completely inaccessible but still conformant, provided that there is an
alternate version that can be reached through an "accessibility supported
mechanism". But it does not specify where this mechanism must be placed, so
in theory it could be the last link of the webpage, making it completely
unusable by real users with disabilities.

So in my view the accessibility support is so poorly documented in the
official WCAG documents that it leads to either too strict or too loose
interpretations, depending on who is affected by the issue. Developers tend
to read sufficient techniques as "always valid" and failures as "always
failing". Meamwhile, users will suffer the consequences of
not-always-sufficient techniques and simply ignore the not-always-failures.

Regards,
Ramón.

Received on Tuesday, 26 November 2013 12:07:34 UTC