Re: Proposal: expanding/modifying Guideline 2.1 and its SCs (2.1.1, 2.1.2, 2.1.3) to cover Touch+AT

I too was on the fence until I realized the proposal replaces the SC we
spent 4 months formulating, meticulously wording for consensus.  I'd be
fine if we magically found a super elegant higher level solution that
replaces what we worked so hard on, but I'm just not seeing that right now,
and I don't have a lot of motivation to pour another 100 personal hours
into this one to solve it's current language problems and research its
unanswered questions, and plug its holes.

I think it's probably premature for the industry, but I could get back on
the fence, if we explicitly require Keyboard in the proposal not as an
example but as a fundamental part of the definition, and we specifically
require functionality to work with system remapping AT turned on, which is
my biggest concern with mobile a11y.

Having said that, I don't see the advantage of this omnibus approach, over
separate SCs that can get consensus piece by piece. Maybe once we gain
consensus from the wider group on the separate issues, we could cycle back
with a combination approach, if we actually do end up with the same
language in 6 SCs. And we can make it clear that that is our intention.

This is the type of thing we could try to solve after the December deadline
to get new SCs past the larger group.







Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Fri, Jul 15, 2016 at 8:41 AM, Detlev Fischer <detlev.fischer@testkreis.de
> wrote:

> Patrick, I agree that there is probably nothing the author can do to
> secure the
> same behaviour, and agree that these platform specific differences do not
> mean
> that content would not meet WCAG.
>
> Forget also the mention of h3 not being read - that's beside the point
> here and
> only noted to highlight another difference between desktop and mobile
> experience.
>
> There is however the aria-hidden technique which made this 'work' (sort
> of) on
> mobile and which is only needed here - without it, the focus would wander
> off
> into the page below the dialog. Seen from a testing and authoring view,
> only if I
> include touch in my a11y baseline would I need to think about such an
> aria-hidden
> technique (that could be one reason to group it under a separate SC - but
> having
> said that, I currently find myself sitting on the fence on this issue).
> Things
> like "apply aria-hidden to background of popup divs" are probably 'repair
> techniques' that would no longer be necessary once mobile AT would honor
> the
> scripted focus handling (but I am actually not sure this would be
> desirable).
>
> Getting more cases of 'gaps' will help deciding what might be left for
> authors to
> do. This is just one example, I'd like to see more. (David, it was your
> concern -
> do you have others)?
>
> Detlev
>
> ---
>
> Patrick H. Lauke schrieb am 15.07.2016 13:57:
>
> > On 15/07/2016 12:45, Detlev Fischer wrote:
> >
> >> --------- Example 1: pop-up dialog (
> >> http://www.3needs.org/en/testing/code/role-dialog-3.html  ) #
> >> Keyboard navigation: Dialog can be opened with enter, dialog h3
> >> (linked via aria-labelledby) is announced, the kb focus kept inside
> >> dialog and moved back to trigger when dialog is closed. # Swipe
> >> navigation (iOS/VoiceOver): Dialog can be opened with double tap,
> >> dialog h3 not read,
> >
> > I'd be careful here - whether the h3 is announced or not has nothing to
> > do with input/navigation, which is what we're focusing on here.
> > Otherwise we start conflating things again and getting ourselves tangled
> > in implementation-specific differences, levels of AT support, etc.
> >
> >> kb focus is not kept in dialog but moves to
> >> browser chrome. But swiping back moves straight to last element in
> >> dialog.
> > > # Swipe navigation (Android/TalkBack): Dialog can be opened
> >> with double tap, dialog h3 not read,
> >
> > Ditto.
> >
> >> kb focus is not kept in dialog
> >> but moves to browser chrome. Swiping back does NOT return to focus
> >> last element in dialog.
> >
> > This is also platform-specific behavior on Android - that the focus
> > doesn't cycle back from the browser chrome to the last element in the
> > web content view. Nothing an author can do about it.
> >
> >> So there is are differences in terms of sequential navigation. The
> >> author advice (via @cookiecrook) to ensure that the AT swiping focus
> >> doesn't wander off into the page background was to apply aria-hidden
> >> to the rest of the page AFTER moving focus to the dialog div. So this
> >> is something that might be captured as an ARIA technique for meeting
> >> SC 2.4.3 - but note that even then, on both touch+AT cases there is
> >> no way of keeping the focus in the dialog. ---------
> >
> > And these are beyond author control, and arguably part of the standard
> > behavior for the platform?
> >
> >> Even if the example does not directly address 2.1.1, it makes the
> >> point that there are differences regarding navigation when comparing
> >> desktop kayboard and sequential touch+AT navigation.
> >
> > There are differences for sure, but the fundamental problem that the SCs
> > want to address (that you CAN actually control/activate/use things with
> > this navigation method, and that you don't get trapped) seems orthogonal
> > to this, to me anyway. Even with those differences, can you build
> > content that satisfies the SCs? I'd say yes.
> >
> >> I think it also ultimately helps deciding whether we need to
> >> generalise SCs so they also address non-pointer input or whether we
> >> will fare better with separate SCs. Agree?
> >
> > Absolutely, yes.
> >
> > Incidentally (and perhaps a bit controversially) I also just filed
> > https://github.com/w3c/Mobile-A11y-Extension/issues/6 (as we seem to
> > have even more input-specific things lurking, but that is likely a
> > separate discussion which we should have in a separate fresh email
> thread)
> >
> > 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
> >
>
>
>
>