I think the rationale (methodology) needs to be well argued and
referenced and cannot really be very short. It is just a type of
document that has a different purpose and audience compared to a
succinct procedural instruction. The latter should be optimised for
the practitioner tackling a website and should have little or no
theoretical ballast.
Quoting Shadi Abou-Zahra <shadi@w3.org>:
> Hi Detlev,
>
> I'm not sure what the others think but I'm not convinced we need two
> documents. The "rationale, audience & scope, rationale of sampling"
> sections should probably be very short to set the scene for the main
> sections but maybe this is unclear from the table of contents alone.
>
> Best,
> Shadi
>
>
> On 25.10.2011 09:45, Detlev Fischer wrote:
>> Hi Shadi, hi all,
>>
>> I made a suggestion a while ago to decouple the methodology (rationale)
>> from the method.
>>
>> * Methodology: rationale, audience & scope, rationale of sampling
>> and sampling methods, measurement of score / tolerances,
>> references etc.
>>
>> * Method: a usable procedure for the actual testing of websites, e.g.:
>> - make entry check (site applicable for testing)
>> - select WCAG level applied (A, AA, AAA)
>> - define page sample, select states and processes
>> - run through procedure proper, with checkpoints based on WCAG
>> success criteria and all checks needed to test whether the sites
>> meets them - which in case of 1.1.1 and 1.3.1 probably means
>> several checkpoints
>> - generate report and, if applicable, conformance statement
>>
>> The reason is simply that the procedure gets lost in the draft Table of
>> Contents. We also need to think from a point of view of the users of the
>> method.
>>
>> Any comments?
>>
>> Detlev
>>
>> 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.
>>>
>>> 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)
>
>
--
---------------------------------------------------------------
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
---------------------------------------------------------------