- From: Ramón Corominas <rcorominas@technosite.es>
- Date: Tue, 26 Nov 2013 12:28:19 +0100
- To: david100@sympatico.ca
- CC: 'Steve Faulkner' <faulkner.steve@gmail.com>, 'Adrian Roselli' <Roselli@algonquinstudios.com>, 'Janina Sajka' <janina@rednote.net>, 'HTML Accessibility Task Force' <public-html-a11y@w3.org>, 'WCAG WG' <w3c-wai-gl@w3.org>, public-comments-wcag20@w3.org, 'Gregg Vanderheiden' <gv@trace.wisc.edu>, kirsten@can-adapt.com
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 11:29:35 UTC