UAWG Action Item: Testability review of UAAG 2.0 draft

I had an action item to review the UAAG 2.0 draft from the perspective 
of testability (the degree to which success criteria can be judged to 
pass or fail):


3RD PARTY CONVENTIONS: Whenever UA developer is asked to follow existing 
conventions there is a possibility they will miss a convention that a 
3rd party tester might feel they should not have. Probably not a major 
issue since the techniques will list links to the major convention 
sources for the major platforms (Windows, MacOS, Gnome, etc.)

Occurrences:
1.1.1, 1.1.2 (op. env. conventions)
2.3.3, 2.4.3, 2.5.3. 2.6.2 (API conventions)
2.7.1 (op. env. conventions)
3.6.2 (highlighting options)
3.7.3 (text options)
4.1.6 (text area conventions)
4.1.10 (conventional bindings)

DEVELOPER SPECIFIES: These success criteria involve developer judgment 
calls that 3rd party testers might not have access to. So these 
decisions should be documented in the conformance claim:

Occurences:
1.2.1 (which are the access features?)
2.8.1 (which APIs are implemented due to UAAG?)
3.13.3 (Important Elements?)
5.3.2, 5.3.3, 5.3.4, 5.3.5 features that benefit accessibility


BROAD INTERPRETATION POSSIBLE: These success criteria can be interpreted 
very broadly ("Make explicitly-defined relationships in the 
content...available programmatically"). Maybe we make use of 
"recognizes" keyword and in all cases of "recognize" we require the 
developers to document what they recognize?

Occurences:
3.4.1, 3.4.2 (which relationships available programmatically?)
3.5.1, 3.5.2 Repair Alternatives


OTHER:
2.10.1 "Timely manner"?





-- 
Jan Richards, M.Sc.
User Interface Design Lead
Adaptive Technology Resource Centre (ATRC)
Faculty of Information (i-school)
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Tuesday, 14 October 2008 15:44:09 UTC