Re: IBM Feedback v2

Hi Sueann,

Thanks for forwarding these comments on.

I have included a first crack at addressing them below (see JR):


Sueann Nichols wrote:
> Hello,
> 
> Regrets for the 12/21 meeting.
> 
> Below is additional feedback from IBM:
> 
> *Section specific comments*
> 
> 1. *Guideline A.1.2* This is a general comment about the non web 
> accessibility compliance points: There are no restrictions on what an 
> accessibility standard is. It is user defined now. Consequently, the 
> evaluator could define their own compliance claims.

JR: That's correct, but I don't think we can come up with am objective 
restriction that is general enough to cover all platforms. In order to 
clarify this point, I suggest we reword the intent as follows:

"Intent of Success Criterion A.1.2.1: The intent of this success 
criterion is to ensure that authoring tool user interfaces that are not 
web applications are accessible to authors with disabilities. In 
formulating a requirement that would best fulfill this intent, the 
Working Group decided upon a requirement to follow and cite the 
accessibility standards and platform conventions that already exist for 
many platforms. It was decided that this was the best approach because:
(a) the requirement to "cite in the conformance claim", which is 
published on the Web, would mean reputable developers would refrain from 
implementing obscure or weak requirements.
(b) the "accessibility standards" wording allows developers the scope to 
harmonize with accessibility legislation in their markets
(c) "platform conventions", by their nature, include platform-specific 
details such as API calls and look-and-feel examples that generic 
software guidance cannot.
(b) "accessibility standards" and "platform conventions" will continue 
to progress even after the publication of these guidelines.

Note: Developers should take note of the documents listed in the 
"Related Resources for Success Criterion A.1.2.1" section, below. Unless 
extenuating circumstances exist (e.g., a document has been superseded, 
the platform has undergone major architectural changes), the listed 
resources should be assumed to be relevant to the platforms listed.


> 2. *A.1.2.1* In WCAG, it is not a requirement to make a conformance 
> claim. This provision seems to require that authoring tools make a 
> claim. Suggest removing "and cite in the conformance claim)" and adding 
> an additional sentence: "If an ATAG 2.0 conformance claim is made, the 
> claim should cite the accessibility standards and/or platform 
> conventions that were followed.

JR: Agreed.


> 3. *A.2.1.1* Define "accessible" as used in the context of this provision.

JR: I wonder if we could reword instead:
"A.2.1.1 Recognized Alternative Content: If recognized alternative 
content is available for editing view *content renderings*, then the 
alternative content is provided to the author(s)."


> 4. *A.2.2.2* The use of "and" at the end of each item in the list seems 
> redundant with the wording of the provision ("any of the following").

JR: This is the convention used by WCAG 2.0.


> 5. *A.2.2.2* If you are accessing text, you need access to the caret 
> position, and the selected text. Does use of a text view preclude 
> embedded objects? If not then they need to be accessible as well.

JR: Should we add "caret position" and "the selected text" to the list?


> 6. *A.3.1.1* The provision is repeated. Why is this provision needed? It 
> is already required by provision A.1.1.1.

JR: The WG is currently discussing this SC, but I think we should keep 
it because of the fundamental importance of keyboard access to 
accessibility. Also, remember that ATAG applies to non-Web apps. Maybe 
we add the line: "Web-based authoring tools will already be required to 
meet this success criterion as part of a A.1.1.1."


> 7. *A.3.2.2* Why is this provision needed? It is already required by 
> provision A.1.1.1.

JR: As above, remember that ATAG2 applies to non-Web apps. Maybe where 
necessary we could add the line: "Web-based authoring tools will already 
be required to meet this success criterion as part of a A.1.1.1."


> 8. *A.3.2.3* This provision is an example of a WCAG requirement that is 
> made for stringent in ATAG. There's no issue with doing that when there 
> is a good reason which in this case, I think there is. But the problem 
> is that the authoring tool developer may have already implemented one of 
> the other strategies that are allowed by WCAG. Somewhere ATAG should 
> call out where there are provisions that override WCAG provisions. Maybe 
> in A.1.1.1?

JR: I agree that A.1.1.1 might be a good place to say something like: 
Some success criteria in Part A may be more stringent than similar 
requirements than WCAG 2.0. This may occur because authors need to be 
able to edit all web content, while certain types of web content (e.g., 
decoration, invisible content) are not as important to an end user's 
experience.


> 9. *A.3.2.3* This checkpoint only says to stop. Per WCAG 2 you want to 
> be able to Pause and Hide content.

JR: Maybe we should change "stop" to "pause". We don't want "hide" 
because the author needs to see all the content the end user will.


> 10. *A.3.4.2* This should include role types such as ARIA roles.

JR: Agreed - but maybe this should be a new success criterion:
A.3.4.X Navigate By Element Role: If an editing view displays a 
structured element set that includes element roles, then the author(s) 
can move the editing focus forward or backward to the next instance of 
an element with the same role. (Level AA)


> 11. *A.3.4.2* There should be a navigate by relationships: labels, 
> controls, describedby, etc. should those features be supported.

JR: I'm open to this, but we would need wording. Relationships might 
also need to be something to call out in Part B.


> 12. *A.3.4.3* Should be scoped to structured element sets that have 
> heading elements. Suggest changing "If an editing view displays a 
> structured element set" to "If an editing view displays a structured 
> element set that includes heading elements".

JR: Agreed.


> 13. *A.3.4.4* Parent and child need clarifying. Suggest " *Parent:* The 
> owning element" and *"Child:* The first owned element" ARIA or HTML 
> might have some better wording.

JR: I agree with that wording.


> 14. *A.3.6.1* and *A.3.6.2* What about auditory settings? Most authoring 
> tools don't have them but if they do, shouldn't the preference setting 
> be saved?

JR: The definition of "display setting" 
(http://www.w3.org/WAI/AU/2009/ED-IMPLEMENTING-ATAG20-20091221/#def-Display-Settings) 
already includes display settings (audio), display settings (visual) and 
display settings (tactile). In both intent sections I suggest:
"display settings" => "display settings (visual, audio, tactile)"


> 15. *A.3.7.2* See comment on A.1.2.1 regarding requiring conformance 
> claims (item a). 

JR: So that would be:
"If an ATAG 2.0 conformance claim is made, the claim should cite the 
existing user agent used."


> Item b may not be possible if the author has not met 
> the requirements of WCAG (included text alternatives, provided 
> structural markup, etc.) 

JR: The actions of the author don't have a bearing here, so (b) is still 
possible.


> Is item c referring to UAAG version 2.0? If 
> ATAG 2.0 is on track to finish first, it may be problematic to reference 
> a standard that is not yet complete and I don't think we want to be 
> referencing UAAG 1.0 which may be outdated.

JR: Looking at A.3.7.2, I think we should remove point (b) because ATAG 
Part A really isn't written as proper guidelines for user agent 
developers. Then I suggest rewording the intent:

"The intent of this success criterion is to ensure that preview features 
strike a balance between giving authors with disabilities an accessible 
means of previewing the web content that they are editing and not giving 
those authors an unrealistic impression of how end users with similar 
disabilities will actually experience that web content in their own user 
agents. In other words, it is not necessarily useful to present a user 
experience with web content as a "preview" when it is much more 
accessible than the actual usage of the web content would be in an 
existing user agent.

The most straightforward way to meet this requirement is for authoring 
tools to simply implement preview features using user agents that are 
already in use by end users - see (a). This might be done in several 
ways, including by opening the web content in a new window or by making 
use of a user agent widget nested within the authoring tool's own user 
interface.

On the other hand, if a preview is being developed that is already a 
departure from existing user agents, the W3C User Agent Accessibility 
Guidelines must be followed - see (b). At the time of publication, UAAG 
version 1.0 is a W3C Recommendation and version 2.0 is under 
development. Note: Developers may develop a preview that does not meet 
(b) as long as (a) is still provided as an option




Cheers,
Jan

Received on Monday, 4 January 2010 20:39:30 UTC