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

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
>

Received on Friday, 15 July 2016 12:41:30 UTC