Thoughts on 4.1.3 and status messages

[lilzesh]

Recently I've really been getting into the weeds with 4.1.3 Status Messages.

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.

I feel some of the content written in the intent section actively contradicts what has been established as normative text. Let us take a look at the definition of status messages more closely.

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 the intent section of 4.1.3 there is an example, i.e., "For example, the list of results obtained from a search are not considered a status update and thus are not covered by this success criterion." There does not seem to be any rationale as to why the addition of search results would not be considered a status message, but when reading the normative text of 4.1.3 along with the definition of status messages I cannot help but think this is in fact a status message.

Consider this. I execute a search on my site's search page, 10 new results are dynamically added to the page, and my focus remains on the submit button. Does this fit the criteria of a status message? I believe so.

Was this a change of content that is not a change in context?

Yes - A change in content definitely occurred as 10 new results were added onto the page, my focus remains in the same location, on the submit button, the page I am on still remains the search page, so the meaning of the page remains the same, and there were no changes of the viewport or the user agent.

Does it meet one of the four other qualifiers that make up a status message?

Those qualifiers being:

• provides information to the user on the success or results of an action, or
• on the waiting state of an application, or
• on the progress of a process, or
• on the existence of errors

Yes - I clicked on a submit button and upon doing so 10 new results were added to the page as a direct result of the action I took against the submit button. That seems to be exactly what the first bullet point from above it stating.

Well now what? What does it all mean?

By the definition of status message, any change in content that is not a change of context and provides information to a user on the success or results of an action must be presented to assistive technology users without receiving focus. Some other common examples, a button that adds more news articles to a page, a chat where messages are added after a user submits a query, and even search results.

The intent reads as if it considers status messages to be things we commonly think of as status messages, i.e., "Searching...", "18 results returned" or "No results returned." It feels like the intent of the document wants the definition of status messages to say something it doesn't, i.e.,

content that explicitly 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

But the current definition of status message feels so much broader. A status message isn't content itself, it's the change in content, and it's this change that must be presented to users somehow.

[patrickhlauke]

Consider this. I execute a search on my site's search page, 10 new results are dynamically added to the page, and my focus remains on the submit button. Does this fit the criteria of a status message?

no ... where is the status message that needs to be announced? if there is/was a line somewhere that also automatically updates, that says something like "Showing 1-10 results of 145" or similar, then THAT would be the status message. or "No results". but just the actual list of results changing is not a status message per se.

the SC is not saying "any time some content is dynamically updated, this must be explicitly announced". it is scoped specifically to just cover status messages. otherwise the normative text would have been much broader.

[lilzesh]

no ... where is the status message that needs to be announced? if there is/was a line somewhere that also automatically updates, that says something like "Showing 1-10 results of 145" or similar, then THAT would be the status message. or "No results". but just the actual list of results changing is not a status message per se.

The act of adding 10 search results to the page is a change in content (and not context) which also provides information to the user on the success or results of an action. To me, this clearly fits within the definition of a status message and thus we must present this to assistive technology users in some manner that does not require moving their focus.

[lilzesh]

To elaborate further. The change in content is itself the status message (given the other qualifiers of status messages are met). If I search and submit and 10 search results are added that change in content is itself the status message. Visually I can see new search results added because the page changed, that is the information provided to the user on the results or success of their action. That is the change that needs to be presented to assistive technology users, and that is commonly achieved with a live region and some text, but that is the mechanism in which we present the status message to the user, not the status message itself.

[bruce-usab]

@lilzesh the user hit the submit button, they are expecting something to change. The result is new content (maybe even a new page). As Patrick notes, 4.1.3 is scoped just to the status message itself. I think the concern you describe is covered by SC 3.2.2 On Input.

[lilzesh]

I agree, they are definitely expecting a change, but they aren't always going to be made aware of the change and I guess that is where my concern is, given the definition of status messages.

A status message is a 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.

Could you help me understand the definition above? It says that a status message is a change in content (that is not a change of context), and in my example, one that provides information to the user on the success or results of an action.

1. I go to a search page
2. I type bananas in the search
3. I navigate to the submit button and activate it
4. 10 new search results concerning bananas were inserted into the same page

There is no doubt in my mind that this is a change of content. I also believe there is no change of context, I remain on the same search page, my focus didn't move, it's still on the submit button, and there were no changes to the user agent or viewport.

So I've now met the first part of the definition of status message, i.e., "a change of content that is not a change of context." Did I meet one of the remaining qualifiers of what constitutes a status message? They are:

• 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.

Yes, information was provided to me based on the success or results of my action, i.e., adding new items onto the page feels like information that has been provided to me based on me submitting my search (the action). Therefore we must make users aware of those new search results without them receiving focus.

Typically, the method we use to present this change to our users is a live region and some text, which we unfortunately call a status message, but that is just the mechanism we use to inform the users of the true status message, the change in content (at least by it's own defintion).

Please correct me if I am mistaken but it sounds like the argument I am hearing is disregarding the first portion of the definition of status messages, i.e. "a change in content that is not a change of context." It feels like there is conflation between the change of content that is not a change of context and the mechanisms we used to present that change to users.

[patrickhlauke]

Yes, information was provided to me based on the success or results of my action, i.e., adding new items onto the page

that's an implicit information - there wasn't a message telling you this, you worked it out yourself based on the fact that new things appeared. the SC only deals with explicit status messages.

[patrickhlauke]

again, if the intention had ever been to make the SC apply to scenarios like yours, it would have been worded differently, along the lines of "In content implemented using markup languages, all changes of content can be programmatically determined"

[patrickhlauke]

@bruce-usab perhaps the definition needs to be tweaked to make that more explicit... #4676

[electrickite]

the SC only deals with explicit status messages.

Since the SC does not mention implicit vs explicit information, the discussion here is instead about the definition of a status message. I think the logic in @lilzesh argument makes some sense. When, for example, a new chat response appears in a chat application there are two things communicated by the new content: the response itself, and the fact that a new message is available. A single element is communicating both things, but both are still communicated to the user. The message text obviously does not fit the definition of a status message, but informing the user that a new message is available does seem to be "information ... on the success or results of an action".

[mbgower]

Yes - I clicked on a submit button and upon doing so 10 new results were added to the page as a direct result of the action I took against the submit button. That seems to be exactly what the first bullet point from above it stating.

Displaying any new information does not constitute a status message. There are clear examples given of what would in this context:

However, brief text messages displayed about the completion or status of the search, such as "Searching...", "18 results returned" or "No results returned" would be status updates if they do not take focus. Examples of status messages are given in the section titled Status Message Examples below.

[lilzesh]

Under the normative definition of status message, at least in its current form, one could reason that there are occasions where new information is a status message. I acknowledge I was intentionally disregarding most of the Understanding and sticking strictly to what was defined in the normative text.

[patrickhlauke]

taking a step back though, even though the idea with definitions is that you could replace the term with the definition wording...the term itself still counts for something, and in this case the term is "status message", so unless there is something that you can identify as "THAT there is the status message", then it gets shaky.

To use a different fictitious example: if the normative wording was "Shout if you see a lion", and the term "lion" was defined as "a mammal with big teeth" ... it doesn't mean that you can interpret the normative wording as "Shout if you see a mammal with big teeth" and then shout when you see a hippo...

So, same logic probably applies here...normatively it does say "status message", so the term itself counts for something. You need to be able to actually identify what the status message is, specifically. Not every "change of content without a change of context...etc" counts.

[electrickite]

even though the idea with definitions is that you could replace the term with the definition wording...the term itself still counts for something

This is getting off topic, I realize, but I'm not sure that is a given. I suppose I've always taken the "replace the term with its definition" approach. Otherwise you are stuck in loop needing to define the term. It may seem like a pedantic point, but with regulations adopting WCAG as a technical standard these distinctions really do matter. They can impact organizational conformance claims, product decisions, budget allocation, etc.

In your lion example, I would argue that the guideline requires shouting if you see a hippo, based on the fact that the glossary definitions are normative. The definition may be overly broad, but that's a fault of the definition.

[kaninchenundente]

taking a step back though, even though the idea with definitions is that you could replace the term with the definition wording...the term itself still counts for something, and in this case the term is "status message", so unless there is something that you can identify as "THAT there is the status message", then it gets shaky.

To use a different fictitious example: if the normative wording was "Shout if you see a lion", and the term "lion" was defined as "a mammal with big teeth" ... it doesn't mean that you can interpret the normative wording as "Shout if you see a mammal with big teeth" and then shout when you see a hippo...

So, same logic probably applies here...normatively it does say "status message", so the term itself counts for something. You need to be able to actually identify what the status message is, specifically. Not every "change of content without a change of context...etc" counts.

The lion/hippo analogy doesn't support your point—it undermines it. If "mammal with big teeth" captures hippos when you only want lions, that's a problem with the definition being too broad, not evidence that terms can't be substituted with their definitions. The answer is to write a better definition, not to claim the word "lion" has some magical property beyond what can be defined.

Your argument that "the term itself counts for something" beyond its definition creates a fundamental logical problem:

Either the definition is incomplete and you need to specify what's missing, or
Your reasoning is circular—requiring people to already know what a status message is before they can identify one, which defeats the entire purpose of having a definition.
This is essentially special pleading—claiming "status message" gets to operate under different rules than other defined terms, without justification. In technical writing, definitions must be substitutable with their terms. That's not optional; it's how definitions work.

[GreggVan]

Sorry - you cannot separate the definition from the SC.. If the definition is bad for use as written in and SC then it should not have been used as written. The SC is bad because it used a bad definition.

that does not mean that the definition is not the right place to fix it -- but the SC is bad for using that definition just like it would be bad if it use the word PAGE when it meant "SENTENCE" or "PARAGRAPH". use the wrong word as it is defined and you wrote the SC wrong.

[mbgower]

When, for example, a new chat response appears in a chat application there are two things communicated by the new content: the response itself, and the fact that a new message is available. A single element is communicating both things, but both are still communicated to the user. The message text obviously does not fit the definition of a status message, but informing the user that a new message is available does seem to be "information ... on the success or results of an action".

I think you are failing to distinguish between communication, and communication explicitly about the status of communication. If that distinction is not made, then we are just talking about all new information in any form, which is obviously not the intent.

An example of a status message in the chat case would be something like " Mike is typing".

[kaninchenundente]

which is obviously not the intent.

The normative success criteria are the only binding requirements for WCAG conformance, and they must be interpreted based on their plain text as written, not redefined by non-normative documents.

The "intent" of a success criterion is defined by what the normative text actually requires, not by what the authors may have wished it to say or what Understanding documents describe.

Understanding documents may help interpret ambiguous normative text, but they cannot contradict or expand what the normative success criterion plainly states. If the SC needs to say something different, it should be changed through the proper standards revision process.

[GreggVan]

PLUS 1 to @kaninchenundente
(I am not commenting on the current proposed changes -- just that we cannot change the SC language - just clarify it in a note. if ambiguous - notes are great. If incorrectly written - notes cannot undo it -- nor can an understanding documents

[electrickite]

then we are just talking about all new information in any form

Not necessarily all new information, only when that new information relates to the success or results of an action, the waiting state of an application, the progress of a process, or the existence of errors.

[electrickite]

To put this position another way, I am leery of an interpretation of 4.1.3 that would make the announcement of "Mike is typing" necessary for WCAG conformance, but would not require any announcement when Mike's message has actually been received.

[GreggVan]

What a great discussion.

OK - my thought on the original question.

1. if we consider a message like "10 results found" to be a status update (which it seems pretty clearly to be) but don't consider simply the results to be a status update -- that seems to be making pass /fail a technical distinction rather than actually trying to achieve what they provision was meant to achieve.

2. definitions are often drafted only thinking about one SC. Then used on other SC where they are not really correct. We need to always update the definitions to work in ALL the places they are used.

   • and then CHECK them using the "substitute the definition into the sentence" technique to make sure they do.
   • if that is what we have done here (the definition is the problem) then we need to leave the SC alone and fix the definition.

3. we should always return to what the SC was trying to achieve -- and correct things to go in that direction

4. SOMETIMES -- an SC seems to have a hole - but doesnt because the "other thing that we seem to have missed" was already covered by another SC and this SC is only intended to cover some instance that the other one did not. I am not sure if that is true here but just something to think about.

5. and finally -- this discussion is great for WCAG3 but we are pretty much stuck with what 2.2 says unless we are going to release a WCAG2.3. it looks like we are trying to stretch the definition of errata here but -- there are limits.

[lilzesh]

Completely understand Gregg, thank you. And in all honesty my intent here was just to drum up discussion not only for my own continuing education in accessibility but for others looking at WCAG from a strictly normative standpoint. I happened to find the status messages definition, which I take to be a replacement for the word, curious as it appears to suggest that the status message is the change and not the manner in which we present that change. I'm not suggesting my interpretation is any more valid than any other approach but seek to clarify the limitations and boundaries of my own knowledge.

I understood the intent of 4.1.3 and what the intent was behind the defintion of status messages, as many contributors here have pointed out to me. But the normative text says what it says "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."

I honestly find the prospect of the current defintion quite appealing. This takes the current criterion from only announcing explicit messages, to making sure we provide explicit messages as the direct result of a user action. That sounds very appealing, but don't get me wrong, I have not thought deep enough about the implications of that, and admit, maybe that is not the best path forward.

[GreggVan]

@lilzesh Glad that you are thinking about these things. In the rush sometime we all miss things. Good to keep looking and thinking about how it looks to those who need to apply it.

ALSO good to re-examine everything and get it as right as we can in WCAG3

[mbgower]

To put this position another way, I am leery of an interpretation of 4.1.3 that would make the announcement of "Mike is typing" necessary for WCAG conformance, but would not require any announcement when Mike's message has actually been received

@electrickite I was trying to give an example of something that is indisputably a status message. Given it's the application communicating that someone is typing, not actual information conveyed by a participant, I'm assuming (hoping) no one will dispute that this additional information fits the definition of a status message.

Messaging applications, given the interaction and content being conveyed, are a little tricky in this area. I mean, they're all about messages, so distinguishing which chunks of the communication are status messages -- or even what parts of a single message constitute status -- can be a challenge. But as you note, the whole problem space trying to be addressed here is that blind users or others who cannot detect messages about status will still have the ability to have those provided to them.

Those working on this new SC spent a lot of time crafting normative language that can provide benefit in this area without creating a nightmare for screen reader users where well-intentioned authors put any new information on a page inside a live region set to assertive.

As this discussion shows, not everyone thinks we got it right, but the nuances of a messaging application are not where I think we're likely to get clarity on that. The fact there seems to be disputes over the search interaction scenario used in the Understanding document is concerning, as that seems like a pretty clear difference in the nature of the communication.

[patrickhlauke]

i think this discussion just shows the desire for the SC to require more than what it tries to carefully scope to just things that can be understood as explicit status messages, and to include "intrinsic" status messages ("the new thing appeared, so of course its appearance itself is a form of 'status message'")

[patrickhlauke]

and these were - from memory - discussions had at the time, and the WG tried to avoid becoming too broad the other way and have an SC that all of a sudden mandates that ALL/ANY changes on a page/screen MUST be announced explicitly by AT

[GreggVan]

Sort of Available to AT -- Yes However, there are no requirements on what AT must do

[GreggVan]

Whether or not this is covered by status messages -- 1.3.1 requires that all things presented visually be programmatically determinable or in text - so it is available to AT. What AT does with it is out of scope. But authors should not try to say act as AT ourselves. It would override the intent and settings of the AT with regard to what should be spoken or not.