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

On 5/11/16, Gregg Vanderheiden RTF <gregg@raisingthefloor.org> wrote:
> If the phrase is used in the SC it will need to be defined.

I believe, any word or phrase that is used normatively in a manner
that conveys a meaning that is different from the one conveyed by it
in general usage or parlance needs to be defined, no?
IMO it does not matter where it is used: in the SC or other normative
content of the doc.
The words "user awareness" in the definition of change in context does
not connote anything more / less than what is generally understood and
does not need a definition. There are other SCs that kick in to make
new content that generally lead to "user awareness" perceivable /
AT-supported.
It is moot now because I believe this particular SC for newly added
content is covered by   WCAG 2.0 IMO.
Yet, a clear understanding of which terms need to be defined will help
as and when new SCs get proposed.
Thanks,
Sailesh Panchang


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

Received on Friday, 20 May 2016 16:12:46 UTC