- From: Sharron Rush <srush@knowbility.org>
- Date: Fri, 29 Mar 2013 18:32:46 -0500
- To: Denis Boudreau <info@denisboudreau.org>, "EOWG (E-mail)" <w3c-wai-eo@w3.org>
- Cc: Shadi Abou-Zahra <shadi@w3.org>
Hey Denis, I just added a few section to the wiki. I don't agree with all that you have suggested, but I do agree with much of it. And, I think the wiki is a good central spot to talk through it all (despite my initial horror of the interface) So, could you post (or would you mind if I moved your comments there)? I will be working on all of it more over the weekend. I am sorry to be so behind, Shadi, but have been playing catch up after the lovely spring conference season. I am out of breath but almost caught up :) Thanks all, Sharron At 12:42 PM 3/29/2013, Denis Boudreau wrote: >Dear EOWG, Shadi, > >Before I submit my comments for WCAG-EM, I thought I'd share them >with you all to see if/where I should send them. > >Some would definitely be better off sent to evalTF rather than >posted on our wiki - so I'd like you to help me figure out where >each of them better fits. > >==//================== > >Redundancy between the abstract, introduction and scope sections. > >A large part of the Abstract is repeated in the Introduction and >Scope section. Is this really intentional? I think documents like >these are already long enough, without some content being repeated. > >I am willing to document these repetitions if it's deemed relevant, >but decided against doing it at this time. > >==//================== > >Step 1.d: Define the Techniques and Failures to be Used (Optional) > >"However, it is not necessary to use these particular techniques. In >fact, in some situations, such as in a closed network, it may be >necessary to use techniques that are specifically developed to the >particular needs of the users of that network. Individuals and >organizations developing techniques have to employ methods for >establishing the technique's ability to meet the WCAG 2.0 Success Criteria." > >Wouldn't it be useful to provide one or two examples of this? So it >makes more sense to those reading this document? > >==//================== > >Step 2.b: Identify Common Functionality of the Website > >I keep reading the definition of "common functionality) and I'm just >not sure what it is we're talking about here. Are we talking about >main navigation, header, footers and so on? Specific features that >is used site wide? Wouldn't it be helpful to refer to "common >functionalities" as representative testing use cases for the >evaluation of the website? > >==//================== > >Step 3: Select a Representative Sample > >"While ideally every web page of a website is evaluated, usually >this is not possible on most websites. In cases where all web pages >can be evaluated, this sampling procedure can be skipped and the >selected sample is considered to be the entire website in the remaining steps." > >I know we mention it's usually not possible to evaluate all pages, >but if we can recognize that it's rarely possible, then why say >ideally it should be all pages? That creates unrealistic >expectations and a pressure most people do not need to deal with. I >feel this is wishful thinking - we need to be more realistic about >this. Most accessibility evaluation do not cover all pages and no >organization can ever afford to run a complete evaluation of all >their pages, except for very small sites (and even then, if they >have a small site, their accessibility budgets will tend to be >proportionally small). Instead of creating pressure on orgs to >consider this, why not focus on trying to get them to think about >selecting the best possible samples within reasonable scope, rather >than have them perceive this selection as a failure because they >can't afford to cover all pages? > >==//================== > >Step 3.d: Include Complete Processes > >"No web page in the selected sample may be part of a process without >all other web pages that are part of that process to be also >included into the selected sample." > >WCAG-EM is not a dogma or a law. We shouldn't impose anything, but >rather, guide people in the right direction. It might be better to >suggest them not to forget any page from a process, rather than >prohibit incomplete process samples. > >I feel something like this would be more appropriate: > >"No web page in the selected sample should be part of a process >without all other web pages that are part of that process to be also >included into the selected sample." > >==//================== > >Step 3.e: Include a Randomly Selected Sample > >5% seems a little low to me, even when the sample contains over 30 >to 50 pages total (WCAG-EM implies it should always be more than >this). I would suggest around 10-15% (where 50 pages would include >another 5-7 random pages to complete the sample). > >==//================== > >Step 4: Audit the Selected Sample (note1) > >We should suggest isolating template findings from the rest of the >findings related to main content of a page or pages, so >findings/issues related to templates can be referenced globally for >all related pages, rather than repeating the findings every time. By >doing this, once the template findings are covered, all subsequent >pages could only be covering the main content issues, making the >whole process simpler and more organized. > >==//================== > >Step 4: Audit the Selected Sample (note2) > >"Note: According to WCAG 2.0, Success Criteria to which there is no >matching content are deemed to have been satisfied. An outcome such >as 'Not Applicable' may be used to denote the particular situation >where Success Criteria were satisfied because no relevant content >was applicable." > >Maybe complete this note as follows: > >"Note: According to WCAG 2.0, Success Criteria to which there is no >matching content are deemed to have been satisfied. An outcome such >as 'Not Applicable' may be used to denote the particular situation >where Success Criteria were satisfied because no relevant content >was applicable. but WCAG 2.0 does not require this. A Success >Criteria that is either validated or not applicable, for whatever >reason, is considered satisfied." > >==//================== > >Step 4.b: Assess Accessibility Support for Features > >Small typo - including "sufficient technqiues" - s/technqiues/techniques. > >==//================== > >Step 5.a: Provide Documentation for Each Step > >Small typo - missing a capital W on the 7th bullet. s/web/Web. > >==//================== > >Step 5.b: Provide a Conformance Evaluation Statement (Optional) > >Shouldn't: > >"As per the requirements for WCAG 2.0 conformance claims, also >accessibility evaluation statements have to include the following >information:" > >Instead read: > >"As per the requirements for WCAG 2.0 conformance claims, >accessibility evaluation statements also have to include the >following information:" > >==//================== > >Step 5.b: Provide a Conformance Evaluation Statement (Optional) > >"Note: It is not possible to make an accessibility evaluation >statement for a website that is still in development." > >Again, WCAG-EM is not a dogma or a law. We shouldn't impose >anything. Rather than prohibit making an accessibility evaluation >statement for a website that is still under development, maybe it >would be better to suggest not to: > >"Note: An accessibility evaluation statement should not be made for >a website that is still in development." > >==//================== > >Re-Running a Website Conformance Evaluation > >I would like to suggest a proportion of 60%/40% between portion of >web pages that were in the original sample and additional new web >pages that were not in the original sample to get significant >distinction between old pages and new ones and measure how well they >compare once remediation has been applied o webpages. > >==//================== > >I'm also hoping to send comments on 5c - performance score, but I >haven't really wrapped my mind around that part yet. > >Thanks for your help sorting these out, before I actually send them >out to the taskforce mailing list. > >Best, > >/Denis > > > > > > > -----Original Message----- > > From: Shawn Henry [mailto:shawn@w3.org] > > Sent: 20 March 2013 17:44 > > To: EOWG (E-mail) > > Subject: EOWG: WCAG-EM comments due this week > > > > Reminder: > > > > -------- Original Message -------- > > Subject: EOWG - WCAG-EM review reminder > > Date: Fri, 08 Mar 2013 13:45:27 -0600 > > From: Shawn Henry <shawn@w3.org> > > To: EOWG (E-mail) <w3c-wai-eo@w3.org> > > > > Hi all, > > > > I've updated the wiki page for comments on WCAG-EM: > > <http://www.w3.org/WAI/EO/wiki/WCAG-EM_review> > > > > If you have copyedits that don't need EOWG consideration, you can send > > them > > directly to <public-wai-evaltf@w3.org> or put them in the wiki under > > the section > > "Copyedits & things that probably don't need discussion" > > > > Remember EOWG is focusing on things like clarity, understandability, > > readability, usability, relationship with other WAI documents, etc. If > > you have > > comments on technical aspects, please send those directly to > > <public-wai- > > evaltf@w3.org>. (If you're not sure, feel free to put them in the > > wiki.) > > > > Thanks! > > ~Shawn > > > > > > > > -------- Original Message -------- > > Subject: Call for Review: Website Accessibility Conformance > > Evaluation > > Methodology (WCAG-EM) > > Date: Tue, 26 Feb 2013 10:10:18 -0800 > > From: Shawn Henry <shawn@w3.org> > > To: WAI Interest Group <w3c-wai-ig@w3.org> > > CC: Shadi Abou-Zahra <shadi@w3.org>, Eric Velleman > > <E.Velleman@bartimeus.nl> > > > > > > > > Dear WAI Interest Group Participants, > > > > WAI invites you to comment on the updated Working Draft of Website > > Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 at: > > http://www.w3.org/TR/WCAG-EM/ > > *We are particularly interested in how it works for you in > > practice*. > > > > Overview: > > WCAG-EM describes an approach for evaluating how websites -- including > > web applications and websites for mobile devices -- conform to Web > > Content > > Accessibility Guidelines (WCAG) 2.0. It covers different situations, > > including > > self-assessment and third-party evaluation. It is independent of > > particular > > evaluation tools, web browsers, and assistive technologies. For more > > information, see the WCAG-EM Overview at: > > http://www.w3.org/WAI/eval/conformance > > > > For review: > > All sections are updated based on feedback from the previous draft. > > Specific > > review questions are indicated with "Review Note" in the draft. We > > especially > > encourage feedback on how the methodology works in different > > situations. > > > > Comments: > > Please send comments on this draft document to the publicly archived > > mailing > > list: > > public-wai-evaltf@w3.org > > by *22 March 2013* > > > > Background: > > WCAG-EM is developed by the WCAG 2.0 Evaluation Methodology Task > > Force (Eval TF), a joint task force of the Web Content Accessibility > > Guidelines > > Working Group (WCAG WG) and Evaluation and Repair Tools Working Group > > (ERT WG). The Eval TF is introduced > > at:<http://www.w3.org/WAI/ER/2011/eval/eval-tf> > > It is a supporting resource for WCAG 2.0 and does not replace or > > supersede it > > in any way. For an overview of WCAG, > > see:<http://www.w3.org/WAI/intro/wcag> > > This work is developed with support of the EC-funded WAI-ACT Project > > (IST > > 287725) described at:<http://www.w3.org/WAI/ACT/> > > It is part of W3C WAI activities on web accessibility evaluation and > > testing > > introduced at:<http://www.w3.org/WAI/ER/2011/eval/> > > > > URI: > > The first URI above goes to the latest version of the document. The > > "dated" > > version of this draft > is:<http://www.w3.org/TR/2013/WD-WCAG-EM-> 20130226/> > > The difference between these URIs are explained in Referencing and > > Linking > > to WAI Guidelines and Technical Documents > > at:<http://www.w3.org/WAI/intro/linking.html> > > > > Please let us know if you have any questions. Thank you in advance for > > your > > comments. > > > > Feel free to circulate this message to other lists; please avoid > > cross-postings > > where possible. > > > > Regards, > > ~Shawn Lawton Henry, WAI Outreach > > Eric Velleman, Eval TF Facilitator > > Shadi Abou-Zahra, W3C/WAI Staff Contact > > > > > > > > ----- > > Shawn Lawton Henry > > W3C Web Accessibility Initiative (WAI) > > Massachusetts Institute of Technology (MIT) > > e-mail: shawn@w3.org > > phone: +1.617.395.7664 > > about: http://www.w3.org/People/Shawn/ > > > > > > > > > > > >
Received on Friday, 29 March 2013 23:33:16 UTC