W3C home > Mailing lists > Public > w3c-wai-au@w3.org > October to December 2012

draft test for ATAG2.0 SC A.3.1.3

From: Boland Jr, Frederick E. <frederick.boland@nist.gov>
Date: Fri, 12 Oct 2012 11:08:52 -0400
To: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
CC: "Boland Jr, Frederick E." <frederick.boland@nist.gov>
Message-ID: <D7A0423E5E193F40BE6E94126930C4930BA90BD723@MBCLUSTER.xchange.nist.gov>
NOTE: In doing the following, I was given to wonder if in SC A.3.1.3 "mechanisms" (plural) should be changed to "a mechanism" (singular)?  Do we really want to require -more than one- keyboard access mechanism with superior "efficiency" to sequential keyboard access?  Wouldn't just one suffice?  In the following I assumed just one..

Thanks and best wishes
Tim Boland NIST

-----------------------begin test for SC A.3.1.3---------------------------------------

Steps:

0. Determine if the platform on which the authoring tool is running supports a keyboard interface.  If it does, then proceed to Step 1.  If not, then skip to Step 8.

1. Document all mechanisms of the user interface for the authoring tool under test (from authoring tool documentation or from experience).  If there are no such mechanisms, then skip to Step 8.  Otherwise proceed to Step 2.

2. Document all keyboard access capabilities  (via mechanisms from Step 1) supported by the keyboard interface (from Step 0) of the authoring tool(from authoring tool documentation or from experience).  If there are fewer than two keyboard access capabilities supported, or if sequential keyboard access is not included, then skip to Step 7.  Otherwise proceed to Step 3.

3. Determine/document the efficiency criteria (including rationale?) for evaluating keyboard access mechanisms that you will use for this particular authoring tool, platform, etc.  Go to Step 4.

4. Document the "before state" of  the authoring tool user interface on this platform.  Use a sequential keyboard access mechanism (from Steps 1 and 2) that navigates the focus one-by-one through all of the items in an ordered set (e.g., menu items, form fields) until the desired item is reached and activated.   Record the "after state" of the authoring tool user interface at this point. Determine the "efficiency" of this keyboard access mechanism using your criteria from Step 3.  Then go back so the "before state"  of the authoring tool user interface (using any mechanism available from Step 1 to do this).  Go to Step 5.

5. From the "before state" specified earlier, use a -different from sequentlal-? keyboard access mechanism (from Step 1) (such as keyboard shortcuts and the use of bypass links) on the same objects as used in Step 4.   Record the "after state" of the authoring tool user interface at this point, and verify that this "after state" is the same as the "after state" from Step 4.  Determine the "efficiency" of this access using the same criteria as used in Step 4.  Go to Step 6.

6. Compare/evaluate the "efficiencies" determined from Step 4 and from Step 5.  If as a result of this comparison/evaluation,  Step 5 is more "efficient"  than Step 4, then this authoring tool "passes" this SC on this platform.  If Step 5 is more "efficient" than Step 4, or the "efficiencies" are the same for Steps 4 and 5, then this authoring tool fails this SC for this platform.  Go to Step 7.

7. If the only keyboard access method supported (from Step 2) is sequential keyboard access, then this authoring tool "fails" this SC for this platform.  Go to Step 8.

8. If the authoring tool has not been evaluated as "pass" or "fail" on this platform in previous steps up to this point, then the authoring tool is "N/A" for this SC on this platform.

----------------------end test for SCA.3.1.3-----------------------------------
Received on Friday, 12 October 2012 15:09:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 October 2012 15:09:21 GMT