Comments on UAAG from Microsoft

Note: The comments were sent to Jeanne's personal email. Although Jeanne requested permission to make them publicly archived, no permission was received. The email is archived at W3C under team-only access. For historic purposes, Email from Cynthia Shelley, 30 April 2015 - Not public

1. Access to the DOM should not be required. This is a quirk of implementation, and not a design. It is far better to move both the browsers and the AT makers towards an API-based approach. Having each AT interact directly with the DOM makes for a brittle and inconsistent experience in a world with many operating systems, browsers and AT products. It contributes to the impossibly complex test matrix for web sites trying to implement accessibility. The industry is moving towards APIs. This cannot be single-A. We would prefer that it be removed all-together.

UAWG response: We posed this question to 4 screen reader engineers. They all agreed that they would prefer to work with the accessibility APIs, but that the AAPIs used by IE are too limited and that they need the DOM as a backup. UAWG has rephrased to clarify that the DOM should be a backup when the AAPIs are insufficient.

2. User Style Sheets should not be required to be exposed to the USER. It is fine to expose this to developers (both web at AT), but it’s not a workable solution for any but the most technical users, who would be able to access it via a developer path anyway. (relates to 1.7). Change to developer, or remove, or make AAA.

UAWG response: There are still a core of low vision users who require user stylesheets for web content. We've altered the wording to make it clearer that this is not just about style sheets in the CSS-specific meaning, but also includes other mechanisms for that could include graphical approaches that would be easier for the average end user. Being able to move user stylesheets between users allows more technical users to support the less technical user.

3. Picking up operating system user settings should be level A. Providing them directly in the browser should be AA. (relates to 1.3.1, 1.4, 2.7, 5.1.3). We can probably live with this one as-is, but would prefer to see a stronger requirement to pick up OS settings. This is important for users to be able to configure the experience for their computer in one place.

UAWG response:We did could not find enough examples of browsers picking up the OS levels to justify making it A. For a success criterion to meet [UAAG level A], it blocks some people with disabilities from getting information or accomplishing a task, and/or it is relatively easy for developers to implement or is common in the existing user agents. UAWG did not think that picking up operating system user settings met those criteria for assigning level A.

4. We still don’t like the idea of a web-based user agent. Your changes made this somewhat better, and we could probably live with it.

UAWG response: We appreciate your willingness to live with it. We think it is important and have use cases for it.

Detailed Feedback

1.1.2 Does not support a WCAG requirement, and therefore should not be single-A.

UAWG response: UAWG disagrees because users need discovery of alternative information,(e.g. long desc extension​, caption, audio description indicator in media players).

1.1.3 Does not support a WCAG requirement, and therefore should not be single-A

UAWG response: People want to turn off images or media because it blocks them from accomplishing what they need to do. Because this is a blocking issue, UAWG wants to keep this at level A.

1.3.1 Should not be single-A. Only picking up operating system settings should be single-A, not providing settings in the browser. 5.1.3 is related, but not crisp enough.

UAWG response: 1.3.1 does not require the user agent to provide it's own user interface for adjusting the settings. If the user agent wants to simply respect user-settings from the OS level, that is fine. However, if the OS does not allow the user to set one of the listed values (e.g. distinguishing visited from unvisited links) then the user agent would be required to provide its own user interface for this user option.

1.4.5 should be single-A, the other items in 1.4 AA

UAWG response: If the UA does not provide an option to pick up default text settings from the OS, it will not block users from accessing any content, it merely makes it a bit more work for the user to configure the UA to have equivalent settings. That extra one-time effort does not seem to be enough to justify making it Level A.

1.7 User Style Sheets should not be a requirement, and certainly not at Single-A. A mechanism for AT developers to override styles makes sense. CSS is too engrained in modern sites, and messing with it via user stylesheets is likely to result in broken sites. This is not something that most end-users can manage.

UAWG response: However, there are users that need the ability to customize sites at an element level. UAWG rephrased 1.7 so the browser can provide a mechanism, not just user stylesheets. See the response to #2 above.

1.8.14 is better, and we can live with it. It is still likely to cause broken sites and I’m still concerned about user experience.

UAWG response: We expect that the people who need it will know or learn how to manage it.

2.7 make 5.1.3 Single-A, and that would cover our objections

UAWG response: 5.1.3 is A. We left 2.7 as is.

4.1.4 do not require DOM access. If it must be in there, make it AAA. It’s a quirk, not a feature.

UAWG response: See #1 above