- From: Alistair Garrison <alistair.j.garrison@gmail.com>
- Date: Tue, 3 Dec 2013 17:51:28 +0000
- To: Shadi Abou-Zahra <shadi@w3.org>, Eval TF <public-wai-evaltf@w3.org>
Hi Shadi, I think it definitely needs to be clarified - but I don't know if the methodology is now the right place. I fully agree with regard to web applications which heavily use and rely on JavaScript APIs, as there is simply no other way of doing things. My concern, relates only to the more simple informational pages - which have seemingly become bloated with unnecessary JavaScript over the years. What if people claim that a web page relies on JavaScript (as an easier option - see below) - when in fact the page could simply have been built better e.g. using HIJAX in place of AJAX, or CSS3 instead of JavaScript, etc… The methodology as written so-far does not pick this situation up… and, it is a situation which could impact many (and feels like a return to the "get a new browser" era). If we suggested a baseline in the methodology which included a "no JavaScript support" situation, we might prevent this from happening… but, as I say it might not be the best place… It may be better to tackle this situation in the guidelines themselves. The guidelines tackle the opposite situation, but not this one. Currently, if you say that JavaScript is not relied upon you have to show that JavaScript does not interfere in all future states… The only problem here is that it actually makes specifying JavaScript as "relied upon" the far easier option from the start… Anyway… we can come back to this at a late date. All the best Alistair On 3 Dec 2013, at 16:53, Shadi Abou-Zahra wrote: > Hi Alistair, > > Glad to hear that you are open to discuss this topic after the next publication as a working draft. We can come back to it. > > For now, I think a lot of this is inherent to the WCAG 2.0 concept of accessibility support. There are particular conditions under which you can consider certain technologies to be relied upon. Once they are deemed as relied upon, AFAIK there is no obligation to test in other environments that do not support these technologies. > > Do you mean we should better clarify this implication of WCAG 2.0? > > Best, > Shadi > > > On 3.12.2013 17:31, Alistair Garrison wrote: >> Hi Shadi, >> >> I would say almost. True, we tell people to select a baseline - but we do not specify "how" to properly select a baseline. We also don't say take into account the target browser / browser capabilities defined by the web developers… >> >> Exactly, what browsers / browser capabilities should be in the baseline? >> >> From 1c "During this step a list of web browsers, assistive technologies, and other user agents that support the accessibility features on the website is defined." >> >> If the page contains JavaScript, do we only test with JavaScript enabled browsers and AT which has JavaScript support? The sentence does not ensure that the page is checked in less supportive environments as well - e.g. a mobile browser with JavaScript disabled by user to save battery life. >> >> And, this opens a broader discussion - if a claim includes the following "The technologies that this content "relies upon" is: XHTML 1.0 Transitional, CSS 2.0 and JavaScript 1.2" - what about the users who do not have this level of support enabled? >> >> To my mind, there is room for a little more discussion / clarity in the reach of 1c - but, of course, at a later date. >> >> All the best >> >> Alistair >> >> On 3 Dec 2013, at 15:43, Shadi Abou-Zahra wrote: >> >>> Hi Alistair, >>> >>> Is this sufficient "Step 1.c: Define an Accessibility Support Baseline"? >>> - http://www.w3.org/WAI/ER/conformance/ED-methodology-20131129#step1c >>> >>> Best, >>> Shadi >>> >>> >>> On 3.12.2013 14:53, Alistair Garrison wrote: >>>> Dear All, >>>> >>>> The situation - evaluating web pages which use feature detection (for example Modernizr) or conditional comments to change the DOM content presented to the user. >>>> >>>> When evaluating such web pages I personally think it prudent to ask the developer which browser / device combinations they were targeting so that the DOM content in each combination could be checked - as the content will, and is designed to, change. With responsive design it is seemingly becoming more and more prevalent, but I don't think we cover it in our document. >>>> >>>> Suggestion - We should include a section in the document which specifies additional actions which the evaluator might consider if they meet this situation. For example, asking the developer which browser / device combinations they were targeting so that the combinations could be checked. >>>> >>>> In addition, for such pages which are often the more complex (JavaScript heavy) should we not define a default baseline for what browsers / browser capabilities we should be checking with? >>>> >>>> Thoughts / comments? >>>> >>>> All the best >>>> >>>> Alistair >>>> >>> >>> -- >>> Shadi Abou-Zahra - http://www.w3.org/People/shadi/ >>> Activity Lead, W3C/WAI International Program Office >>> Evaluation and Repair Tools Working Group (ERT WG) >>> Research and Development Working Group (RDWG) >> >> > > -- > Shadi Abou-Zahra - http://www.w3.org/People/shadi/ > Activity Lead, W3C/WAI International Program Office > Evaluation and Repair Tools Working Group (ERT WG) > Research and Development Working Group (RDWG)
Received on Tuesday, 3 December 2013 17:52:00 UTC