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

Great information and discussion.

Another example I see a lot of is the selection of one radio button in a form will display different additional form fields that were not previously displayed. For example: selecting insurance type radio buttons of Medical or Dental will each have their own set of sub form fields that were not displayed prior to selecting either of them.

Alan

Sent from Mail for Windows 10

From: Sailesh Panchang
Sent: Wednesday, May 11, 2016 4:07 PM
To: Patrick H. Lauke
Cc: w3c-wai-gl@w3.org; public-mobile-a11y-tf@w3.org
Subject: Re: New SC relating to notifications of content change (was Re: Some thinking around the orientation discussion)

Here is a proposal :
Level AA SC:"Changes in content on a Web page made by auto updates or
as a result of user action  that convey information or indicate an
action are made with user awareness unless the user has opted to turn
off notification of such changes".

This may cover change in content:
1. based on filter / sort selections of data already displayed on page or
2. addition(+/-) to cart or
3. a notification that 'support by chat' is available for this task at hand, or
4. results of form submission when they are displayed on same page
5. a global error message placed above the form saying "form
submission failed etc." or a thank you message after completion of a
multi-step process, or
6. on switching from grid view to list view, or
7. in data table when sort column is changed, or
8. on selecting a different pagination link

Above are illustrative.

The Intent doc of Understanding doc should clarify that it does not
cover changes like:
change in content as a result of a user  selecting Tab C instead of
Tab A or opening / closing a menu as these are addressed by 4.1.2
Nor will it cover clicking a link or button that  opens up a dialog or
tooltip. These are already covered.

Thanks,
Sailesh



On 5/11/16, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> Patrick,
> About 2 step interaction: It is not me who is asking this as you
> wrongly conclude.
> this is what G80 (and H32 / H84) recommend. In suggesting this, my
> purpose is to point to one method in which 3.2.2 can be met. Notifying
> user of the expected behavior is another.
> Sailesh
>
>
> On 5/11/16, Patrick H. Lauke <redux@splintered.co.uk> wrote:
>> On 10/05/2016 16:03, Sailesh Panchang wrote:
>>> 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.
>>
>> Taking the Go button case though, you're not simply asking for a visual
>> change in the UI - you're asking for an interaction change. You're
>> asking developers not to use a one-click/one-tap method that works well
>> for the majority of their users (simply activating a checkbox/radio
>> button to dynamically filter search/catalogue results) and instead
>> implementing a two-step method (activating the checkbox/radio button,
>> then pressing Go). It's a much harder sell.
>>
>>> 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.
>>
>> And this brings us back to the point of this thread: WCAG does not have
>> a provision/SC for this sort of thing.
>>
>>> 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 didn't say that it didn't matter. I said that proximity cannot be used
>> as a determining factor exactly *because* it doesn't matter for all
>> users (e.g. SR users), so it would not be a suitable clause to be used
>> in SC wording.
>>
>>> 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.
>>
>> I don't dispute that it's a challenge and a reality. But again, this
>> comes down to having universally testable and determinable clauses in
>> SCs. I would argue that having an SC which may pass on one screen size
>> but fail on another - i.e. the pass/fail determination is completely
>> dependent on the auditor's actual device - is a highly subjective and
>> brittle basis for an SC that is guaranteed to make the SC completely
>> useless and uninforceable in practice. "But your honour, when I tested
>> this site on all our devices, it passed..."
>>
>>> When application / content owner is made aware of this, they need to
>>> address it if it matters to them.
>>
>> But for that to happen they need consistent and testable criteria to
>> base their assessment/fixes on. Again, having something that is
>> device-specific is not the way to go (see also the whole discussion on
>> touch target sizes in "mm as measured on screen", or large text in
>> "real-world points as measured on screen").
>>
>> 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
>>
>>
>