Action-24 on MikeS to write a proposal on the importance of the keyboard for a range of other devices.

from mobile-a11y-tf-note.

Mike's email:
Hi All:

devices. (Mobile Accessibility Task Force)
http://www.w3.org/WAI/GL/mobile-a11y-tf/track/actions/24
On: Mike Shebanek
Due: 2015-03-19

Related to my Action item (#24) above, I'm proposing an additional bullet to 3.1 Keyboard Control for Touchscreen Devices to indicate supporting keyboards also benefits people who require alternate input devices that mimic keyboards:

• Those who require alternative input devices such as switch controls that mimic keyboard input

I've also included a proposed revision to the main text for your review. The suggested new text is below followed by the original text.

-- Mike Shebanek

Proposed Text

3.1 Keyboard Control for Touchscreen Devices
Many mobile devices do not include a physical keyboard but instead require a user to interact with an on-screen keyboard that appears only when an interface control that accepts text or numeric input (e.g. a text box or edit field) is selected.

Even though an on-screen keyboard may be provided, many people with disabilities require an alternative software or hardware keyboard solution in order to effectively use one of these mobile devices.

Mobile Touchscreen devices and apps should be operable using a physical keyboard or alternative external input device and provide or support alternative on-screen keyboard layouts. When being operated using a physical keyboard, a mobile device should also provide an easily identified and highly visible keyboard cursor indicator.

Most mobile operating systems include keyboard interfaces but these may require specific coding support. These interfaces enable mobile devices to be operated using external devices such as a wired or wireless physical keyboard, switch device, or an alternative on-screen keyboard such as a scanning keyboard or keyboard layout with fewer, larger or higher-contrast keys.

Supporting these keyboard interfaces benefits people with a variety of disabilities including:

• Those with visual disabilities who benefit from the characteristics of physical keyboards clearly separated keys, such as tactile feedback, key nibs and predictable key layouts.
• Those with dexterity or mobility disabilities who benefit who require keyboards that minimize inadvertent presses (e.g. differently shaped, spaced and guarded keys)
• Those who require alternative input devices such as switch controls that mimic keyboard input
• Those who can be confused by the dynamic nature of onscreen keyboards and who benefit from the consistency of a physical keyboard.

Original Text

3.1 Keyboard Control for Touchscreen Devices
Mobile device design has evolved away from built-in physical keyboards (e.g. fixed, slide-out) towards devices that maximize touchscreen area and display an on-screen keyboard only when the user has selected a user interface control that accepts text input (e.g. a textbox).

However, keyboard accessibility remains as important as ever and most major mobile operating systems do include keyboard interfaces, allowing mobile devices to be operated by external physical keyboards (e.g. keyboards connected via Bluetooth, USB On-The-Go) or alternative on-screen keyboards (e.g. scanning on-screen keyboards).

Supporting these keyboard interfaces benefits several groups with disabilities:

People with visual disabilities who can benefit from some characteristics of physical keyboards over touchscreen keyboards (e.g. clearly separated keys, key nibs and more predictable key layouts). 
People with dexterity or mobility disabilities, who can benefit from keyboards optimized to minimize inadvertent presses (e.g. differently shaped, spaced and guarded keys) or from specialized input methods that emulate keyboard input. 
People who can be confused by the dynamic nature of onscreen keyboards and who can benefit from the consistency of a physical keyboard.

from mobile-a11y-tf-note.

I was also specifically thinking about the fact that - in the case of HTML content at least - authors need to ensure that all content/controls can be reached even using the pure touchscreen+AT swipe left/right gestures (without even having a physical or on-screen keyboard). This arguably stretches the concept of "keyboard" a bit, but to my mind it's the closest fit for basically saying "don't just rely on touchscreen taps, but make sure that content/controls can also receive virtual focus and be read/activated when a user is navigating sequentially using, say, VoiceOver or Talkback with swipe gestures".

Maybe a concrete example can illustrate what I'm getting at. Take the following of a fictitious custom control:

div { width: 5em; height: 5em; background: red }
...
<div onclick="..."></div>

Note that this can be activated fine using a tap on the touchscreen. However, when navigating using VoiceOver/Talkback and left/right swipe gestures, this <div> never receives focus. So, it can't be operated when navigating with the standard input modality of a mobile/tablet AT. Conceptually to me this is a failure of 2.1.1 as applied to mobile.

Unfortunately, which elements do or don't receive focus when navigating with VO/Talkback and swipes seems to be dependent on the specific platform/AT heuristics. Trying the traditional

<div onclick="..." tabindex="0"></div>

doesn't work. For Chrome/Talkback, adding something like an aria-label makes the <div> now focusable

<div onclick="..." aria-label="..."></div>

but this is not enough for Safari/VO. One way to make both happy, and ensure that the custom control receives focus, is to add a role="button"

<div onclick="..." role="button"></div>

(of course, you'd then also want to provide something like aria-label, or title, etc ... but this just illustrates that whether or not certain elements receive virtual focus is not consistent)

Of course, other things like dropdown menus that rely on :hover (and even :focus, depending on platform/AT) also present problems both for touchscreen users in general, and touchscreen+AT users. And again, conceptually, to me this falls under 2.1.1, at least for the touchscreen+AT+swipe gestures case. Am I stretching the definition of 2.1.1 too far here? I'm basically equating touchscreen+AT+swipes to a "keyboard interface" - mainly because it is the primary means by which AT on mobile/tablet is being operated, and because many of the issues we know traditionally from keyboard access problems (things not receiving focus, being dependent on (mouse) hover, etc) often pose exactly the same problems for users with VO/Talkback who navigate with touchscreen swipes to move the virtual focus.

from mobile-a11y-tf-note.

Patrick, thanks for your comments. I wanted to address each one below with my personal thoughts:

authors need to ensure that all content/controls can be reached even using the pure touchscreen+AT swipe left/right gestures (without even having a physical or on-screen keyboard

Agreed. I brought this up at CSUN too. Users with disabilities such as screen reader users shouldn't have to carry around a physical keyboard to access mobile apps -- that's not comparable access as required by standards such as Section 508.

However, when navigating using VoiceOver/Talkback and left/right swipe gestures, this

never receives focus

I am not able to reproduce these results. VO on iOS 8 and from what I recall with prior versions does indeed put all content in the swipe order regardless of tabindex or role. I have not seen this issue. I do agree that we need onclick, keyboard handling, and the tabindex attribute though.

but this is not enough for Safari/VO. One way to make both happy, and ensure that the custom control receives focus, is to add a role="button"

Omitting a role would be a current WCAG failure.

Of course, other things like dropdown menus that rely on :hover (and even :focus, depending on platform/AT) also present problems both for touchscreen users in general,

Yes, ARIA controls such as sliders, comboboxes, and menus pose serious mobile issues because they rely on keyboard structures that don't translate into accessibility service calls on platforms. I documented this at my CSUN presentation on ARIA control support in mobile browsers.

from mobile-a11y-tf-note.

Just to pick up on what I assume was a message on mailing list that I see quoted in that response, about not being able to reproduce the results in VO/iOS8: see http://codepen.io/patrickhlauke/full/raRNrj/ which has 4 variations: just an empty <div onclick="...">, a <div onclick="..." tabindex="0">, a <div onclick="..." role="button"> and a <div onclick="..." role="button" tabindex="0">. Of those, VO only focuses the last two (on account of them having role="button"). In Chrome/Android with TalkBack, only the very last <div> with both role and tabindex receives focus.

Sure, omitting a role would also be a WCAG failure already, but in my view something like <div onclick="..."></div> should also fail this specific SC since it can't be focused, and we should not rely on this being fixed by some other SC taking care of it.

from mobile-a11y-tf-note.

Ø Of those, VO only focuses the last two (on account of them having role="button").

VoiceOver on iOS with Safari allows the user to swipe to interactive and non-interactive content – in my tests I have found this to be the case. I am able to swipe to a div with or without an onclick and with and without a tabindex and with and without roles. I’m sorry I must be misunderstanding something but I can’t reproduce what you are saying.

Can someone else confirm?

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
[email protected]:[email protected]

703-637-8957 (o)
Follow us: Facebookhttp://www.facebook.com/#%21/ssbbartgroup | Twitterhttp://twitter.com/#%21/SSBBARTGroup | LinkedInhttp://www.linkedin.com/company/355266?trk=tyah | Bloghttp://www.ssbbartgroup.com/blog | Newsletterhttp://eepurl.com/O5DP

From: Patrick H. Lauke [mailto:[email protected]]
Sent: Thursday, March 26, 2015 6:36 PM
To: w3c/Mobile-A11y-TF-Note
Cc: Jonathan Avila
Subject: Re: [Mobile-A11y-TF-Note] 3.1 Keyboard Control: mobile SR navigation benefits from focusable elements (#4)

Just to pick up on what I assume was a message on mailing list that I see quoted in that response, about not being able to reproduce the results in VO/iOS8: see http://codepen.io/patrickhlauke/full/raRNrj/ which has 4 variations: just an empty

from mobile-a11y-tf-note.

Did you try my actual example http://codepen.io/patrickhlauke/full/raRNrj/ ? These are <div> elements devoid of actual content. Perhaps an edge case, but I have encountered these sorts of constructs before (with some graphical background included, and styled to be button-like).

I'm actually getting weird behavior at the moment in Safari/iOS where the content of the codepen (the actual four divs) are sometimes not even focused at all and VO only jumps to the footer with the codepen controls...I sometimes have to touch-to-explore first to even get to my demo divs...

from mobile-a11y-tf-note.

Friendly amendment to Mike's
"Mobile Touchscreen devices and apps should be operable using a physical keyboard or alternative external input device and provide or support alternative on-screen keyboard layouts."

to...
"Mobile Touchscreen devices and apps should be operable using a physical keyboard which can also be emulated by an alternative external input device and provide or support alternative on-screen keyboard layouts."

from mobile-a11y-tf-note.