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

Correct

The question is — if these are BELOW the radio button in question — is there any accessibility problem at all.  ??

gregg

> On May 11, 2016, at 3:20 PM, ALAN SMITH <alands289@gmail.com> wrote:
> 
> Great information and discussion.
>  
> Another example I see a lot of is the selection of one radio button in a form will display different additional form fields that were not previously displayed. For example: selecting insurance type radio buttons of Medical or Dental will each have their own set of sub form fields that were not displayed prior to selecting either of them.
>  
> Alan
>  
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: Sailesh Panchang <mailto:sailesh.panchang@deque.com>
> Sent: Wednesday, May 11, 2016 4:07 PM
> To: Patrick H. Lauke <mailto:redux@splintered.co.uk>
> Cc: w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>; public-mobile-a11y-tf@w3.org <mailto:public-mobile-a11y-tf@w3.org>
> Subject: Re: New SC relating to notifications of content change (was Re: Some thinking around the orientation discussion)
>  
> 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
> >> 
> >> 
> >