Transforming 3.2.7 Change of Content

[mbgower]

This issue thread has been created to track the work being done by myself, @DavidMacDonald and @steverep (with input from Matt King) to revisit the wording and scope of 3.2.7 Change of Content.

[mbgower]

My latest stab at wording and concepts

Change of Content Programmatic notification of changes in content are provided for auto-updating content and status information

status information

• dynamic content such as success, progress or warning notices, which result from either user action or application status changes, and which do not take focus

Programmatic notification

• a mechanism which provides notice of changed content to user agents and assistive technology. The notification can include the actual changed content.

[DavidMacDonald]

This is workable for me.

Would add, "errors" to the definition of Status information and content added/changed/hidden.

• dynamic content such as notice of success, error, progress, warning, new, changed, or hidden content, which result from either user action or application status changes, and which do not take focus.

[mbgower]

I always think in a "such as" statement, less is more. "Dynamic content" is a pretty wide term -- I think anyone would understand that dynamic content can be 'new' or 'changed'. I think we can clarify that in the understanding doc. I'm concerned about using the term "hidden content". There are a lot of meanings of "hidden", and I initially misunderstood what you meant, I think. I believe "removed" is a better descriptor for what you intended? But I also believe that we really don't need anything else. I'm okay swapping out "warning" with "error". I debated which to use and thought that error notices are a form of a warning. Here it is with the swap, to see if that scans better.

dynamic content such as success, progress or error notices, which result from either user action or application status changes, and which do not take focus

You haven't commented on the definition of 'programmatic notification'. I want it to be better, but I think it at least conveys the sense now.

[steverep]

Programmatic notification of changes in content are provided for auto-updating content and status information

The problem with this is that it does not delineate between the types of auto-updating information. This is great for a chat widget, but terrible for an ad carousel, stock ticker, or timer.

a mechanism which provides notice of changed content to user agents and assistive technology. The notification can include the actual changed content.

1. Couldn't I just interpret "notice" as changing the DOM? I don't think aria-live when I read this.
2. What do you mean by "can include"? Would it be okay if it didn't?

[mbgower]

it does not delineate between the types of auto-updating information

Does it need to? Is that not something that can be handled in the Understanding document and techniques? In example, we would have a technique covering content that auto-updates on a regular and frequent basis, such as carousels, stock tickers and timers. That technique's mechanism could be the assignment of a role such as timer, which designates a region of the page as frequently updating.

Did you envision a term that excludes different kinds of auto-updating content?

[mbgower]

What do you mean by "can include"? Would it be okay if it didn't?

I was incorporating a phrase introduced by David. "Can" indicates that something is optional. I believe he was trying to drive at the fact that the notification could include the text string. I'm still trying to figure out a way to cleanly divide the act of programmatic notification from the message that may accompany it. Still not there.As I posted (about 5 seconds before your reply!) I think we can improve this definition. :) Say, what about if we say "indication" instead of notification. Then we can work notification into the definition. Something like

Programmatic indication of changes in content is provided for auto-updating content and status information Programmatic Indication -a mechanism which provides an indication of changed content to user agents and assistive technology. The indication can include notification of the actual changed content.

Is that any better?

[steverep]

Does it need to? Is that not something that can be handled in the Understanding document and techniques? In example, we would have a technique covering content that auto-updates on a regular and frequent basis, such as carousels, stock tickers and timers. That technique's mechanism could be the assignment of a role such as timer, which designates a region of the page as frequently updating.

Yes, I think it absolutely needs to somehow. Your normative text says that programmatic notification is required, so you cannot explain in Understanding that it's okay to take a pass on certain types of content.

Did you envision a term that excludes different kinds of auto-updating content?

No, my initial thought was to take care of this by forcing a role as I proposed on the wiki page. When the role is properly identified semantically, the default aria-* properties are usually appropriate. However, even this is flawed because the role's default properties can just be overridden and my language did not disallow this. I don't have a good solution yet.

Programmatic Indication-a mechanism which provides an indication of changed content to user agents and assistive technology. The indication can include notification of the actual changed content. Is that any better?

Maybe slightly, but I'm still leaning strongly against trying to create a definition for "programmatic notification/indication" because I think it will always lead to problems. One thing I thing my proposal got right was to recognize that we are basically just asking for programmatic determination of live regions with appropriate markup/politeness. We have a definition for the former to use; the hard part is stating the latter. In plain language, we want the SC to say:

Auto-updating and status update content can be programmatically determined, and the importance and relevance is set appropriately for assistive technologies.

[mbgower]

Ha, I had a draft that was thinking of the same thing regarding determinability

Changes in content are programmatically determinable for auto-updating content and status information

I think my wording slightly better captures the idea that it's the changes in content we want determinable. That may arise from an assignment of role (i.e., a role of timer means the changes are frequent and predictable). My concern with your second phrase is that although it nails what we want, it is highly subjective. My question: to what degree can we cover concepts of importance and relevance in techniques and Understanding without making it part of the normative language?

[mraccess77]

I'd also mention that we want to include new content -- not just content that has changed.

[mbgower]

I'd also mention that we want to include new content -- not just content that has changed.

"Changes in content" should cover modified, added or removed content. They all represent changes in content. That will be clarified in the Understanding document.

[awkawk]

Are we talking about programmatic determination of changes in content now, or still on the notification of changes of content?

Changes in content are already covered by WCAG 2.0, so I may just be misunderstanding what people are pushing for.

[steverep]

I think my wording slightly better captures the idea that it's the changes in content we want determinable.

Well, playing devil's advocate, the "change" is always going to be programmatically determinable if I move the virtual focus to it. So I see 2 possible approaches:

1. Target the regions themselves as being programmatically determinable (similar to 4.1.2 and 1.3.1). A semantically correct role or aria-live value other than "off" will do this.
2. Target the "change" being programmatically determinable at the time of the change same techniques apply, although it kinda sorta implies immediate notification through aria-live="assertive" which is obviously bad.

That may arise from an assignment of role (i.e., a role of timer means the changes are frequent and predictable).

If we can pull off the first approach elegantly, that's great, but I'd then worry about accessibility support. This doesn't work for the second approach because no one wants to hear a clock ticking down, or at least not at the rate of visual changes.

My concern with your second phrase is that although it nails what we want, it is highly subjective.

That's because it was meant to nail it in plain language outside the cryptic world of success criteria ;).

My question: to what degree can we cover concepts of importance and relevance in techniques and Understanding without making it part of the normative language?

The "importance" part directly maps to the token specified for aria-live, and that's the million dollar question. The "relevance" part directly maps to aria-relevant and aria-atomic, and I'd be okay implying this by normative text with explanations in techniques and understanding.

The more I think about it, the more I think we should just narrow the scope to the stuff that always needs notification. We're on the right track with status updates (alert, status, and progress bar roles), but we need to incorporate chat and similar logs (log role). Then we could leave other stuff to advisory techniques and Understanding (marquee and timer roles), which are going to have questionable accessibility support anyway.

[steverep]

Changes in content are already covered by WCAG 2.0, so I may just be misunderstanding what people are pushing for.

@awkawk, not quite true and you probably needed to be on the call and private email chain with @mbgower, @DavidMacDonald, and me to fully understand. I promise we're working towards something clean, but still in work. Take a look at the scope discussion on the wiki to perhaps grasp where WCAG 2.0 is deficient.

[mbgower]

@awkawk I will attempt to summarzie the key points for you. As Steve notes, there has been a lot of back and forth in email -- one of the reasons I moved it back to an issue was so that anyone could follow the discussion, at least from this point in time on.

• 4.1.2 addresses user interface components (" notification of changes to these items is available to user agents, including assistive technologies"). This new SC should address other content (which at one point we tried designating simply as 'non-user interface components')

• a key distinction for this kind of content is that it does not take focus when content changes

• another key distinction seems to be that the changes in content we are addressing are visible and largely text-based

• There are four broad considerations we need to cover:

  • indicating that a region of content has info that can dynamically update (using the term 'region' generically here)
  • indicating that a region has been updated, AKA notification
  • conveying the change in content (including the removal of content-- think of how a 'busy' status message that disappears is conveying information by its absence)
  • providing author requirements/guidance on indicating the importance and relevance of the changed content

• The live region definition from ARIA glossary may be starting point for definition of Change of Content

• the SC should be complementary to 3.3.1 Error identification

• a challenge we have is that there are aria roles which designate parts of content that are dynamic BUT we can't just rely on such roles, since the attribute of aria-live can be put on any element

• Much of our vocabulary is based on ARIA, and thus not technology independent. In example, notification of content changes will frequently be supplied through the aria-live attribute

• There is a difference between the ability for the user to be notified of changes in content through the UA or AT, and notifying the user of the content of the changes (the original wording allowed the latter to be an exception for the former)

• I'll also note ongoing discussion we have with Matt King about whether there should be something like aria-live="true", which designates a live region. At the moment, aria-live only designates verbosity, with aria-live="off" conveying no information. If aria-live="false" was the default boolean, then aria-live="true" would provide an ability to indicate divs, etc, that have content that can dynamically change. An attribute called something like aria-live-verbosity could provide all the current values of aria-live.

[awkawk]

@steverep ok, I'll back away, but as I do I will also say that I don't see anything on the wiki page link that you sent where the programmatic determination of the information added to the page (or changed) is not covered under WCAG 2.0. Notification of the changes is a different matter and that is where I see our gap, as well as our challenges in crisply defining an SC around.

[mraccess77]

WCAG 2 seems to address changes of context as well as changes to individual user interface components. The area it doesn't seem to address clearly are changes/additions/removal that don't cause a change of context (don't affect a significant portion of the page) or are not specific to certain components covered by 4.1.2.

[DavidMacDonald]

Steve's plain language version

Auto-updating and status update content can be programmatically determined, and the importance and relevance is set appropriately for assistive technologies.

This doesn't require a status update, only that if it is given, it is determinable... I like the idea of working in the plain language version for a bit...

Status messages are provided for changes in content which can be programmatically determined, and the importance and relevance is set appropriately for assistive technologies.

Change of content: dynamic content such as notice of success, error, progress, warning, new, changed,Auto-updating or hidden content, which result from either user action or application status changes, and which do not take focus.

set appropriately: cool definition here that says something like. Messages which can be read within 10 seconds at x words per minute, have the role which matches their function (marquee, status, alert, log, timer, progressbar)

[awkawk]

@mraccess77 1.3.1? e.g https://www.w3.org/TR/WCAG20-TECHS/SCR21.html

[steverep]

I don't see anything on the wiki page link that you sent where the programmatic determination of the information added to the page (or changed) is not covered under WCAG 2.0.

The content itself is, of course, covered by WCAG 2.0 and needs to be programmatically determinable, but the type of content being programmatically determinable (a live region) is not covered. Satisfying the latter results in notification. In the context of WCAG 2.0 criteria, it's the difference between an actual heading's text being programmatically determined, and the fact that it's a level X heading, or the difference between a components label, and its role.

In ARIA terms, using the roles of alert, status, progressbar, log, timer, and marquee are simply not covered because they are not controls and thus do not meet the definition of "user interface components" for 4.1.2. And let's all agree now that 1.3.1 is enough of a debacle to not even try to argue them there.

Make sense?

[DavidMacDonald]

Steve's plain language version

Auto-updating and status update content can be programmatically determined, and the importance and relevance is set appropriately for assistive technologies.

This doesn't require a status update, only that if it is given, it is determinable... I like the idea of working in the plain language version for a bit...

Short handle Change in content, OR Status : or...

Programmatically determinable status messages are provided for changes in content and the importance and relevance is set appropriately for assistive technologies.

Change of content: dynamic content such as notice of success, error, progress, warning, new, changed,Auto-updating or hidden content, which result from either user action or application status changes, and which do not take focus.

set appropriately: cool definition here that says something like. Messages which can be read within 10 seconds at x words per minute, have the role which matches their function (marquee, status, alert, log, timer, progressbar)

[mraccess77]

@awkawk SCR21 seems more like a technique to show how to add content to a page that will be better seen by AT -- that is an accessibility supported technique -- but by itself doesn't really show any actual association or notification specifically. In one of the examples focus is moved to the new content.

[steverep]

@DavidMacDonald,

This doesn't require a status update, only that if it is given, it is determinable.

Right, that's by design and I don't see it as deficient. Requiring messages is a completely different SC, and WCAG 2.0 already attempts to cover it with criteria like SC 3.3.1, Error Identification.

[awkawk]

@steverep No, I'm not going to agree that 1.3.1 is such a debacle that we should pretend that something that the WG has agreed was covered by it isn't covered in our more enlightened present view. Sorry! :)

@mraccess77 I agree that SCR21 is about adding content to a page. Once it is added to the DOM, that content is programmatically determinable, and if a user happens upon it by chance or by experience knows to look for it (e.g I passed a "Cart: 0" item when I started reading the page, I will go back to see if my item was actually added) then that user can get that information. What is missing is the the notification part, and that is what the SC we have is addressing.

[mbgower]

In one of the examples focus is moved to the new content.

Yes, and moving focus to new content is a technique that accomplishes notification; although where someone has the ability to move focus to new content, the content would typically be a user interface component (a link in the example) and thus already be addressed in 4.1.2 .

[mbgower]

I'm thinking we may want to make our 'plain language' draft even more plain language, but before I attempt that, I want to return to what I listed as the four broad considerations we need to cover:

• indicating that a region of content has info that can dynamically update (using the term 'region' generically here)
• indicating that a region has been updated, AKA notification
• conveying the change in content (including the removal of content-- think of how a 'busy' status message that disappears is conveying information by its absence)
• providing author requirements/guidance on indicating the importance and relevance of the changed content

Does anyone in the discussion think this list is incorrect or over-ambitious? Is there something to add or drop?

[steverep]

@awkawk, okay okay... it's perfect. Let me just ask the practical question then: Do you feel that marking up any of the following is covered by 1.3.1 or any other SC?

• Status updates (including errors) with ARIA alert, status, etc.
• Progress bars with ARIA progressbar and required attributes
• Chat or other logs with ARIA log etc.

I could certainly make an enlightened argument that the way those types of elements behave is information conveyed in presentation that I do not have programmatically available to me.

[steverep]

Yes, and moving focus to new content is a technique that accomplishes notification

Please be very careful touting that as a technique - in most cases it is inappropriate and would violate SC 3.2.5, Change on Request. For example, if I click "add to cart" and get tossed way up the page to the "cart with X items" link, that's no good.

[DavidMacDonald]

@mbgower

• indicating that a region of content has info that can dynamically update (using the term 'region' generically here)

That wasn't really in scope in the original concept. I can see its value, but AT doesn't do that and I'm not too worried that it doesn't.

• indicating that a region has been updated, AKA notification

Yes, that is a primary use case of the original SC

• conveying the change in content (including the removal of content-- think of how a 'busy' status message that disappears is conveying information by its absence)

Yes that is part of the original intent

• providing author requirements/guidance on indicating the importance and relevance of the changed content

I had that in the Understanding, talking about short messages. But if possible this should be in the SC, ensuring the page isn't too chatty.

[awkawk]

• Status updates (including errors) with ARIA alert, status, etc.
• Progress bars with ARIA progressbar and required attributes
• Chat or other logs with ARIA log etc.

@steve, I'm not sure what you are saying isn't programmatically determinable. If you have an alert, that needs a role to be conveyed per 4.1.2. I'm not sure what does or doesn't work for you with alerts, but I don't think that you are saying that the content of the alert isn't programmatically determinable, are you?

Similarly for the other items - ARIA roles exist to help provide roles and semantics to otherwise anonymous content, but the content itself is readable on the web page so long as it is presented there, right?

Again, I'm trying to back away while you all figure out the latest proposal, but I do hope that it isn't repeating existing requirements.

[DavidMacDonald]

@awkawk

There is no requirement in the WCAG to provide a status message for changed content if the user is not focused on it. This is a user requirement, and many screen reader users are asking for this.

[steverep]

@awkawk,

I'm not sure what you are saying isn't programmatically determinable. If you have an alert, that needs a role to be conveyed per 4.1.2. I'm not sure what does or doesn't work for you with alerts, but I don't think that you are saying that the content of the alert isn't programmatically determinable, are you?

No, I (and at least Mike and David) are saying that your assertion that an alert, such as an error message after a form submission, is covered by 4.1.2 is not correct. That SC covers "user interface components" only, which WCAG scopes as controls, and none of those 3 examples I mentioned are controls. In the case of a status or alert message, it's usually just text.

[DavidMacDonald]

I should also mention that the previous SC language has had broad support, whenever I've presented it at conferences and talks. Although I acknowledge it had a few risks of allowing too much chattiness.

[awkawk]

@steverep I need you to be more specific. When you say "[my] assertion that an alert... is covered by 4.1.2 is not correct" - what specifically are you saying isn't covered, either by 4.1.2 or another 2.0 SC?

@DavidMacDonald I never suggested (at least not deliberately) that WCAG 2.0 had a requirement to provide a status message for changed content. I was only reacting to the suggested text that the status message itself needed to be programmatically determinable. If it appears on screen then it needs to be programmatically determinable, per 1.3.1.

[mraccess77]

At the very least this shows the lack of clarity for experts on whether WCAG 2.0 does or does not require markup communicating dynamic regions of a page. Once consensus is reached we should clarify this in the WCAG 2.0 documents.

[DavidMacDonald]

@awkawk Right.

The intent of this SC is to ensure Screen Reader users are notified of changes in content related to the purpose of the page that are not in focus, in a way that doesn't unnecessarily interrupt their work. It is also intended that people with cognitive disabilities have a visual confirmation of success or failure of important actions.

I actually think the above sentence can be the opening to the Understanding for this. @steverep @mbgower do you guys agree with this general intent?

[mbgower]

Up half the night thinking about this one. I'm going to get back to my 4 bullets and respond to a couple of questions, and offer some comments and thoughts I have had.

1. indicating that a region of content has info that can dynamically update (using the term 'region' generically here)
2. indicating that a region has been updated, AKA notification
3. conveying the change in content (including the removal of content-- think of how a 'busy' status message that disappears is conveying information by its absence)
4. providing author requirements/guidance on indicating the importance and relevance of the changed content

1. indicating content that can dynamically update

The very first line of the aria-live property states

Indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and user can expect from the live region.

then the characteristic of "off" is described as

Indicates that updates to the region should not be presented to the user unless the used is currently focused on that region.

I've asked for clarification from Matt King on this, but it seems to me that between the live regions and the aria-live attribute, we do have this ability to indicate.

2. Notifiy that an update has occurred

Built into the live region roles and aria-live property.

3. Convey the contents/nature of the change

For all but content that is completely removed, handled by live regions and aria-live property. We'll need to provide guidance in what to do to indicate that content has been removed. As one critical example, when the "Busy" status indicator disappears, screen readers can definitely benefit from knowing that.

Number 4, importance and relevance of changed content.

@DavidMacDonald said

I had that in the Understanding, talking about short messages. But if possible this should be in the SC, ensuring the page isn't too chatty.

My position, after much thought, is that this should actually be able to be covered by techniques that are also included in 1.3.1. Why? Because the importance and relevance for information added to the presentation should be based on how it is presented. Matt King responded "Bingo" to this statement in our email thread

Since the new text is in the UI, there tends to be a fair degree of consideration placed on the brevity and effectiveness of the information. I'd argue pretty strongly that making such information available through live regions is the most elegant and reliable way of ensuring a screen-reader user gets a similar experience. I'd also argue that in the same way location helps a designer decide on appropriate regions, the placement and frequency of information could help the designer designate the relative importance of that information to everyone, including a screen reader user.

A lot of this guidance is built into the default values of the live region roles, and the APG. I think some techniques on using aria-live appropriately based on the relative position of changed content in relationship to the item with focus, can resolve this conundrum, without us having to put any language into the SC itself.

---

Conclusion

I think we can cover ourselves with a shorter SC, that cross-references 4.1.2 and 1.3.1 in Notes. Two candidates that seem to be approaching this:

Changes in content are programmatically determinable for auto-updating content and status information

OR

Auto-updating and status information can be programmatically determined.

Steve had some thoughts on variations. Both need some form of the following definition:

status information dynamic content such as success, progress or warning notices, which result from either user action or application status changes, and which do not take focus

I'd also suggest we want to call out something like. Note: See 4.1.2 Name, Role, Value for considerations involving changes to the content of user interface components.

[mbgower]

By the way, another thought I had last night. What about prompts, as in speech interaction? I believe that conversational UI design is going to have to be brought into this as a consideration.

It looks like we have a gap for speech conversations, period. It's not covered by any of the time-based media, since the one most relevant, Audio-only (live) is AAA and Captions (live) is restricted to synchronized media.

I think a good portion can potentially get covered under 1.1.1 (although "presentation" is never defined). IBM added our own Situation G to our techniques to cover audio alerts. I flagged that to the WG previously. I see a potential for an audio situation getting added that covered both audio alerts and speech prompts. That would ensure a text equivalent for audio alerts, which would then potentially get covered by existing WCAG considerations (although as an alternative, would they get the same pass that captions do for some things?).

It might be an idea to consider speech prompts here to see if we can bring them in. It would be pretty hard to argue they fall under 'status information' or 'auto-updating'.

[mbgower]

@awkawk said

I need you to be more specific. When you say "[my] assertion that an alert... is covered by 4.1.2 is not correct" - what specifically are you saying isn't covered, either by 4.1.2 or another 2.0 SC?

The opening of 4.1.2 makes it clear it is "For all User Interface Components". The glossary definition:

user interface component a part of the content that is perceived by users as a single control for a distinct function Note 1: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls. Note 2: User interface components include form elements and links as well as components generated by scripts. Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component."

Information we are concerned about has many qualities which clearly separate it from this definition:

• It tends to be text only (not a widget)
• It is non-interactive (cannot be navigated to by keyboard without use of AT).
• It does not normally take focus
  • which follows that it is updated when focus is elsewhere

4.1.2 covers many considerations to do with such components, such as assignment of role, changes in state, properties and values, and notification of changes.

We are trying to ensure that some of these considerations are addressed for status text and other kinds of information which does not meet the definition of a user interface component. At one point we thought we could cover the topic by simply saying such items need to be assigned an appropriate live role. However, there are a couple of issues with this. First, it is technology depenedent. Second, even within aria specs, aria-live is a property that can be placed on any element. That implies there are likely cases where insisting on use of a live region will be problematic.

In a nutshell, we have one solution for the problem. We just need to properly describe the problem with SC language so that we can ensure the solution can be properly applied without being misapplied/misinterpreted.

[DavidMacDonald]

@mbgower I can live with some form of this.

1. Should status messages be visual to cover off part of Issue #54, and to address your concern about internationalization?
2. I know "warnings" could include "errors", but I'd put errors in that definition.
3. regarding audio feedback. I'm OK with that idea, but COGA may be concerned if all audio feedback has to get a text alternative, because it might be a disincentive to authors who might otherwise do something that helps them... let's mull that over at TPAC

[mbgower]

Okay, thanks for the response @DavidMacDonald . I also saw the email feedback from Matt and you on the current wording of the aria spec for aria-live. Still digesting that.

I have looked at @steverep 's and @awkawk's prior feedback and attempted to work this into my latest language. I'm still not happy with this, but hoping it may actually approach something we can all live with:

---

3.2.7 Change of Content

For auto-updating or status information, all of the following are true:

1. Changes in content are programmatically determinable through role or attributes
2. Notification of changes to content is available to user agents, including assistive technologies.

status information content such as success, progress or error notices, which dynamically updates as a result of user action or application status changes, and which does not take focus

---

I added in the idea of roles in the first item. Originally, it just read:

1. Changes in content are programmatically determinable

Comments? My idea would be to keep it simple, and that a lot of the nuance would be clarified through Understanding and techniques.

David, I think I'm going to leave audio feedback out of this for now. Once we have language that we can agree on for the main thing, we can try to incorporate. But I think trying to work it in before that just makes it messier.

[mraccess77]

The phrase "auto-updating and status information" is too restrictive in my opinion. It doesn't seem to capture the issue when new content appears and the presence of the new content not only needs to be programmatically but also a notification given when the new content appears.

[mbgower]

The phrase "auto-updating and status information" is too restrictive in my opinion. It doesn't seem to capture the issue

Hi @mraccess77, can you give me examples of what content you feel is missing? The definition of status information reads as follows

status information content such as success, progress or error notices, which dynamically updates as a result of user action or application status changes, and which does not take focus

As you are aware, Auto-updating is listed in 2.2.2. It is not defined there, but qualified to the degree it appplies in that content. We haven't discussed whether there is a need to do more than cross-reference it. Obviously the intent would be to provide Understanding and technique guidance for specific types of auto-updating content.

Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

[mbgower]

It doesn't seem to capture the issue when new content appears and the presence of the new content not only needs to be programmatically but also a notification given when the new content appears.

@mraccess77, the two bullets of the SC seems to directly address this. The first has the requirement for the changes to be determinable. The second requires notification of those changes. Can you elaborate on how this is deficient?

[mbgower]

In discussion with Steve, we're wondering about removing the auto-updating information to steer clear of confusion over use of less adopted and supported aria roles (These could be added in as advisory techniques.) and concentrate on status messages and error logs. As a first shot at that, I'm simply removing the term

3.2.7 Change of Content

For status information, all of the following are true:

• Changes in content are programmatically determinable through role or attributes
• Notification of changes to content is available to user agents, including assistive technologies.

status information content, such as success, progress or error notices, which dynamically updates as a result of user action or application status changes, and which does not take focus

-- We could also potentially bake the definition into the SC wording now:

For content which does not take focus and which dynamically updates as a result of user action or application status changes, the following are true: ... Note: success, progress and error notices are examples of such content

[mraccess77]

Focusing on status messages and error logs doesn't really seem to address the issues with new content. I am thinking of a situation where you check a box and a section above appears with new form elements in it. This is an important content change that isn't a change of context but it is something the user needs to be aware of. Are we putting off this scenario for WCAG 2.1 or trying to address this situation?

[mbgower]

@mraccess77 said

Focusing on status messages and error logs doesn't really seem to address the issues with new content. I am thinking of a situation where you check a box and a section above appears with new form elements in it.

I would think of that as a Change of Context and failure of On Input. Here is the wording in SCR19 Using an onchange event on a select element without causing a change of context

It is important to note that the select item which is modified is after the trigger select element in the reading order of the Web page. This ensures that assistive technologies will pick up the change and users will encounter the new data when the modified element receives focus. This technique relies on JavaScript support in the user agent.

Here are key parts of the glossary definition of changes of context:

major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously Changes in context include changes of...content that changes the meaning of the Web page.

You state

This is an important content change that isn't a change of context but it is something the user needs to be aware of.

As you note, this is an important content change and the user needs to be aware of it. This seems to meet the criterion of the fourth bullet in the definition, as quoted, and I have had no problem failing such instances with current 2.0 pages.

---

On a more general note, you are correct in that we are not trying to resolve every situation where a change of content could be conveyed by the app to the AT. We are trying to tackle specific ones which are least detectable to a screen reader user (status messages, as defined, would never take focus), and for which there are good existing ARIA roles and guidance. Low hanging fruit as it were.

I think we can also list considerations in the Understanding document that talk about considerations where new content does not meet our subset, and provide advisory techniques for those situations (everything from moving focus to new content that can take focus, to use of advanced notice, dialogues and offscreen text).

[mbgower]

Cross referencing a comment in another issue that is relevant to discussion

[mraccess77]

@mbgower it's not at all clear that it's a change of context. In my example a section appeared -- but what if just one new field appears and the triggering element was a button that the user pressed enter on. In that case it was user initiated and one new field would not seem to be a change of context.

[mbgower]

what if just one new field appears and the triggering element was a button that the user pressed enter on

If the element appeared based on such a user action, I agree that it is not a failure in 2.0 against either 3.2.1 On Input or 3.2.2 On Focus, given that it did not occur when an element received focus or the user began inputting information.

I'm going to address your scenario, but I do think it is getting off base of the catalyst for this SC -- that is, to surface text added to the screen which doesn't (read "cannot") take focus. Given that we've already acknowledge this SC is aimed at targetting the most problematic and easily solved situation, and is not designed to solve every situation where new content is added to the screen, I'm not sure how germane the digression will be, but I'll try to bring it around to the new SC intent and language.

---

First off, I think we can all agree that any interactive control that is designed to appear above the current focus point is going to be a challenge to discover for many users, and is going to be confusing/surprising to anyone who renavigates the site and discovers it. So, we're talking about poor design. We cannot solve every crappy design quirk with standards.

Second, I think we can also agree that this situation becomes worse for people with a variety of disabilities.

What are the ways to address the scenario that you describe?

1. I can convince the team that this is a crappy design and convince them to make their UI better. If they've followed any kind of UAT process, they'll have received feedback that supports this. I can also point out the increased problems for PwDs, and even take a stab at saying how it is a failure (probably using 2.4.3 Focus Order or Conformance Requirement 4 ). This is obviously the preferred solution.

2. I can put the focus to this new control, which would certain make its presence clear to everyone. Given this was triggered by a user activating a button, such a change of context is allowed. I can't imagine that's a very elegant solution, but it does solve an inelegant design problem.

3. I could use some kind of onscreen alert to let users know a new field has been added above the present location. I don't think this is that desirable, but it does let all user know to go back, so it covers everyone. Such an alert would either be modal and announced, or would be covered by this new SC and its techniques, which cover alert roles and aria-alert.

4. I could only worry about alerting blind users; essentially giving the same info as in the prior scenario, but do it with non-displaying text.

5. I could have the new element's contents (name, role, value) announced by the screen reader without moving focus. Probably the least desirable of these options, given I would have no context for what was spoken or why.

6. I could combine the last two and both announce a new field was added and read out its label/value. Slightly better? Only know with user testing.

---

All these solutions could be done with current language. Note that these last 3 are all solutions restricted to users with screen readers. What we'd be ensuring with the new SC language is that in scenario three where the visible notice appears as the solution for all users, the screen reader user also receives that notice.

[mbgower]

Suggested wording change on Monday's working group call was:

For content which does not take focus and which dynamically updates as a result of user action or application status changes, notification of changes to content can be programmatically determined by user agents, including assistive technologies.