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

Hello Patrickk,
Yes, for 3.2.2 the notification of expected behavior needs to precede
the UI component.
Yes, the Go-button is an older paradigm.
But UI designers need to realize the accessibility challenge they
create. And implementing one of these two choices will change the UI
visually but help accessibility and perhaps usability too. Surely they
can do something else (that almost certainly may involve a UI design
change) as long as they do not pose these challenges.
About search results being silently displayed on the same page after
activating Go button : Yes the user needs a notification say with
aria-live / alert and maybe an updated heading or table caption etc.
If suitable, even moving focus to that content.
This is akin to error messaging when the presence of a global error
message above the form is not exposed to an SR.
Visual proximity of  updated content may not matter to SR users but it
does matter generally as well as for specific PWD user groups.
I agree it is a challenge testing different device sizes, but  it is just that.
Usability and accessibility are in reality platform and device size
specific. Something may work on laptop and responsively say, on
phones / tablets of certain sizes but not on other sized  phones and
tablets.
When application / content owner is made aware of this, they need to
address it if it matters to them.
And about support for title: Yes, I agree it is other browsers that
need to fall in line. I was trying to point to progress made on  Win
10 / Edge in this regard. Better support for title will allow
developers to employ it to notify users of expected behavior of
certain controls and not actually place a separate visual notification
on the screen.
Thanks,
Sailesh

On 5/9/16, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 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 Tuesday, 10 May 2016 15:29:58 UTC