RE: UAAG Guideline 12 Gaps

I think an interesting level III criteria might call for some explanation of the browser user interface.  Keyboard shortcuts and such are great documented in help but as software becomes more and more visual, some explanation of what's going on might be a nice level III item.

I recognize that one goal of accessibility is that you don't necessarily need to perceive the interface in one (visual) way but still having some orientation to what's going on could help in some settings.

Kelly



-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On Behalf Of Jan Richards
Sent: Friday, November 02, 2007 11:57 AM
To: WAI-UA list
Subject: UAAG Guideline 12 Gaps


As per one of my action items from Oct. 25
(http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0018.html):


Overall, if we go to a WCAG or ATAG-like, multi-level success criteria
model, all of 12 would likely roll together into one guideline (see at
end of this message).


12.1 Provide accessible documentation (P1)
- no pre-existing issues in the Wiki
- I suggest we might consider synching with ATAG 2.0 on this:
<quote>
A.4.4.1 Accessible Format (user interface "chrome"): At least one
version of the documentation must either be:
- "A" Accessible: Web content and conform to a minimum level of Web
content accessibility (although it is not necessary for the
documentation to be delivered on-line), or
- Accessible Platform Format: not be Web content and conform to a
published accessibility benchmark that is identified in the conformance
claim (e.g., when platform-specific documentation systems are used).
</quote> @@note "accessibility benchmark" is an ATAG term@@


12.2 Provide documentation of accessibility features (P1)
- In ATAG 2.0 this is handled by a success criteria in a Guideline
"A.4.4 Document the user interface including all accessibility features"

<quote>
A.4.4.2 Document Accessibility Features (user interface "chrome"): All
features that are specifically required to meet Part A of these
guidelines (e.g. keyboard shortcuts, text search, etc.) must be documented.
</quote>

- ATAG 2.0 also includes a P3 requirement for a "tutorial" that might be
useful in a user agent?


12.3 Provide documentation of default bindings (P1)
- agree with our prev. issue to remove the sufficient technique
- I think perhaps that this checkpoint could be a success criteria for 11.5.


12.4 Provide documentation of changes between versions (P2)
- no pre-existing issues in the Wiki
- suggest defining "user agent to features that benefit accessibility"
with reference to features needed to meet UAAG.


12.5 Provide dedicated accessibility section (P2)
- This is just a P2 modifier to 12.2

===================================
Rolling it all together:

Guideline 12.X: Document the user interface including all accessibility
features.

Level A Success Criteria

-Accessible Format: At least one version of the documentation must
either be:
+ "A" Accessible: Web content and conform to a minimum level of Web
content accessibility (although it is not necessary for the
documentation to be delivered on-line), or
+ Accessible Platform Format: not be Web content but be an accessible
format@@needs work@@ (e.g., when platform-specific documentation systems
are used).

- Document Accessibility Features: All *user agent features that benefit
accessibility* (i.e., involved in meeting these guidelines, e.g.
keyboard shortcuts, text search, etc.) must be documented.


Level AA Success Criteria

- Provide documentation of the default user agent input configuration
(e.g., the default keyboard bindings).

- Provide documentation of changes since the previous version of all
*user agent features that benefit accessibility*.

- In a dedicated section of the documentation, provide a centralized
view of all *user agent features that benefit accessibility*.


Level AAA Success Criteria

@@NEW IDEA@@- Accessible Browsing Tutorial: A tutorial on how to use the
tool's accessibility features together is provided.

@@NEW IDEA@@ - In documenting *user agent features that benefit
accessibility* include information on behavior of features if
accessibility information in the content is missing or broken.




===================================

Cheers,
Jan

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

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

Received on Monday, 5 November 2007 01:28:17 UTC