- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Mon, 16 Oct 2017 09:23:19 +0100
- To: w3c-wai-ig@w3.org
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