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

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
>
>

Received on Wednesday, 11 May 2016 20:00:31 UTC