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

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 11:58:00 UTC