Transforming 3.2.7 Change of Content #544
Comments
|
My latest stab at wording and concepts
|
|
This is workable for me. Would add, "errors" to the definition of Status information and content added/changed/hidden.
|
|
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.
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. |
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.
|
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? |
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. :)
Is that any better? |
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.
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
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. |
|
Ha, I had a draft that was thinking of the same thing regarding determinability
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? |
|
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. |
|
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. |
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:
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.
That's because it was meant to nail it in plain language outside the cryptic world of success criteria ;).
The "importance" part directly maps to the token specified for 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. |
@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. |
|
@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.
|
|
@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. |
|
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. |
|
Steve's plain language version
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...
|
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 Make sense? |
|
Steve's plain language version
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...
|
|
@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. |
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. |
|
@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. |
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 . |
|
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:
Does anyone in the discussion think this list is incorrect or over-ambitious? Is there something to add or drop? |
|
@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?
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. |
|
Suggested wording change on Monday's working group call was:
|
|
Comments from today's discussion:
|
|
@steverep and @DavidMacDonald .Attempt at a rewrite to take these into account:
OR
OR
For status messages, To re-emphasize, we also need to ensure we explain the relationship to 4.1.2 Name, Role, Value and 2.2.1 Pause, Stop, Hide. I also wanted to note that the "including assistive technologies" phrase was lifted directly from 4.1.2. I assume there was a reason it was included there, so it makes sense to reuse here. I still have a nagging feeling that making the notification programmatically determinable is problematic, but i cannot adequately voice at this moment. Will try to revisit. |
|
In discussion, David raised the idea of ensuring we capture a "18 results" message on search results as an example of a status message |
|
David wants to distinguish between notifications of new content and all that new content being read out. The former is a status notices; the latter is chatter no one wants |
|
Final wording:
Status messages Status content is an alternative? |
|
I suggest "can be programmatically determined" and "can be presented to the user" (rather than "announced", which suggests a spoken interface only). These changes are editorial. |
|
Incorporating Jason's comments:
I'm fine with that. |
|
Yes, I think Jason's change addresses the comments Steve had at the end which we were going to tackle by including the following in the Understanding: “announced” can cover a variety of modalities for surfacing information to the user from sound to spoken text to Braille display. Nice to have someone look at it fresh after we're all punch drunk with fatigue :) The final things Steve had requested were some revisions to the definition of status messages -- David had a few words about that too -- and a consideration to renaming the SC.
Objective two: consider working in the idea of this being dynamic content that is not present in the DOM initially. I also worked in David's desire to track changes to the UI through user action by adding in "or results of"
I'm pretty happy with that. Objective three: consider a new name for the SC. I guess the obvious title is Status Messages. But I feel like we're pushing our luck a bit with this. My feeling is that if we leave it as Change of Content it will give us some leeway in the Understanding document to riff on some of David's considerations. I also suspect that someone in the working group will propose a new title. Maybe if we put the focus to the group by asking that question on the title? The submitted version would read:
|
|
Final thought. Do we need to define status messages as NOT being user interface components? I'm worried that someone might make the argument that if the status message is in a dialog or some other form of notice that takes focus, this SC seems redundant and possibly even disruptive.
OR |
|
@mbgower, I like the latest definition which starts by saying "changes in content..." That solves one issue. I don't think we should leave the title as is; it should reflect the scope clearly. Something like "Status Messages" or "Status Changes" would work best. And I think that the SC saying without focus is enough. As I said last night, we don't want an "out" just by putting |
|
@DavidMacDonald @steverep @jasonjgw, please offer final comments: 3.2.7 Change of Content Status messages |
|
|
Oops, sorry about missing new title @steverep ! 3.2.7 Status Changes Status messages |
|
This SC is very different from all other SCs as it specifically dictates how notifications are to be made programmatically determinable: i.e. using role or other attribute. Is that not how everything is made accessible? By using a particular tag or attribute? I am glad to see that the originally proposed SC for "change in content" has undergone a significant metamorphosis since I raised the objection in issue 539. |
|
Will a JS alert satisfy the requirement? |
|
@spanchang, this transformation is now all about simply using the ARIA live region roles and their properties appropriately. The ones targeted here are those which are well accessibility supported: alert, status, log, and progressbar. Results can also be achieved by specifying A JS alert is not in scope here because a screen reader will jump focus to that. In other words, it does not meet the definition of a status message per this SC. |
To build on what Steve is saying, any info displayed through a js alert triggers a change in context, and so, according to the definition of status message is not applicable. Language for status message definition agreed on today's call:
There's nothing wrong with using a dialog to alert users of issues. This SC is covering a situation where an author uses javascript to add text (i.e., whatever the author put into the alert in your example) directly into the page content instead. It doesn't take focus, and there's no way for the AT to understand it has been added unless it is given the proper role AND any properties that role has that cover communication to the AT are appropriately set to give notice to the AT (i.e., it cannot put aria-live="off"). |
I wouldn't say there is consensus, but there was a decision made to reduce the scope of the SC down to something that could be adopted successfully in the working group's timeline, which would still be of demonstrable benefit. |
|
Mike / Steve,
If text / content is added that is not visually distinguishable from
existing content on the page, yes adding role / other properties will
help AT users.
But if that content lacks distinct presentational properties, will
that content not be difficult for some sighted non-AT using PWD user
groups to notice? Some of these users could be those whose needs are
being addressed by Cognitive and Learning Disabilities Accessibility
Task Force.
It could be a UI design / usability issue too that results in ordinary
users too missing the changed content unless they scrutinize the page
carefully.
This situation is discussed under Reason#2 of
http://www.mindoversight.com/?p=168
If presentational / styling properties are added, it will then be
covered by SC 1.3.1 because that content has to be programmatically
determinable too.
Or at the present time, is it a conscious decision to not consider the
needs of non-AT using PWD groups?
I believe this is the case, right?
Thanks and best wishes,
Sailesh
…On 11/30/17, Mike Gower ***@***.***> wrote:
> Apparently there is consensus on the objections raised in the articles:
http://www.mindoversight.com/?p=171
I wouldn't say there is consensus, but there was a decision made to reduce
the scope of the SC down to something that could be adopted successfully in
the working group's timeline, which would still be of demonstrable benefit.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#544 (comment)
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765
|
Possibly. But what presentational properties do you think would ensure all non-AT using PwDs would notice it? That is in the realm of conjecture. And if you could define any, would you want to insist those must be used by all designers? What we can say is that if such text is given an appropriate role to indicate it is a status message or whatever, that is arguably beneficial to any AT which wishes to do something with that, for whatever user group.
Sure, but the task of the guidelines is not to prevent designers from making every poor design decision. It's to try to offset poor design decisions that adversely affect PwDs to a larger degree.
I think you're missing the point here. While something that is visually presented as larger text can be given a heading tag -- which will meet 1.3.1 -- that does nothing to alert anyone to the fact it has been added to the DOM after page load. If an author brings such information into the UI as any kind of dialog, then it is handled fine by existing 2.0 requirements. But there are a growing list of situations where the author does not change the context of the user by pulling way focus in that manner; the author is content with assuming a user will see the new content being added.
I'm not happy with the way the wording got changed from 'user agents including assistive technology' to just assistive technologies. But that was an edit requested during review of the SC language. I'd prefer that get put back in, as I agree there is not clear reason to not specify user agents. That said, if the info is available to ATs, it is, I believe, by definition available to user agents since they are the ones handling the API. So I'm not sure it doesn't amount to the same thing. |
|
Hello Mike,
Thanks for the explanation.
No I am not missing the point ... if it is injected into the page and
in a manner that is visually distinguishable it does serve as an alert
or status update for the user and then needs the role of alert or such
assigned to it. The heading markup will help one discover that content
if one needs to do so separately.
I am aware WCAG is there to level poor design choices so content is
accessible. That's why I asked about sighted non-AT using PWD groups.
Also, if the intent is to make the new content perceivable, should
this SC not be under Guideline 1.3 then? And at Level A?
Best regards,
Sailesh
…On 12/5/17, Mike Gower ***@***.***> wrote:
@spanchang
> But if that content lacks distinct presentational properties, will that
> content not be difficult for some sighted non-AT using PWD user groups to
> notice?
Possibly. But what presentational properties do you think would ensure all
non-AT using PwDs would notice it? That is in the realm of conjecture. And
if you could define any, would you want to insist those must be used by all
designers? What we can say is that if such text is given an appropriate role
to indicate it is a status message or whatever, that is arguably beneficial
to any AT which wishes to do something with that, for whatever user group.
> It could be a UI design / usability issue too that results in ordinary
> users too missing the changed content
Sure, but the task of the guidelines is not to prevent designers from making
poor designs. It's to try to offset poor design decisions that adversely
affect PwDs to a larger degree.
> If presentational / styling properties are added, it will then be covered
> by SC 1.3.1 because that content has to be programmatically determinable
> too.
I think you're missing the point here. While something that is visually
presented as larger text can be given a heading tag -- which will meet 1.3.1
-- that does nothing to alert anyone to the fact it has been added to the
DOM after page load.
If an author brings such information into the UI as any kind of dialog, then
it is handled fine by existing 2.0 requirements. But there are a growing
list of situations where the author does not change the context of the user
by pulling way focus in that manner; the author is content with assuming a
user will see the new content being added.
Adding new content to the screen can happen from any number of motivations.
We cannot conjecture on what those are. What we have done is attempted to
define text updates that have the purpose of providing status information to
the user. These are the most crucial for any user to detect in near real
time.
> is it a conscious decision to not consider the needs of non-AT using PWD
> groups?
I'm not happy with the way the wording got changed from 'user agents
including assistive technology' to just assistive technologies. But that was
an edit requested during review of the SC language. I'd prefer that get put
back in, as I agree there is not clear reason to not specify user agents.
That said, if the info is available to ATs, it is, I believe, by definition
available to user agents since they are the ones handling the API. So I'm
not sure it doesn't amount to the same thing.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#544 (comment)
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765
|
Ah, I think I understand what you're saying: you want the status role assigned and a requirement for some kind of programmatic indicator through an attribute or whatever that makes the new content meet 1.3.1. Is that it? If that is what you're asking for, that requirement already exists if there is any kind of styling applied to the text. If there's no styling, I agree there is nothing on which to hang an accessibility requirement for 1.3.1 -- other than the basic |
|
Mike, You wrote: |
If the message appears with the same formatting you use on your site for headings, then if the author does not mark it up with a heading tag, it seems like a pretty clear failure of 1.3.1. But as I hope is by now clear, that has little to do with the intent or wording of the Status Changes SC.
Why would failing to put your span inside the H3 have any bearing on whether the new text is surfaced to ATs? I feel like we're speaking at cross purposes here. There are no styling tags in HTML that are going to accomplish providing a 'notice' to users. Where you implement your text in something that causes a change of context, you accomplish that automatically, which is why that use case is excluded.
You are welcome to propose such an SC, but that is an independent issue from what is being tackled here. The H3 in your example does not increase the ability for an AT to surface the new information -- that is accomplished with your proper use of an aria-live attribute. This SC ensures that in a situation like this, the aria-live attribute or an equivalent method of flagging the text is implemented. @spanchang now that the SC has reached CFC and is part of the latest draft, I suggest it makes sense for you to open specific issues for the SC so that they can be considered by the larger working group. |
|
Hi Mike,
<start>Why would failing to put your span inside the H3 have any
bearing on whether the new text is surfaced to ATs? I feel like we're
speaking at cross purposes here. There are no styling tags in HTML
that are going to accomplish providing a 'notice' to users. Where you
implement your text in something that causes a change of context, you
accomplish that automatically, which is why that use case is excluded
... The H3 in your example does not increase the ability for an AT to
surface the new information </end>
I think you are missing the point in this example. The h3 is not the
essence of the example. The span tag within the h3 is styled
differently so it is visually discernible and it has been assigned
aria-live=assertive (i.e. like an alert) so it is instantly detected
by screen readers when presented. In this example it is within the h3
but it could be a separate p-tag too for instance. So the
info-relation now in that example is programmatically determinable
because the span tag has proper semantics / markup.
You said "that requirement already exists if there is any kind of
styling applied to the text", so the example tries to illustrate that.
Sailesh
…On 12/15/17, Mike Gower ***@***.***> wrote:
> Your statement above suggests you agree that failing to mark up the span
> tag within the h3 above the form for the global error message injected to
> the page fails SC 1.3.1 today, correct
If the message appears with the same formatting you use on your site for
headings, then if the author does not mark it up with a heading tag, it
seems like a pretty clear failure of 1.3.1. But as I hope is by now clear,
that has little to do with the intent or wording of the Status Changes SC.
> If so, should the status change SC not exclude such cases?
Why would failing to put your span inside the H3 have any bearing on whether
the new text is surfaced to ATs? I feel like we're speaking at cross
purposes here. There are no styling tags in HTML that are going to
accomplish providing a 'notice' to users. Where you implement your text in
something that causes a change of context, you accomplish that
automatically, which is why that use case is excluded.
> If there's no styling, I agree there is nothing on which to hang an
> accessibility requirement for 1.3.1.
In this case, a new SC under Guideline 1.4 should require that such content
is distinguishable via its presentation properties.
You are welcome to propose such an SC, but that is an independent issue from
what is being tackled here. The H3 in your example does not increase the
ability for an AT to surface the new information -- that is accomplished
with your proper use of an aria-live attribute. This SC ensures that in a
situation like this, the aria-live attribute or an equivalent method of
flagging the text is implemented.
@spanchang now that the SC has reached CFC and is part of the latest draft,
I suggest it makes sense for you to open specific issues for the SC so that
they can be considered by the larger working group.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#544 (comment)
--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765
|
|
I think there is an outstanding task for this SC to be moved to Guideline 1.3, Adaptable. Its current home under 3.2, Predictable, seems very much incorrect. Anyone disagree? |
|
Closing issue, since SC has been added to December published working draft. |
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.
The text was updated successfully, but these errors were encountered: