New proposed section in UAAG 2.o Implementing doc

Location:
-----
To follow "Using levels" (http://jspellman.github.io/UAAG/Implementing-UAAG20/#intro-using-levels)

Wording:
-----
The UAAG 2.0 success criteria apply to 

- UA user interface: 
When the success criterion will be applicable to the controls (e.g. menus, buttons, prompts, native audio/video player controls, and other components for input and output) and mechanisms (e.g. selection and focus) provided by the user agent that are not created on the basis of the author-supplied content. The user agent user interface may include extensions that become part of the user agent user interface (e.g. toolbars, additional menus). 
(Source: Glossary definition of *user agent user interface* [http://jspellman.github.io/UAAG/Implementing-UAAG20/#def-ua-ui])

- Content user interface: 
When the success criterion will be applicable to the user interface that emerges from the user agent rendering of the author-supplied content. It includes all rendered content (e.g. text, headings, enabled elements, disabled elements, author-supplied audio/video controls).
Note: There may be a mix of recognized and unrecognized user interface controls depending on the author-supplied content.
(Source: Glossary definition of *content user interface* [http://jspellman.github.io/UAAG/Implementing-UAAG20/#def-content-ui])

- Communication with platform accessibility services: 
When the success criterion will be applicable to programmatic communication to a programmatic interface that is engineered to enhance communication between mainstream software applications and assistive technologies (e.g. MSAA, UI Automation, and IAccessible2 for Windows applications, AXAPI for Mac OSX applications, Gnome Accessibility Toolkit API for GNOME applications, Java Access for Java applications). On some platforms it may be conventional to enhance communication further by implementing a DOM.
(Source: Glossary definition of *platform accessibility service* [http://jspellman.github.io/UAAG/Implementing-UAAG20/#def-access-platform-arch]) 

- Configuration settings: 
When the success criterion requires that a particular configuration setting exist (e.g. that the user be able to turn a functionality on or off) or the success criterion relates to configuration settings, in general.

- Configuration settings (optional): 
When the success criterion requires functionality, but lets the developer decide whether the functionality will always be turned on or whether it could be controlled by a configuration setting.


Linking:
-----
All of the "Applies To" tags will link to the appropriate item in this section.


Cheers,
Jan

(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
OCAD UNIVERSITY

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca

Received on Thursday, 11 September 2014 17:33:00 UTC