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

On 09/05/2016 22:10, Sailesh Panchang wrote:
> I point out that SC 3.2.2 says, "... unless the user has been advised
> of the behavior before using the component".
> So often in situations of checkboxes for filters sometimes accompanied
> with a sort feature too, if things are happening dynamically in an
> 'non-visual' manner, I suggest they need to include a visual
> notification advising users of the behavior

Per 3.2.2 this should be a notification *prior* to actually doing 
anything, right?

> or   placement of a
> go-button that triggers the change only on user request.

For both, I would say that many sites (certainly search options on 
shopping sites) regularly *don't* do this, and arguably for good reason 
- many users want to tick boxes/filters and see immediate dynamic 
changes happen. It's now mostly expected behavior for many users, and 
going back to an explicit submit/go button will often not be an 
acceptable compromise.

And even if there was a submit/go button, and a user activates it...if 
the result is a "silent" dynamic update of search results in another 
part of the page, but nothing is exposed to the user which may prompt AT 
to aknowledge that something actually happened, the user will have no 
idea if what they just activated had any discernible effect, or if there 
was a JS error, or the site is badly coded and only reacts on mouseup 
rather than click, or...

Also, here I'd argue that on a page with search results and filter 
options, when just the search results are dynamically updated, arguably 
it's *not* necessarily a change of context in the sense of point 4 
"content that changes the meaning of the Web page." 
https://www.w3.org/TR/WCAG20/#context-changedef - the meaning is still 
the same, just the actual results are different. The page didn't 
transmogrify from being a search page into being something else, like an 
image gallery or whatever...

> I agree, using title / aria-label  and aria-live / aria-controls can
> be included in the recommendations.
> A title attribute helps AT users and mouse users ... user agents
> really should be  made to support title  for keyboard users too. [1]
 > [1] 
https://blogs.windows.com/msedgedev/2016/04/20/building-a-more-accessible-web-platform/

(and although you point to an article about plans for Edge to become 
more accessible, as pointed out in another thread - on WebAIM I believe 
- IE11 and Edge actually do show title as a tooltip in Win8 and Win10 
already...so really, it's all the other browsers that need to catch up :) )

>
> Also updating table caption / heading  above the newly  displayed
> content  / search / filtered results  and judicious use of aria-live
> helps.
> Depending on situation and context,  one can use the present SCs
> notably 3.2.2, 1.3.2, 2.4.3    at most times.

Depending on the various interpretations of what is and isn't a "change 
of context", and only for situation where something is a result of 
either focus or action/activation. So quite a few loopholes and grey 
areas (changes of content that don't arguably change the "meaning" of a 
page, or changes that occur not directly as a result of focus/input, 
such as the originally mentioned flipping from landscape to portrait - 
unless this is stretched to be a "viewport" change, though originally 
that didn't really cover this orientation change scenario - or something 
updated because of a timer, server notification, etc).

> For the update to count of items in cart,  if it is not in viewport
> for anyone or not easily perceivable even by non-PWD,  one can
> highlighht that as a big usability issue generally and that may be
> considered more critical (sadly than even accessibility) by many
> clients and get fixed on a priority basis.

This will heavily depend on lots of other factors again, such as 
viewport size, zoom, potential magnification software being used, etc. 
Many of these can't be tested consistently or detected by authors. And 
what if the update happens right next to whatever the user clicked, but 
this fact/notification isn't apparent to non-sighted AT users anyway? At 
least for this user group, visual proximity is of no relevance.

> Clients can be urged to change the UI design and then with aria-live
> etc. the content can be made accessible as well.
> Defining anew SC can be tricky and create some overlap.

Overlap may not be problematic - I'd say there already are quite a few 
cases of overlap. In fact, if a new more general SC is introduced about 
the general need to somehow notify/provide a mechanism/make a 
programmatically determinable thing that tells the user something 
elsewhere on the same page has changed, then there can be more explicit 
cross-referencing from those SCs that we've discussed so far, where - 
depending on interpretation - some argue it's already covered while 
others don't feel it's actually quite the right fit.

P
-- 
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 Monday, 9 May 2016 23:04:46 UTC