RE: New SC relating to notifications of content change (was Re: Some thinking around the orientation discussion)



>-----Original Message-----
>From: Alastair Campbell [mailto:acampbell@nomensa.com]
>Sent: Monday, May 09, 2016 10:03 AM


>Agreed, and that is partly why I think it needs to be done on the
>author/developer side of things. An automated solution (e.g. user-agent
>detecting changes) would be too blunt, it needs to take account of the
>context.

I also agree. We don't want the user to be intrusively informed of every change that occurs in the DOM. This is why ARIA live regions were created.

The challenge lies in specifying which changes should be designated by the author as among those of which the user should be notified. Doing the notifying may require the cooperation of assistive technologies, and may therefore be subject to user control, or may not happen. The author can't be held responsible for such contingencies.
>
>A straw-man SC could be: If the page is updated away from the “Point of
>regard” [1], and the change is important to their task, the user must be
>notified.
>
>The middle part of that (about task) isn’t workable, but that’s what I’m trying
>to get at.


That's a good start. Unfortunately, the user agent can't reliably determine where the point of regard is (whenever it diverges from the focus).

If we consider again the instant messaging application that has previously been discussed as an example, suppose that the user's task is to monitor incoming messages. In this case, notification of changes to the message log is important even if the point of regard is elsewhere, for example in surrounding page navigation elements or in help text.  If the user's task is to write and send a message, then notification of incoming messages is less important, and by your criterion,it need not be provided. I would suggest more strongly that it should be "polite" so far as ARIA is concerned, and should perhaps be suppressed if ARIA is not involved, whenever the user is engaging with the message editing functionality.

Perhaps we should consider two kinds of change: those which occur in response to a user's action but which are not part of the user interface component that has focus, and those which are caused by events from sources other than the user's most recent action, for example timer expiry, incoming data, etc. I think the author should take reasonable measures to enable the user to be notified of changes in the first category, and there aren't any obvious exceptions. The second category is more complicated, and I'm not sure what the distinguishing criterion should be. Reasonable steps include notifying AT that the change is important enough to be conveyed to the user. There may be other desirable steps also in order to assist those who are not relying on AT.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Monday, 9 May 2016 15:31:24 UTC