Should SC 3.2.6's "role" be "Name, states, roles, and values" from SC 4.1.2? Or is the name of the SC wrong?

[peterkorn]

SC 4.1.2 uses the terms "name", "role", "states", "properties", and "values" when defining things that can be programmatically determined/set for use by AT. Should that same or similar formulation be used in SC 2.3.6? Status changes are more commonly a change in state or value, and particularly NOT a change in role. Stuffing it in role will cause problems for AT.

Then again, upon reading Understanding, perhaps the real problem is the name of this SC - it should perhaps be "Status Messages" instead of "Status Changes" (which sounds too much like "State Changes" like changing from checked to unchecked or a progress indicator changing its value). A draft How to Meet for this would be helpful (e.g. showing the correct ARIA role for a status message).

[awkawk]

Thank you for commenting. For more information about how the AG WG will process this issue, see the following:

• Issue Processing - How the WG will discuss the issue
• Issue Resolution - Identifying and responding to the official WG response
• Issue Notifications - How to limit notifications from GitHub

[DavidMacDonald]

I could live with the change to "status messages". A major technique would be live region roles

• role=alert
• role=log
• role=marquee
• role=timer
• role=progressbar
• role=status

[awkawk]

Edited title to point to 3.2.6 (there is no 2.3.6) - @peterkorn if incorrect, please fix...

[awkawk]

I've given this some thought as well and think that changing the title to "Status Messages". We might also want to change the SC text lightly (and in an editorial sense) to:

From:
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.

To:
In content implemented using markup languages, status messages can be programmatically determined and can be presented to users by assistive technologies without receiving focus.

The "role or properties" is in the technique space and might limit possible solutions.

[DavidMacDonald]

Status changes are more commonly a change in state or value, and particularly NOT a change in role.

role="alert" ... we wouldn't want an alert role to be persistent when there is no alert message... we would use the role="alert" in some cases to notify the user of a change.

[mbgower]

[Draft official response]
Thank you for your comments. The working group is scheduled to review the Understanding document for Status Changes, and will consider your comments related to both a change in the SC name and the use of "role" in the language during that discussion.

[awkawk]

Current issue that is a concern is whether the scenario where a screen reader user can find information with the virtual focus and whether that will meet this SC (it shouldn't). Thoughts?

[DavidMacDonald]

There is no requirement in the current SC to be able to navigate to the location of the announced text.

[mbgower]

These more recent comments appear to refer back to parts of the thread that precede the draft official response. A CFC to rename this SC to Status Messages is a day away from closing; I'm hoping that that change will addresss @peterkorn's concern, since he suggested renaming in his second paragraph.

However, I did want to take a moment to address the suggested wording change that has come up since then in this thread.

In content implemented using markup languages, status messages can be programmatically determined and can be presented to users by assistive technologies without receiving focus.

My concern with the above suggested rewording is that, given the reality of how virtual cursors work with screen readers, any text would pass this, because:

1. anything appearing in so much as a paragraph element is programmatically determinable and
2. an AT can present any of this information to the user, via the virtual cursor, without receiving focus.

This means that a key objective of the SC -- allowing users to be notified about status messages as they change -- would be lost. An author could meet the SC with any existing implementations, leaving the user to hunt around trying to find what new text may or may not have appeared.

The suggested rewording also implies there is some attribute that makes something programmatically determinable as a status message. There isn't because there is no status_message element or property. The existing attributes which may be used on a status message (i.e., aria alerts) could also be used on something that doesn't meet the definition of a status message.

The existing SC wording requires that the means by which the element is programmatically determinable is what results in the message's ability to be presented via AT. In example, giving a paragraph of text which meets the definition of a status message a role of alert meets the objective. Similarly, providing an element containing a status message with an aria-live attribute (set to something other than "off") also achieves this. If the role or property does not result in the status message being presented to the user, then it does not meet the SC. That is a very different scenario than would occur with the suggested rewording.

[mraccess77]

I agree @mbgower the change renders the SC useless as we already have this through 1.3.1.

[awkawk]

[Official WG Comment]
Thank you for the comment. We have made a change to move 3.2.6 Status Changes to be 4.1.3 Status Messages per your suggestion, and will clarify the intent further in the Understanding document and in techniques. See the change at: https://rawgit.com/w3c/wcag21/master/guidelines/index.html#status-messages

[awkawk]

The WG decided on the above response, so we changed the text in the comment containing the proposed response to read "[Official WG Response]". Please confirm is you are satisfied with the response within 3 days. If we haven't heard a response by then we will regard the resolution as satisfactory.