Update definition for "status message"#4840
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Slotting the new definition in place of the term into the normative wording for the SC, results in:
(note that the definition is for "status message", singular, while the SC uses "status messages", plural, so I tweaked the replacement accordingly to make it plural) compare this to the far more open-ended/vague current definition
|
|
@patrickhlauke I feel this new definition leaves us in a similar situation. To pressure test it, consider a received chat message. It satisfies "discrete pieces of content that are changed/updated dynamically" and also "provide[s] information to the user on the success or results of an action" and would be a status message under this new definition. Similar arguments can be made for dynamic search results. The distinction we are trying to draw here seems to be around author intent. I wonder if something like this would capture it?
The primary purpose of a chat message is not to "provide information to the user on the success or results of an action", it is to convey the text of the message. Similarly, the primary purpose of a set of search results is to display the links to matching pages. |
|
@electrickite still think it's a particularly obtuse reading of the words, but ... changed "and provides" to "to provide" which hopefully removes any such misinterpretation |
|
@patrickhlauke My job sometimes requires that I read standards as obtusely as possible, so I appreciate the change! :) |
|
I so very much appreciate removing "change of context" from the definition for status message! Currently, there is some circular logic, but I have some concern that this is a change of meaning. I am looking forward to discussion on TF call! |
|
Reviewed on TF call 1/16 and consensus for change. Since it is normative, will need to go through CFC. On call @scottaohara volunteered to update Understanding reflecting the question raised by issue. |
WilcoFiers
left a comment
WilcoFiers
left a comment
There was a problem hiding this comment.
Firstly and always, never a fan of normative changes.
I acknowledge the previous definition was a little trickier to understand it was much easier to test than this one. Change of context is well understood, whereas "discrete piece of content" is pretty vague. What if 10 status messages show up at once, is that a "discrete piece of content"? Or if the message shows up along with some other new information?
By removing "change of context" I think you unintentionally added a requirement that even if a status message is focused when it appears, it also has to be programmatically determined. That's not currently the case because changing focus is a change of context. Arguably active element may be considered programmatically determined. That feels like stretching programmatically determined definition beyond what it was intended to do though. If that is intended I think that'd need to be clarified in an understanding doc.
I also think the wording isn't very clean. The "changed/update" phrase should probably be "changed or updated". The word "dynamic" seems redundant. A discrete change or update is always dynamic, no?
Overall, I think this new definition creates more grey area than the current one. I appreciate that a surface-level reading of it makes it easier to understand the intent of the definition, but if that comes at the cost of testability I don't think that's a good trade-off.
|
Just for comparison, grafting the current definition of status message into the 4.1.3 SC text:
Grafting the proposed new wording in:
Looking at the grafted part above, I would think that the "without receiving focus" part in the SC text itself takes care of this. A "status message" itself is not tied to whether or not it does or doesn't receive focus ... the scoping of it needing to be announced when it's NOT receiving focus is part of the SC, not intrinsic to the definition of what a status message is, I'd say
sure, happy to tweak this
This tries to reinforce that it's a change that happens without, say, a page reload - to make sure that this doesn't unintentionally scope itself to "the page reloads, and there's a new count somewhere saying 'Results 11-20 of 100" now, and THAT now needs to be announced on page load" |
|
Really in support of this change, but something about 'discrete pieces of content' isn't sufficiently descriptive or clarifying for me. Is there a way to be clearer still, and more irreducible, perhaps with something like:
Edit: maybe just "content", even, instead of "instructive" or "discrete"? |
@WilcoFiers unless you mean that a "change of context" also covers the scenario where the content is changed under people's focus/feet (as in focus isn't moved per se, the content that is currently focused is) - which i think is a novel interpretation that (although logical once one thinks about it) doesn't come out of the definition for change of context https://www.w3.org/TR/WCAG22/#dfn-change-of-context (as in: don't think this was ever the intended interpretation for having that wording in the original status message definition?) |
|
I think the benefits of the change outweigh the cons, even considering the churn necessary for CFC. This isn’t the only place it happens, but it’s problematic to have too much of the detail (i.e., not a change of context) embedded in the definition — especially when that work is done by the SC. |
No that's not what I meant. That is an interesting scenario I'd never considered that. That might be a change of focus though since focus is set back to the body if the focused element is pulled? I'm not sure, but that isn't my main concern.
This seems vague and raises questions for me that I don't have with the current text. |
|
I sympathize with wanting to clarify the scenario from the motivating issue, but I don't think this proposed change achieves that goal and I agree that it creates new issues like Wilco pointed out. 1: It doesn't fix the issueI don't think the new wording is actually any more clear than the original that it would exclude "a list of search results that appears after clicking a search button" from being considered a "status message". Comparing the wording:
...I don't see why someone wouldn't consider the list of results to be "a discrete piece of content", and I think it obviously "provides information... on the results of an action". 2: Dropping "change of context" is breakingI agree with Wilco that dropping the "change of context" wording changes the requirement in a way that's probably not intended, and I don't think we should do that in an erratum. @patrickhlauke , you said:
I don't think this is right. Consider a case where a user performs an action and then focus is moved to information about the result. In the old wording, the movement of focus means that this is a "change of context" and thus not a "status message" for the purpose of the requirement. In the new wording, this now is a status message, and so now you've added a requirement to announce it (which might require announhcing more than just the change of focus would have done on its own). 3: "dynamic" and "discrete" are vagueI agree with @WilcoFiers and @camusamta 's feedback that "dynamic" and "discrete" both feel vague/off, and that it'd make sense to include "added" and not merely "changed/updated". |
Maybe I'm looking at this too closely myself, but saying that a "discrete piece of content that is changed/updated dynamically to provide information to the user on the success or results of an action..." to me would indicate that that's its sole purpose, and would not include the actual results/updated table/whatever, whereas "that provides information to the user" has more of that ambiguity. But would welcome alternative suggestions on how to tackle the original issue that motivated this, as it's undisputable that currently the vague definition of status message lends itself to interpreting it in a way that would mandate ANY dynamic change/update as a result of an action needing to be announced explicitly (including things like "in a form, if you select a radio button, a new field appears"), which was not the original intent of the SC. Maybe expanding to "discrete piece of content whose only purpose is to provide the user..." ... or would that still suggest that the list of results etc can also be seen as that? Because as far as i remember, we never intended the actual results etc to be covered by this requirement, so somehow we need to make that clear.
i think i'm seeing what you're getting at ... you saying that regardless of the "without receiving focus" at the end of the SC, the normative wording with the new definition inserted would now suggest that it must be (theoretically) possible for this to announce even IF it wasn't receiving focus? i think similar to the painful confusion we had with the "pointer" definition, this "status message" definition is wrongly overloaded but now necessary because the vague / not precise enough wording of the SC? because to me, a status message is a status message, regardless of whether it receives focus or not. it's only that WHEN it happens and doesn't receive focus, we want to make sure it's programmatically determinable so that it can be announced. now wondering if that could only be fixed with an additional change to the normative wording of the SC itself. EDIT: if we were to also touch the normative SC wording, we'd probably want to change "without receiving focus" to "when it doesn't receive focus" |
|
Even "the success or results of an action" is problematic because some status messages are not the result of an action by anyone, let alone the user. A session timeout warning would be one example, as is a notification that you have new messages that may have been created automatically by the system. |
I think this is really close. Because I still think 'discrete' raises the possibility for the same misinterpretations you're trying to address, what about something like: "information that is added or updated dynamically, whose only purpose is to instruct 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" The grafted-in version:
The word 'only' could possibly be swapped for 'explicit', too, if that still reads as having ambiguity. |
This still has the unintentional requirement Wilco was referring to in Patrick's initial proposal right, i.e., if the status message is focused, it would then still be required to be programmatically determined through role/properties? Can we simply slot change of context back in, in a different location, but retain what you have come up with to replace "change in content?" E.g.:
|
I would really like to avoid doing that in the glossary/term definition ... if we're already going through the pain of a normative change, I'd be more in favour of slotting it somehow into the normative SC wording, and keeping the definition of what a "status message" is clean (a status is a status, whether it receives focus or not) |
|
SC 4.1.3 includes “without receiving focus” so, as Patrick notes, that (redundantly) addresses the “not a change of context” clause of status messages. The glossary term could drop that, leaving:
We could also add note addressing #4676 clarifying than an updated search result (or whatever) does not meet this definition. |
|
Discussed on TF call 6 Fed. @patrickhlauke will take another pass. From discussion, just changing the term without updated the SC may not be feasible. It was noted that the current phrasing of 4.1.3 precludes best practice of using ARIA Notify — because 4.1.3 requires role or properties (which is not how ARIA Notify works). The limiting current scoping to “markup languages” also limits the generalizability of this ICT (e.g., WCAG2ICT). |
Why do you refer to ARIA Notify as a "best practice"? As far as I can tell, it does not improve the user experience in any way. It may make it easier for developers to implement announcements, but the poor discoverability makes testing much more difficult if you don't know what announcements a page is supposed to make (if any), and what triggers them. We will need to build new testing tools to help with this. |
* reintroduces the change of context part, but in the SC text, not the definition of what is or isn't a status message * removes the role/property part, so that the SC also covers things like `ariaNotify` * removes the "In content implemented using markup languages" to make this SC applicable even for status messages in things like native apps when WCAG is used in a WCAG2ICT context
|
after discussion in the TF meeting two weeks ago, this is now a more fundamental rewrite:
Doing the combined "normative SC text with grafted in definition" dance, this PR would land on:
|
|
Closing this PR in favour of its successor #4952 (mainly because the description, thumbs up/down, and discussion/comments, may be confusing since this morphed considerably since it was first filed). |
8 participants
The current definition for "status message" https://www.w3.org/TR/WCAG22/#dfn-status-messages manages to somehow miss out the fact that a status message refers to an actual discrete "message". The current definition makes it sound like any change of content may be interpreted as an "intrinsic" status message (see discussion #4672).
This PR changes the (normative) definition to make it clear that the WG always intended this to refer to explicit "status messages", and not somehow mandate the need for any dynamic content update (such as dynamically updating a list of results) must trigger some sort of SR announcement.
Closes #4676
Preview (in context): https://deploy-preview-4840--wcag2.netlify.app/understanding/status-messages#dfn-status-message