Re: 2.1 Keyboard Accessible for Mobile/Touch Devices

On 16/10/2017 08:03, Anton Bolfing wrote:
> Dear Mailinglist
> 
> I'm writing on behalf of the Swiss «Access for all» foundation. We are 
> currently developing our Mobile Apps Accessibility Certification Process 
> for Switzerland. There, we intend to stick to the WCAG as closely as 
> possible.  And we have one open question which is terribly haunting. I 
> try to make it short and clear:
> 
> It's about 2.1 Keyboard Accessible (for touch screen devices):
> 
> [Maybe you find it easier to answer questions 1) and 2) at the bottom of 
> this email directly, I terribly failed in making it short and clear, 
> nevertheless …]
> 
> 1a. Is it necessary to test mobile apps with an external keyboard in 
> order to check whether [broadly] all functionalities can be accessed and 
> operated using TAB and ARROW keys?

Yes.

> 1b. Is there a way to operate mobile devices by keyboard without having 
> a screen reader up and running? (what about focus visibility, ...)

Keyboards on iOS devices without VO running only work in the same 
situation as when the on-screen keyboard is shown (e.g. when focused on 
a text field, URL entry field, etc). On Android and Windows Phone 
however, keyboard works in all situations and behaves pretty much like 
on desktop (e.g. you can run Android with keyboard and no TalkBack, and 
you should still be able to use TAB, ENTER, ARROW keys etc to 
navigate/activate things).

> 1c. What alternative input device would you recommend testing 2.1 with? 
> A switch access device maybe?

Switch access devices are generally keyboard-like in that the end result 
is a key event/press. So technically, as long as it works with keyboard 
it should work with switch access as well without needing extra testing 
(though I'll admit my knowledge in this area is not that deep, so happy 
to be corrected).

Playing a bit with iOS switch access, it seems that it sets focus to 
groups/sections of web content (not just focusable elements). So it 
seems that even non-keyboard-focusable elements should work with switch 
access to an extent (though this would benefit from further testing).

> 2a. Would it make sense to interpret "2.1 Keyboard Accessible" as "2.1 
> Sequential Navigation"? This would allow to test whether all 
> functionalities can be operated by screen reader (swipe gestures 
> [VoiceOver, TalkBack]). Right?

Yes, at least that has been my/The Paciello Group's interpretation. Note 
that there has been some early discussion in the run-up for WCAG 2.1 to 
modify the wording of Keyboard Accessible to conceptually include these 
sorts of things, but this has not been accepted at this point. There are 
more SCs planned for WCAG 2.1 that will (partially) cover some of these 
aspects, but there's likely still gaps here.

> 2b. Is there a way to operate mobile devices sequentially by an input 
> device without having a screen reader up and running? (focus visibility, 
> ...). Switch access?

See answer to 1b.

> 3. Given the equivalent case of a <div> or <img> with an on-click event 
> in JavaScript, which is not accessible/focusable by keyboard (violation 
> of 2.1.1). What WCAG 2.0 guideline/criterion is violated if an app 
> element is not accessible by 3a) an access switch or any other 
> sequential navigation input method and 3b) screen reader swipe gestures?

I'd fail this still under 2.1.1. I'd note that screen reader swipe 
gestures are generally equivalent to reading keys on desktop SRs, so the 
virtual focus generally gets set to anything regardless of whether it's 
a traditionally focusable element or not (e.g. I can swipe to move focus 
to a simple <span>)

> 4a. Since there is no browse/focus mode distinction in App screen 
> readers, what behaviour is expected of keyboard navigation?

See above regarding swipe gesture controlled AT. Note however that, as 
mentioned in 1b, you CAN have actual keyboard navigation on some devices 
- then, in scenarios like Android + physical keyboard + TalkBack, you DO 
have two navigation modes (using TAB/SHIFT+TAB to navigate through 
focusable elements, and cursor keys/swipes to use reading mode).

(btw, when you say "App", do you mean native app, hybrid app, or are you 
still referring to web content in a browser on mobile/tablet? I'd be 
careful with terminology to avoid confusion, as actual native app 
accessibility is a slightly separate subject).

> 4b. Is the equivalent case (see 3.) a realistic scenario?

Yes

> I very much hope that the problem underlying these questions is getting 
> clear. Basically I/we need two answers to it for being able to declare 
> to our customers how we assess accessibility of apps in our upcoming 
> certification process:
> 
> 1)            How to test 2.1 Keyboard Accessible?

Android/Windows phone+external keyboard. Plus, but this is my 
interpretation only, making sure things work with sequential access, can 
be operated using VO/TB and swipe gesture navigation, etc.

> 2)            How to deal with failures of swipe gesture 
> focusability/operability (if not in 2.1)?

I'd include these in 2.1.1.

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 Monday, 16 October 2017 08:24:02 UTC