- From: Wilco Fiers <w.fiers@accessibility.nl>
- Date: Wed, 23 Apr 2014 15:59:17 +0200
- To: WCAG <w3c-wai-gl@w3.org>
Hi David, A few weeks back a similar issue with SCR21 was discussed during the WG call. As a result the following page was added to the open issues page on the wiki: www.w3.org/WAI/GL/wiki/WCAG_Techniques_for_dynamic_content It proposes a way forward with this technique that is more in line with the current way web developers and screen readers address this issue. Perhaps this is useful in this discussion. Regards, Wilco Fiers Accessibility Foundation ________________________________________ Van: David MacDonald [david100@sympatico.ca] Verzonden: woensdag 23 april 2014 14:10 Aan: WCAG Onderwerp: Action item complete re SCR 21 I had an action item to get back to my contact in the Canadian Government about SCR21 and their questions with it. From the response, it appears that SCR21 is perceived as an anti-technique rather than a technique ... it is perceived as instruction what NOT to do. At CSUN the folks a Freedom Scientific said JAWS no longer takes a static snapshot of the page to work off of, but rather continually to query the DOM for changes. I think VO and NVDA do the same. Here is the contact in the Canadian Government's response below: ==== start of response==== The main issue was with the technique telling what DOM manipulation JavaScript methods not to use when there is no evidence that there is any impact on accessibility or any negative impact to the DOM when using those methods (although supposedly document.write can be a bit flaky). The only justification for the technique that is given is they are not part of the DOM spec and that one of them won't work in XHTML with the application/xhtml+xml MIME type. Hardly any justification for this being one of the WCAG 2.0 sufficient techniques, much less discouraging the use of those methods. The use is widespread, in particular innerHTML because of longtime and widespread browser support. Pretty much every JavaScript framework on the planet will fail this technique, as will most JavaScript-enabled sites. Both innertHTML and outerHTML are supported across the board (Firefox started supporting outerHTML in version 11). As for innerText, support is not that great and neither is the performance. The textContent property is much better but IE didn't add support until IE9. As for outerText, I think it is IE only but there isn't much point with the other options (just a shortcut for replacing the current element node with a text node). So to sum up, there is no point in this technique being part of WCAG 2.0. It discourages common and harmless coding practices with out any justification or basis. Ideally this technique would be dropped. If it needs to be kept because of issues caused by document.write, then just limit it to that (but there better be a very good accessibility-related justification given). As for being on GitHub, I'm glad you guys ended up there. I'm encouraging people to go that route to share their feedback rather than the other approach. ==== end of response==== Cheers, David MacDonald CanAdapt Solutions Inc. Tel: 613.235.4902 LinkedIn<http://www.linkedin.com/in/davidmacdonald100> www.Can-Adapt.com<http://www.Can-Adapt.com> Adapting the web to all users Including those with disabilities If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>
Received on Wednesday, 23 April 2014 13:59:51 UTC