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

It also has impact on the 1.3.2 meaningful sequence SC, and of course depending on what the new content consists of every other SC might come into play.

There is no SC right now that relates to notification of changes in general, so that is something that we can consider moving forward.  It wasn’t practical even in HTML content when WCAG 2.0 was published.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility and Standards
Adobe 

akirkpat@adobe.com
http://twitter.com/awkawk








On 5/6/16, 08:48, "Jonathan Avila" <jon.avila@ssbbartgroup.com> wrote:

>> I think WCAG currently lacks an SC that essentially says something along the lines of "When content/structure/functionality is changed dynamically (either automatically or as a result of a user interaction), ensure that this change is conveyed to the user" (probably single or double A).
>
>I believe this would currently fall under SC 4.1.2.    That SC talks about events and APIs and that is the likely way this information would be communicated.
>
>For example, F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur is mapped to SC 4.1.2
>
>Jonathan
>
>Jonathan Avila
>Chief Accessibility Officer
>SSB BART Group 
>jon.avila@ssbbartgroup.com
>703.637.8957 (Office)
>
>Visit us online: Website | Twitter | Facebook | Linkedin | Blog
>Check out our Digital Accessibility Webinars!
>
>
>-----Original Message-----
>From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
>Sent: Friday, May 06, 2016 4:22 AM
>To: public-mobile-a11y-tf@w3.org; w3c-wai-gl@w3.org
>Cc: lisa.seeman
>Subject: New SC relating to notifications of content change (was Re: Some thinking around the orientation discussion)
>
>[Copying this to the WAI-GL list, as I think this is far more general / not directly related to only the mobile TF or even cognitive TF]
>
>I think WCAG currently lacks an SC that essentially says something along the lines of "When content/structure/functionality is changed dynamically (either automatically or as a result of a user interaction), ensure that this change is conveyed to the user" (probably single or double A).
>
>While what prompted me originally was the scenario of
>
>- a user flips their mobile/tablet device from landscape to portrait, and the overall page layout/structure/functionality changes (e.g. new UI elements are added/shown, components such as carousels turn into accordions, the overall view in a calendar flips from "today's schedule" 
>to "this month's overview" or similar)
>
>I'm actually thinking about something more broad and generic - not necessarily related to responsive designs per se, but also covering situations like:
>
>- a user changes some filtering options/controls at the top of a results/catalogue page, and (without reloading the page altogether) the list of items further down the page is dynamically updated; generally, we'd advise people to add an aria live region (usually hidden) that simply states "results listing updated (showing 10 of 50)" or similar, so that an AT user can get notification that another part of the page has changed (without an actual change in context)
>
>- some content on the page is auto-updated - so not as a result of a user action, but based on other factors (e.g. a timer, a push notification coming from the server, etc)
>
>But yes, this would also cover - in the specific context of what we discussed - device orientation change, and a resulting change of layout which also fundamentally changes functionality/layout/structure.
>
>4.1.2 currently covers notifications/changes of state on a control itself (so that users get notified if, for instance, the interface component that the user is currently on changes in functionality/value/meaning), but WCAG doesn't - to my knowlede anyway - contain an SC about notifying users of changes elsewhere in the page...and this, particularly for dynamic sites, is arguably needed.
>
>The timing aspect of auto-updating content is covered/touched on in 2.2.2, but I don't believe it actually covers the *notification* of the auto-update itself, only having the ability to pause/stop/hide these auto-updates.
>
>But there is, I think, a gap here - no SC that specifically calls for users to be notified of fundamental/substantive changes to the current page.
>
>Sufficient technique wise, we'd probably be looking at (for HTML/JS/ARIA
>technologies) things like:
>
>- move the focus programmatically to the changed content - but be careful of not falling foul of 3.2.2 / change of context (and particularly if the user is likely to be in the middle of some other activity, such as working their way through filtering/refining search results, it would be inappropriate to yank their focus to the updated results, as they may not even have been done with their filtering)
>
>- notify the user with a hidden aria-live region (as described above), which would allow for a change notification without change of context / yanking the user away from their current activity/focus
>
>Thoughts?
>
>P
>
>On 06/05/2016 01:43, David MacDonald wrote:
>> I agree... it is a good point in a responsive world where sections get 
>> dropped off ... do you have some proposed language?
>>
>>   I'm wondering what type of mechanism we might propose to notify a 
>> user of what is gone from a page and how to get it back...
>>
>> The Cognitive team have looked at simplifying interfaces dropping off 
>> content that is not central to the point of the page, that might be 
>> pertinent to this success criteria
>>
>> They proposed an attribute "@aria-importance": {"high"} This might be 
>> an area we would want to stay in close contact with them about...
>>
>> Cheers,
>> David MacDonald
>>
>> *Can**Adapt**Solutions Inc.*
>>
>> Tel:  613.235.4902
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> twitter.com/davidmacd <http://twitter.com/davidmacd>
>>
>> GitHub <https://github.com/DavidMacDonald>
>>
>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>
>> /  Adapting the web to *all* users/
>>
>> /            Including those with disabilities/
>>
>> If you are not the intended recipient, please review our privacy 
>> policy <http://www.davidmacd.com/disclaimer.html>
>>
>> On Thu, May 5, 2016 at 7:42 PM, Patrick H. Lauke 
>> <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote:
>>
>>     On 05/05/2016 17:50, David MacDonald wrote:
>>
>>         Added to WIKI
>>
>>         
>> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_3.4

>> .1
>>
>>
>>     I was going to comment on the line about "Changes in orientation
>>     must be programmatically exposed", but I see that in the latest edit
>>     on the wiki that has been removed. Just to say I approve of this,
>>     partially because it's usually the domain of the OS/AT to announce
>>     an orientation change.
>>
>>     I *can* see that in certain situations it would be useful to
>>     announce to the user if something changed in the current page/view
>>     as a result of an orientation change (e.g. a completely different
>>     layout is introduced with more/less navigation options,
>>     functionalities, etc), but this is probably something that falls
>>     under the need to have a more generic "if parts of the page change,
>>     this change should be announced to the user" SC (which, at least for
>>     interface components, is probably covered by 4.1.2, but not for
>>     non-user-interface cases.
>>
>>     For this latter part, is it worth proposing/thinking about another
>>     SC (which is, once again, not really "mobile" specific)?
>>
>>
>>     P
>>     --
>>     Patrick H. Lauke
>>
>>     www.splintered.co.uk <http://www.splintered.co.uk> |
>>     https://github.com/patrickhlauke

>>     http://flickr.com/photos/redux/ | http://redux.deviantart.com

>>     twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>>
>
>
>--
>Patrick H. Lauke
>
>www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com

>twitter: @patrick_h_lauke | skype: patrick_h_lauke
>

Received on Friday, 6 May 2016 17:07:35 UTC