W3C home > Mailing lists > Public > public-wai-evaltf@w3.org > June 2012

Re: Step 1.e: Define the Techniques to be used

From: Detlev Fischer <detlev.fischer@testkreis.de>
Date: Fri, 1 Jun 2012 11:46:59 +0200
Cc: Eval TF <public-wai-evaltf@w3.org>
Message-Id: <0F3D608C-9C91-4FC7-89D5-E01E17C7638F@testkreis.de>
To: Alistair Garrison <alistair.j.garrison@gmail.com>
Hi Alistair, as I said, my example was also not comprehensive. I agree  
that checking SC 2.1.1 would also needs looking out for elements that  
respond to the mouse, but not to the keyboard. That is actually part  
of the checkpoint for 2.1.1 in BITV-Test.
Best, Detlev


On 1 Jun 2012, at 11:26, Alistair Garrison wrote:

> Hi Detlev,
>
> Taking the time to re-read what I wrote you'd see I state the code  
> was "an example only" - just a simple example of functionality -  
> sadly I don't have the time for more… It was not meant to be assessed…
>
> The example provided an element (attached to functionality) which is  
> not focusable - and does not appear in the tab order (full stop).
>
> To be crystal clear:
>
> 1) It appears that your testing method would have missed it - if you  
> check keyboard operability using just tabbing.
> 2) It would not have been missed if the web developer had  
> specifically told you that they intended all elements attached to  
> functions to be in the tab order. And, you had checked what they said.
>
> This is the point behind my request that 1e be non-optional.
>
> Alistair
>
> On 1 Jun 2012, at 11:17, Detlev Fischer wrote:
>
>> Hi AListair,
>>
>> Again I'll wait for others to chime in - just respond to your color  
>> change example:
>>
>> If the scripted color change from red to blue is only activated on  
>> mouseover, this would be irrelevant as long as it is not used to  
>> meet any SC. If, however, such a change is used to meet SC 1.4.1 by  
>> highlighting inline text links that already has a color contrast of  
>> 3:1 or better to the surrounding text, changing color alone may or  
>> may not be sufficient as visual enhancement  (the test of G183  
>> mentions enhancements "such as an underline, font change, etc" (http://www.w3.org/TR/WCAG20-TECHS/G183.html 
>>  - incidentally one of the many cases where even fairly detailed  
>> test procedures apparently still leave wiggle room). In any case,  
>> assuming that color change would be deemed sufficient as visual  
>> enhancement on receiving focus, testing how focusable elements  
>> respond to both mouseover and tabbing would be needed (a detail  
>> that I had left out in my example). Still, I wouldn't see a need to  
>> delve into the script if the behaviour is observable in normal  
>> interaction via mouse and keyboard.
>>
>> Regards,
>> Detlev
>>
>> On 1 Jun 2012, at 10:50, Alistair Garrison wrote:
>>
>>> Hi Detlev,
>>>
>>> I accept your position with 1.e - and will remain firmly with mine  
>>> (1.e. needed, and non-optional).  It would be interesting to hear  
>>> what others think?
>>>
>>> Also...
>>>
>>> You write "You just check, in the set of selected UA, by tabbing,  
>>> activating links, and so on if the page actually affords proper  
>>> keyboard operability - not necessarily how, by which technique,  
>>> this has been achieved."
>>>
>>> I would just like to say that, to my mind, this again re- 
>>> emphasises the need to test against web developer followed  
>>> techniques - as otherwise you run the risk of missing things  
>>> (technical accessibility evaluation should be supplemented by  
>>> functional testing, not replaced).
>>>
>>> You've picked an interesting example - which I think clearly  
>>> highlights this very issue. If you take the following, an example  
>>> only, but lets say its a wonderful function a keyboard user might  
>>> really wish to use ;-)
>>>
>>> function changeToBlue() {colorTarget.style.cssText =  
>>> "colour:blue;";} (placed in script section)
>>>
>>> <div id="colorTarget" onmouseover="changeToBlue()"  
>>> onblur="changeToBlue()" style="color:red;">Test</div>
>>>
>>> This element / function does not appear in the tab order -  
>>> thinking about keyboard operability I believe it is a fail, but  
>>> how would you know if you just check by tabbing?  This would,  
>>> however, have been picked up if a web developer followed technique  
>>> had been evaluated which said "all elements attached to JavaScript  
>>> functionality appear in the tab order (or some such thing)" - it  
>>> would also have been valuable for the web developer to know this.
>>>
>>> Finally, I wish to clarify that once all the techniques followed  
>>> by the developer have been evaluated I would whole-heartly suggest  
>>> functional testing (more for usability for people with  
>>> disabilities and realism) - but only afterwards, not instead.
>>>
>>> All the best
>>>
>>> Alistair
>>>
>>> On 1 Jun 2012, at 09:49, Detlev Fischer wrote:
>>>
>>>> Hi Alistair,
>>>>
>>>> I'll leave it to others to reply as I have made my position clear  
>>>> (I hope). Just one clarification. You write:
>>>>
>>>>> So, I'd really like to ask - "is 1.e being non-optional only  
>>>>> objectionable to those who operate a third-party 'set in stone'  
>>>>> evaluation methodology?" - as they could not possibly think of  
>>>>> assessing anything other than they have already decided to assess…
>>>>
>>>>
>>>> I was trying to point out that the procedure must *not* be set in  
>>>> stone, i.e. check only for very specific techniques since it  
>>>> might miss other ways of meeting the Success Criteria. The  
>>>> assessment methods are often not tied to a particular technique  
>>>> anyway. If you check for keyboard operability, proper focus  
>>>> order, focus visibilty etc might have been created in a variety  
>>>> of ways. You just check, in the set of selected UA, by tabbing,  
>>>> activating links, and so on if the page actually affords proper  
>>>> keyboard operability - not necessarily how, by which technique,  
>>>> this has been achieved.
>>>>
>>>> Regards,
>>>> Detlev
>>>>
>>>> On 1 Jun 2012, at 08:42, Alistair Garrison wrote:
>>>>
>>>>> Dear All,
>>>>>
>>>>> The fact that evaluators each can have their own take even on  
>>>>> WCAG 2.0 is proof enough that 1.e is needed - and should be non- 
>>>>> optional.  If we fail to record the techniques selected and  
>>>>> followed by the web developer, and ideally tested agains, what  
>>>>> hope do we have of creating evaluations which are reproducible…  
>>>>> or, indeed which provide useful feedback as to failings in  
>>>>> implementation - and, importantly failings in technique selection.
>>>>>
>>>>> To my mind, a goal of WCAG 2.0 is to let the web developer  
>>>>> decide which techniques they believe satisfy the Success  
>>>>> Criteria of WCAG 2.0 - and, the evaluators job to test what they  
>>>>> have done.   That said, there will be a good deal of work ahead  
>>>>> in educating people as to what satisfies each Success Criteria -  
>>>>> and, 1.e being non-optional could play an important role.
>>>>>
>>>>> On a different note - if we look at an evaluation carried out by  
>>>>> the same company that creates the website (first party) it would  
>>>>> be laughable if they tested against anything but the techniques  
>>>>> their developers used to create the website - why would they…   
>>>>> For them, following 1.e would be a 'no-brainer'…
>>>>>
>>>>> So, I'd really like to ask - "is 1.e being non-optional only  
>>>>> objectionable to those who operate a third-party 'set in stone'  
>>>>> evaluation methodology?" - as they could not possibly think of  
>>>>> assessing anything other than they have already decided to assess…
>>>>>
>>>>> Interested to hear any thoughts…
>>>>>
>>>>> All the best
>>>>>
>>>>> Alistair
>>>>>
>>>>> On 1 Jun 2012, at 05:37, Vivienne CONWAY wrote:
>>>>>
>>>>>> Hi Richard
>>>>>> I've actually been having a long debate (they get pretty  
>>>>>> excited) with the IG about this one.  According to WCAG 2,  
>>>>>> 2.4.1. is met if the ST of a correct heading structure is  
>>>>>> applied.  While I don't agree that having headings should be a  
>>>>>> sufficient technique on its own (due to the fact it doesn't  
>>>>>> help keyboard users), it appears to be set in WCAG 2 that way.   
>>>>>> It fails 2.4.1 if there are no (working - implied I think) skip  
>>>>>> links and the heading structure is either non-existent or  
>>>>>> insufficient to bypass repeated navigation structures.
>>>>>>
>>>>>> Your thoughts?
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Vivienne L. Conway, B.IT(Hons), MACS CT, AALIA(cs)
>>>>>> PhD Candidate & Sessional Lecturer, Edith Cowan University,  
>>>>>> Perth, W.A.
>>>>>> Director, Web Key IT Pty Ltd.
>>>>>> v.conway@ecu.edu.au
>>>>>> v.conway@webkeyit.com
>>>>>> Mob: 0415 383 673
>>>>>>
>>>>>> This email is confidential and intended only for the use of the  
>>>>>> individual or entity named above. If you are not the intended  
>>>>>> recipient, you are notified that any dissemination,  
>>>>>> distribution or copying of this email is strictly prohibited.  
>>>>>> If you have received this email in error, please notify me  
>>>>>> immediately by return email or telephone and destroy the  
>>>>>> original message.
>>>>>> ________________________________________
>>>>>> From: RichardWarren [richard.warren@userite.com]
>>>>>> Sent: Friday, 1 June 2012 1:45 AM
>>>>>> To: detlev.fischer@testkreis.de; alistair.j.garrison@gmail.com; public-wai-evaltf@w3.org
>>>>>> Subject: Re: Step 1.e: Define the Techniques to be used
>>>>>>
>>>>>> Hi Detlev,
>>>>>>
>>>>>> As mentioned before, meeting one individual SC does not mean  
>>>>>> automatically
>>>>>> meeting the actual guideline subsection. In the case you  
>>>>>> mention - correct
>>>>>> semantics (headings) can provide a way for blind users to  
>>>>>> navigate more
>>>>>> easily (incl. skiping blocks). However a sighted keyboard user  
>>>>>> with a
>>>>>> standard browser does not usually have access to the semantic  
>>>>>> code in the
>>>>>> way that a screen reader does. So for these users we still need  
>>>>>> to provide a
>>>>>> "skip" link for long navigation lists at least.
>>>>>>
>>>>>> So if "Commissioner says we have implemented skip links to meet  
>>>>>> 2.4.1 Bypass
>>>>>> Blocks"  then I say great, but you also need to have suitable  
>>>>>> heading codes
>>>>>> (and possibly something like "skip code samples" if the site is  
>>>>>> an on-line
>>>>>> course in HTML) so we will check that your site has mechanism/s  
>>>>>> for
>>>>>> bypassing repetitive blocks and non-informative blocks whilst  
>>>>>> we are at it
>>>>>> for compliance with guideline 2.4.1.
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: detlev.fischer@testkreis.de
>>>>>> Sent: Thursday, May 31, 2012 4:22 PM
>>>>>> To: alistair.j.garrison@gmail.com ; public-wai-evaltf@w3.org
>>>>>> Subject: Re: Fwd: Step 1.e: Define the Techniques to be used
>>>>>>
>>>>>> Hi Alistair, hi all,
>>>>>>
>>>>>> Don't know if it is a good idea to answer here since this now  
>>>>>> goes into the
>>>>>> "Disposition of Comments" but I'll have a go nevertheless.
>>>>>>
>>>>>> As I understand it, we need to look for each SC if any of the  
>>>>>> Sufficient
>>>>>> Techniques (or a set of combined techniques as expressed in the  
>>>>>> options of
>>>>>> the "How to meet" document) has been suvessfully used. For  
>>>>>> that, it is not
>>>>>> sufficient to test techniques being put forward by the  
>>>>>> comissioner.
>>>>>>
>>>>>> Example:
>>>>>> * Commissioner says "we have implemented skip links to meet  
>>>>>> 2.4.1 Bypass
>>>>>> Blocks"
>>>>>> * You evaluate and find that for some reason skip links aren't  
>>>>>> properly
>>>>>> implemented (fail of that technique)
>>>>>> * There is a proper headings structure that meets SC 4.2.1 (or  
>>>>>> ARIA
>>>>>> landmarks in a context where that is accessibility supported)
>>>>>>
>>>>>> Now as long as you don't hit a failure, I guess you woud need  
>>>>>> to say pass to
>>>>>> the SC even though the technique submitted did not work.
>>>>>> (Having said that, the faulty skip links may fail other SC, but  
>>>>>> not SC
>>>>>> 2.4.1).
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> Regards,
>>>>>> Detlev
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: alistair.j.garrison@gmail.com
>>>>>> To: public-wai-evaltf@w3.org
>>>>>> Date: 31.05.2012 17:06:52
>>>>>> Subject: Fwd: Step 1.e: Define the Techniques to be used
>>>>>>
>>>>>>
>>>>>>> Dear All,
>>>>>>>
>>>>>>> Would it be possible to add my comments about Step 1.e to the  
>>>>>>> comments
>>>>>>> document - http://www.w3.org/WAI/ER/conformance/comments
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: Alistair Garrison <alistair.j.garrison@gmail.com>
>>>>>>>> Subject: Step 1.e: Define the Techniques to be used
>>>>>>>> Date: 10 May 2012 10:48:41 CEST
>>>>>>>> To: Eval TF <public-wai-evaltf@w3.org>
>>>>>>>>
>>>>>>>> Dear All,
>>>>>>>>
>>>>>>>> "Step 1.e: Define the Techniques to be used" - could we  
>>>>>>>> consider making
>>>>>>>> this step non-optional?
>>>>>>>>
>>>>>>>> The first reason being that we really need to check their  
>>>>>>>> implementation
>>>>>>>> of the techniques (W3C, their own code of best practice or  
>>>>>>>> whatever) they
>>>>>>>> say they use.
>>>>>>>>
>>>>>>>> For example:
>>>>>>>>
>>>>>>>> - Case 1) If they have done something by using technique A,  
>>>>>>>> and we
>>>>>>>> evaluate using technique B there could be an issue (they  
>>>>>>>> might fail B);
>>>>>>>> - Case 2) If they have done something by using technique A,  
>>>>>>>> and we
>>>>>>>> evaluate using technique A and B there still could be an  
>>>>>>>> issue (they
>>>>>>>> might fail B);
>>>>>>>> - Case 3) If they have done something by using technique A,  
>>>>>>>> and we
>>>>>>>> evaluate using technique A - it seems to work.
>>>>>>>>
>>>>>>>> The second reason being that testing seems only to be really  
>>>>>>>> replicable
>>>>>>>> if we know what the techniques were they said they  
>>>>>>>> implemented -
>>>>>>>> otherwise, two different teams could easily get two different  
>>>>>>>> results
>>>>>>>> based on the cases above.
>>>>>>>>
>>>>>>>> I would be interested to hear your thoughts.
>>>>>>>>
>>>>>>>> Very best regards
>>>>>>>>
>>>>>>>> Alistair
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> This e-mail is confidential. If you are not the intended  
>>>>>> recipient you must not disclose or use the information  
>>>>>> contained within. If you have received it in error please  
>>>>>> return it to the sender via reply e-mail and delete any record  
>>>>>> of it from your system. The information contained within is not  
>>>>>> the opinion of Edith Cowan University in general and the  
>>>>>> University accepts no liability for the accuracy of the  
>>>>>> information provided.
>>>>>>
>>>>>> CRICOS IPC 00279B
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> -- 
>>>> Detlev Fischer
>>>> testkreis - das Accessibility-Team von feld.wald.wiese
>>>> c/o feld.wald.wiese
>>>> Borselstraße 3-7 (im Hof)
>>>> 22765 Hamburg
>>>>
>>>> Tel   +49 (0)40 439 10 68-3
>>>> Mobil +49 (0)1577 170 73 84
>>>> Fax   +49 (0)40 439 10 68-5
>>>>
>>>> http://www.testkreis.de
>>>> Beratung, Tests und Schulungen für barrierefreie Websites
>>>>
>>>>
>>>>
>>>
>>
>> -- 
>> Detlev Fischer
>> testkreis - das Accessibility-Team von feld.wald.wiese
>> c/o feld.wald.wiese
>> Borselstraße 3-7 (im Hof)
>> 22765 Hamburg
>>
>> Tel   +49 (0)40 439 10 68-3
>> Mobil +49 (0)1577 170 73 84
>> Fax   +49 (0)40 439 10 68-5
>>
>> http://www.testkreis.de
>> Beratung, Tests und Schulungen für barrierefreie Websites
>>
>>
>>

-- 
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Borselstraße 3-7 (im Hof)
22765 Hamburg

Tel   +49 (0)40 439 10 68-3
Mobil +49 (0)1577 170 73 84
Fax   +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
Received on Friday, 1 June 2012 09:38:46 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:52:14 GMT