- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Fri, 31 Jan 2014 09:12:10 +0100
- To: Karl Groves <karlgroves@gmail.com>
- CC: public-wai-evaltf@w3.org
Thanks Karl. The issue is terminology. The full page needs to be checked for each Success Criterion, but that does not mean you need to re-evaluate any page components already evaluated. You either know they pass or fail from your previous evaluation, and you need to consider this partial result for evaluating the full page. Anyway, we will consider your comment for future refinement. Best, Shadi On 30.1.2014 20:12, Karl Groves wrote: > Shadi, > > The portion you cited is clear enough IMO, however the guidance I cited > seems to be in direct conflict, especially as the words "full page" > contains a link to normative WCAG documentation stating that partial pages > cannot be considered in conformance claims. > > > On Thu, Jan 30, 2014 at 12:35 PM, Shadi Abou-Zahra <shadi@w3.org> wrote: > >> Hi Karl, >> >> Thank you for your prompt feedback! >> >> There is a note in this section that reads: >> [[ >> While it is important to check the conformance of each web page and web >> page state in the sample to each WCAG 2.0 Success Criterion, repeated >> components such as the header, navigation bars, search form, and others >> usually do not need to be re-evaluated on each occurrence. For example, if >> the same header code is used on two web pages then it is evaluated on the >> first only in most situations. >> ]] >> >> A similar statement is earlier on in the introduction to Step 4. >> >> Maybe these need to be made more clear? Do you have some suggestions? >> >> Best, >> Shadi >> >> >> >> On 30.1.2014 17:11, Karl Groves wrote: >> >>> Apologies for my hasty striking of the send button. Here is the full >>> response: >>> >>> WCAG-EM contains the statement, >>> "Methodology Requirement 4.a: Check that each full page (web page and web >>> page state) in the selected sample satisfies each of the WCAG 2.0 Success >>> Criteria of the target conformance level." >>> >>> This statement and supporting material make it appear as though an >>> *entire* >>> web page must be tested in its entirety in order to satisfy the >>> requirements. This ignores the fact that websites composed of a series of >>> static pages is the exception, rather than the rule. The vast majority >>> of >>> websites these days are presented through the use of some server-side >>> means >>> to generate the final interface - from basic SSI to template systems, to >>> complex web applications being generated from content management systems >>> and everything in between. In some cases the server-side generation >>> merely >>> wraps content in a global wrapper while in others the server-side code >>> merges data and markup as part of a template. This methodology seems to >>> ignore that fact and may mislead the reader into believing that the final >>> rendered web page(s) must be tested in their entirety. This risks >>> requiring >>> the tester to perform needless duplicate work. >>> >>> While the goal is and should remain a full page that is accessible, the >>> testing of the entire page is unnecessary in reaching this goal. A >>> sensible >>> sampling strategy can and should use representative samples of those >>> document features which contribute to the page. Multiple instances of UI >>> components that are shared across pages do not need to be tested multiple >>> times and should be ignored or avoided during the test effort as their >>> inclusion will not add any new data but will add needless effort. >>> >>> >>> On Thu, Jan 30, 2014 at 11:08 AM, Karl Groves <karlgroves@gmail.com> >>> wrote: >>> >>> WCAG-EM contains the statement, >>>> "Methodology Requirement 4.a: Check that each full page (web page and web >>>> page state) in the selected sample satisfies each of the WCAG 2.0 Success >>>> Criteria of the target conformance level." >>>> >>>> This statement and supporting material make it appear as though an >>>> *entire* web page must be tested in its entirety in order to satisfy the >>>> requirements. This ignores the fact that websites composed of a series >>>> of >>>> static pages is the exception, rather than the rule. The vast majority >>>> of >>>> websites these days are presented through the use of some server-side >>>> means >>>> to generate the final interface - from basic SSI to template systems, to >>>> complex web applications being generated from content management systems >>>> and everything in between. In some cases the server-side generation >>>> merely >>>> wraps content in a global wrapper while in others the server-side code >>>> merges data and markup as part of a template. This methodology seems to >>>> ignore that fact and may mislead the reader into believing that the final >>>> rendered web page(s) must be tested in their entirety. This risks >>>> requiring >>>> the tester to perform needless duplicate work. >>>> >>>> While the goal is and should remain a full page that is accessible, the >>>> testing of the entire page is unnecessary >>>> >>>> >>>> -- >>>> Karl Groves >>>> www.karlgroves.com >>>> @karlgroves >>>> http://www.linkedin.com/in/karlgroves >>>> Phone: +1 410.541.6829 >>>> >>>> www.botsmasher.com >>>> www.a11ybuzz.com >>>> www.mothereffingtoolconfuser.com >>>> Day One Wordpress Theme: https://bitbucket.org/karlgroves/day-one-theme >>>> >>>> >>> >>> >>> >> -- >> 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 Friday, 31 January 2014 08:12:41 UTC