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

If the phrase is used in the SC it will need to be defined. 

gregg

> On May 11, 2016, at 3:33 PM, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> "User awareness" is  used in the same manner as is used in the
> glossary explaining "change of context". Any other alternative
> wording?
> The SC will need a note to clarify that this does not apply to links
> and such  listed in the exclusions listed  in that email.
> Thanks,
> Sailesh
> On 5/11/16, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote:
>> You have to define specifically what “user awareness” means.
>> 
>> (PS - all links on a page will be triggered by this)
>> 
>> gregg
>> 
>>> On May 11, 2016, at 3:04 PM, Sailesh Panchang <sailesh.panchang@deque.com>
>>> wrote:
>>> 
>>> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>>