- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Wed, 19 Oct 2011 17:32:32 +0200
- To: Detlev Fischer <fischer@dias.de>
- CC: public-wai-evaltf@w3.org
Hi Detlev, On 18.10.2011 12:05, Detlev Fischer wrote: > Am 18.10.2011 11:59, schrieb Shadi Abou-Zahra: >> Hi Detlev, >> >> I believe we agreed that the Methodology would explain how to use WCAG >> 2.0 Techniques for evaluating web page samples rather than to duplicate >> them or to create synthesized versions of them. > > This may have been agreed. I just wonder what remains as practical > operational value for evaluators wanting to use the methodology in real > cases, with real sites. Is the idea that the methodology just > establishes a blueprint that would then be fleshed out / operationalised > by actors from the target audience in more hands-on procedures? Hopefully this will not be necessary. The Methodology will provide a procedure around WCAG 2.0. In addition, there is room for improving the How to Meet WCAG 2.0 quick reference [1] (or develop a similar interface) to be more geared for evaluators. It is planned WAI work [2] to be done through the WAI-ACT Project [3]. [1] <http://www.w3.org/WAI/WCAG20/quickref/> [2] <http://www.w3.org/WAI/ER/2011/eval/#supporting> [3] <http://www.w3.org/WAI/ACT/> Best, Shadi >> If we go down that route we risk re-interpreting WCAG or running into >> maintenance issues for chasing web technologies as they are released. >> >> I think we should, as far as possible, decouple the Methodology from the >> detailed "alt-text checking"-level; this is already covered by WCAG. >> >> Having said that, I can imagine improvements to the "How to Meet WCAG2" >> quick reference [1], to better address the need of evaluators rather >> than developers. For example by organizing the Techniques thematically >> rather than by Success Criteria. However, this would be separate work. >> >> [1] <http://www.w3.org/WAI/WCAG20/quickref/> >> >> Regards, >> Shadi >> >> >> On 18.10.2011 11:24, Detlev Fischer wrote: >>> Am 18.10.2011 09:14, schrieb Shadi Abou-Zahra: >>>> Hi Detlev, >>>> >>>> On 18.10.2011 08:39, Detlev Fischer wrote: >>>>> Hi Shady, >>>>> >>>>> I am still not sure how we can clearly delineate the difference >>>>> between >>>>> the wider term "web content" (as in WCAG) and "website" as >>>>> explained on >>>>> - <http://www.w3.org/WAI/ER/methodology-reqs/#website> >>>> >>>> Agree, this is a challenge that we need to address. >>>> >>>> >>>>> Maybe we should clearly state in the definition whether "website" >>>>> includes any content offered via plugin technologies like Flash? >>>> >>>> As I understand it, "website" includes any web content as defined by >>>> WCAG 2.0, which would include Flash and other web technologies. >>>> >>>> >>>>> Thisa has practical implications. For example, if Flash would be >>>>> included, the testing procedure would then either have to be *very* >>>>> general (actually more general than in many tests of techniques, which >>>>> do reference tools like aDesigner2) or fork depending on HTML, FLASH, >>>>> etc. >>>> >>>> I'm not sure I understand this rationale. There are already WCAG 2.0 >>>> Techniques for Flash. Maybe not yet a complete set but enough to show >>>> how the Methodology would utilize existing WCAG 2.0 Techniques. >>> >>> I guess the procedure would either reference, as planned, tests in >>> individual techniques (HTML, CSS, Flash, etc) which means it would be >>> very bitty and carry a lot of redundancy, or it would offer a practical >>> synthesis from a hands-on point of view and thereby, add practical value >>> for testers. When checking for alt texts, for example, there will be >>> many applicable techniques which are often mutually exclusive. If I use >>> "list images" in WAT to trundle through the images of a web page and >>> check whether alt texts descripe content (unlinked images), indicate >>> link target or purpose (linked images) or are empty (decorative images), >>> the economic procedure is to synthesize the assessment as you go through >>> the list. No one would *actually* step through the atomic tests again >>> and again. It would also be disruptive from an operational perspective. >>> You want to have *one* page which tells you what to do and how to assess >>> the instances you find (for some complex SC like 1.1.1 and 1.3.1, it may >>> be several, of course). >>> >>> So back to my original rationale: >>> >>> Either the test procedure is generic and says "Check all images opn the >>> page to verify that the alt attribute is present and appropriate" which >>> hardly goes beyond the text of WCAG Guideline 1.1. and is therefore of >>> questionable merit, or it would present some sort of decision tree which >>> recommends a sequence or path through options and thereby synthesizes >>> the atomic tests necessary to check for conformance to a particular SC. >>> >>> Now, if we deal with HTML/CSS/JS content but also FLASH content, this >>> might then apear as a choice at some point the decision tree: you check >>> if FLASH is used, fork to applicable Flash tests (or a procedure >>> syntheizing tests), the return to check HTML (just as an example). It >>> just makes an already complex HTML-oriented test procedure still more >>> complex. >>> >>> Just as an aside: in BIT-Test we deal with this problem in a 'silo >>> approach': we (will) offer separate WCAG-based tests for different media >>> (HTML/CSS/JS, PDF, maybe some day Flash). >>> >>> I personally think (and I have said this before) that a test procedure >>> that integrates atomic tests and offers advice regarding the success of >>> failure of instances checked is the actual added value in practical >>> terms. >>> >>> Detlev >>>> >>>> Best, >>>> Shadi >>>> >>>> >>>>> Regards, >>>>> Detlev >>>>> >>>>> Am 17.10.2011 15:15, schrieb Shadi Abou-Zahra: >>>>>> Dear Detlev, All, >>>>>> >>>>>> On 17.10.2011 10:15, Detlev Fischer wrote: >>>>>>> I have now fully caught up with the discussion of the term "website" >>>>>>> and >>>>>>> I realise it can be (or has been) defined to include web apps etc. >>>>>> >>>>>> Correct: >>>>>> - <http://www.w3.org/WAI/ER/methodology-reqs/#website> >>>>>> >>>>>> >>>>>>> Still, since the term "website" has been avoided in the title of >>>>>>> WCAG >>>>>>> and also carries connotations of a traditional hierachical site, ist >>>>>>> seems more congenial to me to use "Web content" instead (even if it >>>>>>> makes the acronym still thornier). >>>>>> >>>>>> It is not about the acronym but rather about the scope of WCAG versus >>>>>> that of the Methodology. Web content is used to build websites. WCAG >>>>>> applies to any web content while our Methodology is limited to >>>>>> websites. >>>>>> >>>>>> I think we should either use the term "website" to denote static and >>>>>> dynamic web pages, web applications, intranets, mobile sites, etc, or >>>>>> come up with another term that applies to websites in their entirety. >>>>>> >>>>>> Regards, >>>>>> Shadi >>>>>> >>>>>> >>>>>>> Detlev >>>>>>> >>>>>>> Am 17.10.2011 08:40, schrieb kvotis@iti.gr: >>>>>>>> Hello everyone >>>>>>>> >>>>>>>> i aggree with the following comment of Detlev and this was also my >>>>>>>> comment >>>>>>>> to a previous mail. I cannot understand why we are refereeing >>>>>>>> only to >>>>>>>> Websites. I think that we need a more general term including also >>>>>>>> Web >>>>>>>> applications, Mobile Web applications,etc... >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> kostas >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> back from holidays, I am trying to catch up with discussions now. >>>>>>>>> >>>>>>>>> I do not mind WAEM even though I do not think it is particularly >>>>>>>>> easy >>>>>>>>> to pronounce (other then spelling out double-U - E - A - M). >>>>>>>>> >>>>>>>>> I have some concern regarding the W for "website", as in the >>>>>>>>> current >>>>>>>>> full title >>>>>>>>> "Website Accessibility Evaluation Methodology". The "WC" of WCAG >>>>>>>>> sounds a lot more general than the term "website". This also >>>>>>>>> relates >>>>>>>>> to the important comments by Aaron Leventhal regarding the >>>>>>>>> scope of >>>>>>>>> the methodology, tool independence, and the possible need to cover >>>>>>>>> different web content and UA scenarios. >>>>>>>>> >>>>>>>>> Is what we develop here focused on websites and not on things like >>>>>>>>> web >>>>>>>>> apps for mobile UAs? If we want to be as general as WCAG we might >>>>>>>>> need >>>>>>>>> to change the full name of the methodology and accordingly, the >>>>>>>>> acronym. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Detlev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Zitat von "Velleman, Eric"<evelleman@bartimeus.nl>: >>>>>>>>> >>>>>>>>>> Dear all, >>>>>>>>>> >>>>>>>>>> We decided in the call to discuss the short name in the list. >>>>>>>>>> Below >>>>>>>>>> are some short names from the discussions we had sofar and a >>>>>>>>>> proposed shortlist of requirements: >>>>>>>>>> >>>>>>>>>> Requirements for a short name: >>>>>>>>>> - It should be short >>>>>>>>>> - Easy to pronounce >>>>>>>>>> - Clear to all what it means (selfexplanatory) >>>>>>>>>> - Be about the methodology >>>>>>>>>> >>>>>>>>>> Shortnames (Make your choice or add new ones): >>>>>>>>>> - SiteAccess >>>>>>>>>> - WCAG-Method >>>>>>>>>> - WCAG-EM >>>>>>>>>> - WAEM (really using the title) >>>>>>>>>> - WCAG-Check >>>>>>>>>> - AccessSite >>>>>>>>>> - WCAG-Site >>>>>>>>>> - AccessCheck >>>>>>>>>> - SiteCheck >>>>>>>>>> - CheckSite >>>>>>>>>> - WAMBAM >>>>>>>>>> - WAME >>>>>>>>>> - MCEWA >>>>>>>>>> - CEWA >>>>>>>>>> - CEW2WCAG2 >>>>>>>>>> - UWEM >>>>>>>>>> - SITE >>>>>>>>>> - MAWA >>>>>>>>>> - MDWC >>>>>>>>>> - EWAMAC >>>>>>>>>> - EMAWC >>>>>>>>>> - WEM >>>>>>>>>> >>>>>>>>>> Kindest regards, >>>>>>>>>> >>>>>>>>>> Eric >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> Detlev Fischer PhD >>>>>>>>> DIAS GmbH - Daten, Informationssysteme und Analysen im Sozialen >>>>>>>>> Gesch?ftsf?hrung: Thomas Lilienthal, Michael Zapp >>>>>>>>> >>>>>>>>> Telefon: +49-40-43 18 75-25 >>>>>>>>> Mobile: +49-157 7-170 73 84 >>>>>>>>> Fax: +49-40-43 18 75-19 >>>>>>>>> E-Mail: fischer@dias.de >>>>>>>>> >>>>>>>>> Anschrift: Schulterblatt 36, D-20357 Hamburg >>>>>>>>> Amtsgericht Hamburg HRB 58 167 >>>>>>>>> Gesch?ftsf?hrer: Thomas Lilienthal, Michael Zapp >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > -- 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 Wednesday, 19 October 2011 15:33:00 UTC