search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Success Criterion 3.2.6 Status Change - Scope is too narrow in current Editor's Draft & Final Draft #605

Closed SuzanneTaylor closed 6 years ago

SuzanneTaylor commented 6 years ago

"In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus."

This doesn't cover situations where complex information is added to the screen and AT users don't know it appeared. This draft:

The need (and reasonable implementation) is not limited to markup languages... An interactive book implemented in Swift or Objective-C for iOS can certainly easily provide notification through AT, for example.

Perhaps something like this?

If a change of content causes new content or functionality to appear on the screen, at least one of the following is true:

joshueoconnor commented 6 years ago

Relates to https://www.w3.org/TR/2017/WD-WCAG21-20171207/#status-changes

mbgower commented 6 years ago

Thank you for your detailed issue.

The initial goal of this SC was broader in scope but various considerations were identified which led the authors to keep the scope contained. After carefully reviewing your feedback, the working group believes the existing wording should remain in place. Instead, the intention is to list Best Practices and Advisory Techniques which could address broader Changes of Content.

Here are specific responses to some of the points raised in the issue:

addresses the implementation of status messages, but doesn't say there needs to be a status message (essentially you can pass by not having a status message)

That is by design. WCAG has a history of defining content requirements when the content is present.

Any attempt to make status messages a requirement will inevitably lead to poor implementations that make applications unusable by screen reader users -- the exact opposite of the goal. It was felt that significant scrutiny is given by designers to information they add to the UI. Restricting the SC to cover such information, where it does not alter a user's context (no change of context), seemed like a way to ensure messages were appropriate and limited.

indicates that the info be presented by AT without receiving focus

That is not exactly what the SC is saying. It defines status messages as items that do not take focus (change of content without being a change of context), and then makes requirements where such items exist. The SC does not restrict messages from being displayed in a dialog, for example. Such a message is a change of context and so does not meet the definition of a status message, and so is not covered by it (being instead covered by 4.1.2).

The need (and reasonable implementation) is not limited to markup languages... An interactive book implemented in Swift or Objective-C for iOS can certainly easily provide notification through AT, for example.

The working group spent considerable time debating removing the markup language restriction. In the end, the group felt there is not enough research, evidence or best practices to apply this to other technologies. WCAG 2.0 and 2.1 apply to content at a URL. However, we'd be glad to have you propose a technique for how to apply this to other technologies that we could add as a best practice for those who may be trying to apply WCAG to content not at a URL.

This last section will address your proposed alternative wording.

If a change of content causes new content or functionality to appear on the screen, at least one of the following is true:

We believe this effectively means "For each change of content at least one of the following is true:" We had several iterations with a similar approach to this, covering similar scenarios. All were abandoned due to nuances of implementation or testing. Some of those have been identified below.

The new content appears directly after the control that triggers it in the reading order.

If the new content is a user interface control, this will likely be detected by screen readers. (Although issues with latency can cause focus issues; for example, where the user's act of leaving a control triggers a change, the user's focus may move to the next existing item before coding updates the DOM, thus the user bypasses the new control.)

But what if the new content is an element that does not take focus? If the screen reader user has previously perused the page and is now navigating by pressing Tab, how is the screen reader user to know the new information exists? Since an author could use this bullet to bypass notifying users (the first bullet), it seems to lose a key accomplishment of the current SC language.

For content that is updated on a regular basis, or is updated so frequently that status messages may be disruptive, the user is advised of the type and frequency of updates (e.g. through a section heading or label)

These "regular basis" and "disruptive" parameters would have to be defined in a way that was testable. The manner of advising the user would itself be quite difficult to establish in language that ensured it was testable. There is danger that this would be poorly implemented and would degrade the experience for a screen reader user. Perhaps in future iterations of WCAG we can find standardized and testable ways of notifying users of content that updates frequently without this risk of interfering with their experience.

Some examples of interactions which may not be covered/considered by your alternative proposal:

SuzanneTaylor commented 6 years ago

thanks for the detailed response! (Yes, I had taken language from earlier draft and tried to restore it with minor adjustments as I had been happy to see it in there & I thought it was well done.) I see your points though - oh well. 3.2.6 is a nice addition as-is