RE: Proposal: 3.3.2 and OCAD42 comment

Hi Jim,

Greg's message gets at pretty much the same issues we struggled with in ATAG. However, we felt that the value of acknowledging the nuance in how features get explained was worth the loophole risk.

Cheers,
Jan

(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957
Inclusive Design Research Centre (IDRC)
OCAD University
________________________________
From: Jim Allan [jimallan@tsbvi.edu]
Sent: September-22-13 6:07 PM
To: Greg Lowney
Cc: WAI-ua
Subject: Re: Proposal: 3.3.2 and OCAD42 comment

perhaps Jan can chime in on this. the wording I submitted was a UAAG label changed for the exact text in ATAG. The ATAG wording (which is in LC if not CR), especially the 4) not used by users was requested by industry.
Jim


On Sun, Sep 22, 2013 at 11:56 AM, Greg Lowney <gcl-0039@access-research.org<mailto:gcl-0039@access-research.org>> wrote:
I have some concerns about the wording, although these are tricky concepts to pin down. I'd appreciate hearing others' thoughts on them.

I not sure I agree with list item 4 ("Not Used by Users"). In the example given, one can easily imagine sophisticated end users, rehab professionals, and developers of assistive technology would want to know whether or not a user agent supports platform accessibility services, and documenting this would make it easier for them. (Knowing the claim would not necessarily mean it will be compatible with a particular piece of assistive technology, so testing would still be required, but knowing that the user agent acknowledges that it isn't supported may save a lot of effort.) On the other hand, one could argue that it's documented by the UAAG20 conformance claim for the user agent. Any idea which SC would allow this exemption?

Also, regarding list item 2 ("Described in the User Interface"), could that be interpreted overly broadly, to include things that are, arguably, implicitly documented in the user interface, or which the developer considers self-explanatory? After all, almost every feature is described to some extent, even if it's just a cryptic name for a menu item or check box. An option might also be buried way down in an obscure section of the user interface, even though its label may seem self-explanatory once one (finally) finds it. I'd think that would violate the intent of the SC. On the other hand, I admit there can be cases where there really is little useful to add beyond the labels in the UI. (It would be almost as bad if the option was documented in a context-sensitive help that's only available once one has (finally) found the option, although the latter case is addressed by the 3.3.4, Centralized View, AAA). Perhaps we could address this in the Intent section for the SC, by going into a bit more detail about what is expected, particularly what is meant by "explained", and perhaps providing a negative example.

    Thanks,
    Greg


-------- Original Message --------
Subject: Proposal: 3.3.2 and OCAD42 comment
From: Jim Allan <jimallan@tsbvi.edu><mailto:jimallan@tsbvi.edu>
To: WAI-ua <w3c-wai-ua@w3.org><mailto:w3c-wai-ua@w3.org>
Date: 9/17/2013 8:45 AM
we missed a comment...
please comment on list
existing

3.3.2 Document Accessibility Features: All features of the user agent that meet User Agent Accessibility Guidelines 2.0 success criteria are documented. (Level A)

comment OCAD42: The corresponding ATAG2 SC was rewritten: http://www.w3.org/WAI/AU/ATAG20/#sc_a421

OCAD42 [needs proposal]

Proposal: using ATAG as a model, rewrote for UAAG. The ATAG definition as based on feedback from vendors. It is more comprehensive. I believe the IER is ok even with the rewording.

3.3.2 Describe Accessibility Features:

For each user agent feature that is used to meet UAAG 2.0, at least one of the following is true: (Level A)

    (a) Described in the Documentation: Use of the feature is explained in the user agents's documentation; or
    (b) Described in the Interface: Use of the feature is explained in the user agent user interface; or
    (c) Platform Service: The feature is a service provided by an underlying platform; or
    (d) Not Used by Users: The feature is not used directly by users (e.g., passing information to a platform accessibility service).

--
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315<tel:512.206.9315>    fax: 512.206.9264<tel:512.206.9264>  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964




--
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964