- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Fri, 20 May 2016 12:12:17 -0400
- To: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
- Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
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