Update normative wording of 4.1.3 and definition of "status message"

[patrickhlauke]

The current normative wording for 4.1.3 Status Messages has ... issues:

• the mention of through role or properties would disallow the use of upcoming/new solutions, such as ariaNotify, since they are programmatic but do not rely on roles/properties
• the preface of In content implemented using markup languages limits the scope of this SC, which results in 4.1.3 not being applicable in cases where WCAG is being applied to other technologies (WCAG2ICT) - the current https://www.w3.org/TR/wcag2ict/#applying-sc-4-1-3-status-messages-to-non-web-documents-and-software notes that the SC "applies as written", meaning that in non-markup-language scenarios, it doesn't ... but then provides a note saying it sure would be nice if it did ("there is still a user need...") - and this handwave is also present in current draft versions of the upcoming EN 301 549 v4.1.0; many auditors currently "ignore" the markup language part when evaluating native mobile/desktop apps against WCAG, and take the fundamental principle - that AT must announce status messages when these don't receive focus - regardless

In addition, this PR tweaks the definition of what a "status message" is - there have been discussions (such as #4672) around the fact that the definition as it currently stands can actually apply to a lot more than just what was originally intended (e.g. if, after activating a control, a table is updated ... is the whole table a "status message"? based on the current definition, it can be seen as such). the update here tries to more specifically define status messages as discrete/explicit messages (excluding the "implicit status message" given by content, like a table, being updated). it also moves out the whole part about change of context - a status message is a status message, regardless of whether or not it changes context. this part about context change was already present in the normative wording of the SC, but has been reinforced.

I believe this change, while quite deep, is backwards-compatible with the existing/current version of the wording the way it was originally intended

EDIT: Reintroduced the limitation of scope by adding "In technologies that support it" as a preamble

---

Current normative wording (SC + term)

Current normative wording of the SC, the definition, and "grafting" (with tweaks from singular to plural) that definition into the normative wording:

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.

change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors

In content implemented using markup languages, change[s] in content that [are] not a change of context, and that [provide] information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

---

Proposed normative rewording (SC + term)

This PR proposes the following change to the SC, the definition, and shows the resulting "grafted" version (with tweaks from singular to plural) :

In technologies that support it, status messages that appear dynamically (without a change of context) can be programmatically determined without receiving focus, so that they can be presented to the user by assistive technologies.

discrete piece of content whose only purpose is to provide information to the user on the results of an action, the waiting state of an application, the progress or completion of a process, or the existence of errors

In technologies that support it, discrete piece[s] of content whose only purpose is to provide information to the user on the results of an action, the waiting state of an application, the progress or completion of a process, or the existence of errors that appear dynamically (without a change of context) can be programmatically determined without receiving focus, so that they can be presented to the user by assistive technologies.

---

• SC diff
• Term diff

Closes #4676

This PR supersedes #4840 (as that one originally only tried to update the definition, but further discussion on the PR made it clear that there's more fundamental work to be done, if we're already aiming for a normative change)

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	5bd1e59
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/69d04910a9b6ed0008c11dda
😎 Deploy Preview	https://deploy-preview-4952--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[detlevhfischer]

Very nice to see the reference to content implemented using markup languages removed (in the light of applying the requirement to mobile apps)

[bruce-usab]

I agree that it would be good to remove “in content using markup languages” here and elsewhere. It gives too much of a free pass to mobile and WCAG2ICT. As I noted in previous draft (#4840) excising “changes that are not a change of context” from the defined term is tremendously helpful.

[bruce-usab]

Just FYI, from editors draft of WCAG2ICT:

4.1.3 Status Messages — Depends upon status messages being programmatically determinable using role or properties.

As @scottaohara noted, limiting authors to only (ARIA) role or properties is counter to current best practices.

[bruce-usab]

@detlevhfischer provided current formulation of 4.1.3 in EN 301 549 V.4.1:

Where ICT is, or includes, non-web software that provides a user interface, and the software includes functionality that is not closed to programmatic access of information by assistive technologies, and the functionality that is not closed supports status message notifications, status messages from the functionality that is not closed can be programmatically determined so that they can be presented to the user by assistive technologies without receiving focus.

The WCAG success criterion is restricted to content implemented using markup languages, but the WCAG2ICT Task Force has concluded that even “where status messages are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus.”

[bruce-usab]

On TF call we noted that moving focus incorrectly should not be a loophole. @baldino-m suggest updating Understanding to allow for change of context to the right place.

[patrickhlauke]

to expand, at TF meeting concern was raised that the "without causing a change of context" part didn't explicitly say that the status message is/was the one that received focus. so the gap is: a status message is updated, but focus moves SOMEWHERE ELSE on the page, then it would still be exempted. this gap is already present in the current term/normative SC wording, but just "hidden" by being buried in the definition.

@scottaohara raised the point that ariaNotify is going to be the de-facto solution that ARIA-WG is pushing, and aria-live will be legacy, so at the very least removing the "role or property" part of the normative wording is essential, as otherwise the SC won't be applicable to reality.

@giacomo-petri suggested that now that the "In markup languages..." part is removed, it would still be prudent to have wording along the lines of "In technologies that support it..." or similar, to provide some guard rails.

Will iterate on this and bring it back to the group in future.

[bruce-usab]

See preview diff of SC 4.1.3 and revised glossary term.

[patrickhlauke]

Made changes based on the discussion at the last TF call:

• added a "In technologies that support it" preamble
• simplified the rest of the sentence to spell out that this means "status messages that don't receive focus". any other changes of context would already be out of scope based on the new definition that talks about DYNAMIC changes of content (i.e. loading a new page or similar would not be DYNAMIC anymore)

[bruce-usab]

On TF call 4/3, we decided to work on this more. In particular the example of a confirmation message -- both as a new page and as a status message -- would be a clarifying example.

[patrickhlauke]

Had a little flash of inspiration after our meeting 33b5a03

[bruce-usab]

@patrickhlauke I think you need either an i.e. or e.g. right after the opening parenthesis. At present, “without a change of context” can be read either way (both seem like they work, but I think i.e. is what you mean) — or even as a constraint/modifier to “dynamically” (which is an ambiguity you definitely don’t mean).

I did a quick scan of 2.2 SC and spotted only three that use parentheticals. They are all variations on providing examples, and you’re essentially providing an synonym.

• 2.1.4

…using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then…
…one or more non-printable keyboard keys (e.g., Ctrl, Alt);

• 3.3.9

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step…

• 4.1.2

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role…

I also see that merely remove the parentheses is problematic.

[patrickhlauke]

wondering if it should be even more specific, as "change of context" is a bit overloaded as is. maybe dynamically could just be clarified as "(i.e. without moving to a new page)" or similar...