W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > January to March 2013

Re: EOWG: WCAG-EM comments due this week

From: Sharron Rush <srush@knowbility.org>
Date: Fri, 29 Mar 2013 18:32:46 -0500
Message-ID: <5156249f.4692e00a.7fd2.ffffd844@mx.google.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 29 March 2013 23:33:17 UTC