- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Wed, 11 May 2016 16:33:24 -0400
- To: Gregg Vanderheiden <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>
"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 Wednesday, 11 May 2016 20:33:53 UTC