- From: David MacDonald <david100@sympatico.ca>
- Date: Tue, 26 Nov 2013 07:07:01 -0500
- To: <rcorominas@technosite.es>
- CC: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'WCAG WG'" <w3c-wai-gl@w3.org>, <kirsten@can-adapt.com>
>> 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:36 UTC