Re: EOWG: WCAG-EM comments due this week

Hi Sharron,

Yes, I can move my comments to the wiki, but I don't think that will be possible before some time next week. With Easter and everything happening now, my kids are expecting me to be available for them this weekend. 

So, if you feel like moving it there yourself over the week-end, you're more than welcomed to do so. If not, I'll do my best to integrate them before next Friday.

I'm also interested in knowing which elements you're disagreeing with. Can you share some of those, or would you rather wait until our next eo meeting to discuss those?

Best,

/Denis




On 2013-03-29, at 7:32 PM, Sharron Rush <srush@knowbility.org> wrote:

> 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 Saturday, 30 March 2013 20:12:43 UTC