W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2017

2.1 Keyboard Accessible for Mobile/Touch Devices

From: Anton Bolfing <anton.bolfing@access-for-all.ch>
Date: Mon, 16 Oct 2017 09:03:50 +0200
To: <w3c-wai-ig-request@w3.org>, <w3c-wai-ig@w3.org>
Message-ID: <007601d3464c$eb79c040$c26d40c0$@access-for-all.ch>
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?

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

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


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]).

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?


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?


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

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


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?

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


Any documentation/links bringing some light into this are highly


With our best thanks


Anton Bolfing




Dr. Anton Bolfing
Leiter Forschung und Entwicklung

«Zugang für alle»
Schweizerische Stiftung zur
behindertengerechten Technologienutzung
Dörflistrasse 10
CH-8057 Zürich

Tel.        +41 (0)44 515 54 24
E-Mail    <mailto:anton.bolfing@access-for-all.ch>
Web       <http://www.access-for-all.ch/> www.access-for-all.ch/ 
Blog        <http://www.access4all.ch/blog/> www.access4all.ch/blog/
Twitter  <http://twitter.com/access4all> http://twitter.com/access4all

Received on Monday, 16 October 2017 07:04:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:37:11 UTC