RE: Your comments on the W3C User Agent Accessibility Guidelines working draft

Here is our response to the UAAG comment disposition.  I apologize for the late response.  Both Kelly and myself were out for large parts of last week due to unforeseen circumstances.

MS01: Definition of "User agent" should not include "web-based user agent"
We do not agree that a "web-based user agent" is a legitimate concept.  If it's web-based, it's content.  WCAG was written to cover web applications, including those that render content.  UAAG should not be covering that.   The target audience of this document should be user agent implementers, not end users.  The fact that end users don't understand how it is engineered is not relevant.

MS02: Separation of assistive technologies from user agents We accept the UAAG disposition.  However, we think it would be useful to take some of the text from your response to our comment and add it as a note in the document.

MS04: Delineate between content and browser We accept the UAAG disposition

MS03: Separation between browsers and OS We still believe that 1.4.1 should be separated into a level A criterion to pick up the OS settings where they exist, and level AA or level AAA criterion to go beyond the settings available on the platform.

MS05: Examples in the implementation document do not make distinction of content, browser, assistive technologies, and OS We still feel that this area of UAAG is fundamentally flawed.  UAAG needs to clarify what should be done in the browser, where the browser should rely on OS features, where it should go beyond them, and what should be done by AT.  The target audience of this document should be user agent implementers, not end users.  We don't believe it to be relevant that end users may not understand the engineering considerations of the accessibility stack.

MS06: Setting realistic Level A, AA, and AAA success criteria We think that many of the current A success criteria do not meet the test of a,b,c,d as defined in our original comment.  For example:

1.1.1 ok
1.1.2 what requirement of WCAG does this support?  Also, this would be better handled by AT than by a browser.
1.1.3 What requirement of WCAG does this support?
1.1.4, 1.1.5 are AA
1.1.5 first two bullets seem like A to support WCAG 1.2.  I believe the third bullet is required under CVAA but not WCAG, so can stay AA
1.1.6 is also required by CVAA, but can stay AAA
1.2.1 is good at AA.  Repairing missing content by definition is dealing with content that doesn't meet WCAG.
1.2.2 good at AAA for the same reason
1.3 should be refactored so that level A requires picking up OS settings for these things where they exist, and levels AA or AAA would require adding features beyond what is available on the OS settings, as described in current 1.3.1 and 1.3.2
1.4 Should be refactored so that level A requires picking up OS settings for basic text settings where they exist, and levels AA or AAA would require adding features beyond what is available on the OS settings
1.4.2 should be handled by AT
1.4.3 should be handled by AT
1.4.4 is ok at AA
1.4.5 why is a global setting lower priority than a per-object setting?  It seems far easier to implement and more useful.
1.5.1 ok at A
1.6 levels ok
1.7 user style sheets should be AAA.  They are not a feasible solution.  They don't work with the modern web, where styles are used for UI configuration, and they are too technical for typical end users.  Style sheet modification makes some sense as a programmatic interface available to AT developers, but not as an end-user feature.
1.8.9 seems difficult to implement and should be AAA
1.8.14 will break a lot of content and is a bad idea. It is also too technical to be an end user feature, and should only (maybe) exist as a programmatic interface for AT developers.  If it is determined that it can be implemented without breaking things, then AAA The rest of 1.8 levels look ok
1.9 levels look ok
1.10.1 should not be an end user feature, but a programmatic interface for AT developers.  It is much too technical, especially since it is targeted at users who have trouble understanding the simpler user-facing renderings of those relationships.  We could get behind level A for creating an API for AT to use, but it should either be AAA or gone as an end user feature.
2.1 looks ok
2.2.3 is a bad idea.  Defaulting to source order is a bug, not something to be codified. You are preventing browsers from implementing navigation based on visual rendering, which many add-on AT products support, and which is often a better solution.  If it must be kept, make it AAA The rest of 2.2 looks ok for level
2.3.1 is not always a good idea.  Some content has too many enabled elements to provide keyboard shortcuts to them all.  If it stays, it should be AAA, as it is not necessary for meeting WCAG.
2.3.2 see 2.3.1
2.3.3, .4. ,5 are ok at AA
2.4 looks ok for levels
2.5.1 is vaporware, and should be AAA or removed.  If we knew how to do this, we wouldn't need WCAG or SVG ARIA.
2.5.2 could be A.  It is needed to meet WCAG 1.3
2.5.3 is good at AAA
2.6 should be AAA or advisory.  Its implementability is an area of open debate.  It's less vaporware than 2.5.1, but still not a solved problem.
2.7 needs a level A about picking up OS settings.  The rest look ok for level
2.8.1 ok at AA
2.9 ok
2.10 can't be A.  We are not at all sure this is implementable.  The browser does not always know how something will flash.  Flash rate is dependent on script, system state (is my swap file full?  It will run slower) and hardware.
2.11 looks ok
2.11.7 might make more sense as AT than mainstream UA requirement
2.12.2 should be A.  It is required for WCAG and is easy to implement
2.12.3 should be at least AA, maybe A.  It is required for WCAG, and is easy to implement on any platform with an accessibility API.  Have you gotten feedback that it's hard?
3.1.2 should be AA. It may be difficult to implement.  I am not aware of any browser that currently support it.  Requiring confirmation is easy, but greatly decreases usability.  
3.1.4 should be A.  All the browsers support it.
3.2 looks ok for levels
4.1 looks ok.  
4.1.4 DOM could be AA.  Providing AT developers a way to go around accessibility APIs is not always a good thing, as it results in inconsistent user experiences based on the AT developers interpretation.
5.1.1 and 5.1.2 there is no such thing as a web-based user agent.  see other comment.  If it's web-based, it's content, not a user agent.


MS07: Think beyond desktop computers
We accept the UAAG disposition

MS08: Realistic expectation of the end users We still do not agree that user stylesheets are a reasonable end user feature.  User Stylesheets are too technical to be an end user feature.  They make sense only as a programmatic interface available to AT developers.  We would be satisfied if the references to "users can" were changed to "AT can" or "developers can".

MS09: Subjectivity must be eliminated
We accept the UAAG disposition


Thank you for your consideration.

Cynthia C. Shelly

-----Original Message-----
From: Jeanne Spellman [mailto:jeanne@w3.org] 
Sent: Thursday, September 25, 2014 12:14 PM
To: Alex Li
Cc: public-uaag2-comments@w3.org
Subject: Your comments on the W3C User Agent Accessibility Guidelines working draft

Alex,

Thank you for your thoughtful comments on the User Agent Accessibility Guidelines (UAAG) 2.0 Last Call Working Draft.  The working group (UAWG) has considered all comments and has published a new working draft of UAAG 2.0 that integrates the input of all the comments. Many were interlocking or had implications beyond the text that was the immediate source of the comment. See the list of changes in the Status section for an overview of changes and the link to more detailed list of changes.
    Your original comments: 
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0002.html
    UAAG 2.0: http://www.w3.org/TR/2014/WD-UAAG20-20140925/
    UAAG 2.0 Reference: 
http://www.w3.org/TR/2014/WD-UAAG20-Reference-20140925/


The Disposition of Comments spreadsheet lists all of the comments and the UAWG response for each one. You may find your comments by searching for the comment number starting with: MS
    http://jspellman.github.io/UAAG-LC-Comment/

Please respond to the publicly archived list (reply all to this email) by 10 October 2014 to let us know if our response to your comment is acceptable or not. You may also file Issues in Github.  In case of disagreement, you are requested to provide a specific solution for or a path to a consensus with the Working Group. If such a consensus cannot be achieved, you will be given the opportunity to raise a formal objection which will then be reviewed by the Director during the transition of this document to the next stage in the W3C Recommendation Track.
    email: public-uaag2-comments@w3.org
    archive: http://lists.w3.org/Archives/Public/public-uaag2-comments/
    Github: https://github.com/w3c/UAAG/issues

If we have not heard from you by 10 October 2014, we will assume that our response is acceptable.  This Working Draft is open for new or additional comments until 17 October, 2014.

UAWG thanks you for your contribution to improving this working draft. 
Your input has helped significantly.  We hope you will continue to comment on this draft and encourage the Internet Explorer development team to implement UAAG 2.0.

Regards,

Jim Allan, Co-Chair
kelly Ford, Co-Chair
Jeanne Spellman, W3C Staff Contact

Received on Tuesday, 21 October 2014 20:11:23 UTC