DevIntro/Mobile/Upcoming

From Education & Outreach

(DRAFT PAGE 3) Developers' Introduction to Mobile Accessibility: Upcoming

What to expect in WCAG 2.1

WCAG 2.1 will have new success criteria that are especially critical for mobile. Here’s one example:

No accidental activation

Issue: It can be easy to accidentally touch elements on a touchscreen.

Proposed SC:

For single pointer activation, at least one of the following is true:

  • Activation is on the up-event, either explicitly or implicitly as a platform's generic activation/click event;
  • A mechanism is available that allows the user to choose the up-event as an option;
  • Confirmation is provided, which can dismiss activation;
  • Activation is reversible;
  • Down-event activation event is essential and waiting for the up-event would invalidate the activity

Details and discussion of No Accidental Activation

[[[Note from Kim: Some of the items from areas of work under development may make it into 2.1 and should be moved at that point.]]]

Areas of work under development

The WCAG mobile task force is working to point out ways to ensure accessibility on mobile devices.

Here are some of the issues the task force has identified, proposed success criteria for, and generated discussion about. Note that these are all still under discussion and may or may not become part of a standard.

These can be useful as non-normative success criteria for interim consideration by developers.

Character Key Shortcuts

Issue: Character key shortcuts are useful for keyboard users, but detrimental for speech input users.

Proposed solution: Allow input users to turn off or change character key shortcuts.

Discussion: Character Key Shortcuts

Concurrent Input Mechanisms

Issue: Users sometimes use multiple input mechanisms.

Proposed solution: Ensure that all functionality works even when a user switches between input mechanisms.

Discussion: Concurrent Input Mechanisms

Device Sensors

Issue: Some users can’t physically move a mobile device.

Proposed solution: Allow users to operate functionality without requiring device sensor information unless the device sensor is essential for a function and not using it would invalidate the activity.

Discussion: Device Sensors

Keyboard with Assistive Technology

Issue: Some assistive technologies remap keyboard shortcuts.

Proposed solution: Ensure that functions are still available by keyboard when assistive technology is on.

Discussion: Keyboard with Assistive Technology

Non-interference with Assistive Technology

Issue: There can be conflicts between standard mobile technologies and assistive technology that users might have for mobile devices.

Proposed solution: Ensure that content doesn’t interfere with the normal operation of the platform assistive technology.

Discussion: Non-interference with Assistive Technology

Orientation

Issue: Some users can’t change screen orientation on a mobile device.

Proposed solution: Allow users to choose between portrait and landscape orientation unless the orientation is essential for the use of the content.

Discussion: Orientation

Pointer

Issue: Some users require pointer input.

Proposed solution: Ensure that users can operate all functionality using pointer input.

Discussion: Pointer

Pointer Gestures

Issue: Some users can’t use pointer gestures like pinch and zoom.

Proposed solution: Provide a way for users to operate pointer gestures using simple pointer input.

Discussion: Pointer Gestures

Pointer Inputs with Additional Sensors

Issue: Some users can’t use controls that require more than position, e.g. pressure, tilt information.

Proposed solution: Provide a way to operate functionality that doesn’t require information like pressure and tilt.

Discussion: Pointer Inputs with Additional Sensors

Speech Input

Issue: Hidden commands are detrimental for speech input users.

Proposed solution: Provide discoverable, accessible names for screen elements.

Discussion: Speech Input

Target Size

Issue: Some users have trouble using a pointer with small targets.

Proposed solution: Ensure that all users can access touch targets.

Discussion: Target Size

Touch with Assistive Technology

Issue: Some assistive technologies remap touch gestures.

Proposed solution: Ensure that functions are still available by touch when assistive technology is on.

Discussion: Touch with Assistive Technology

Related tips and techniques

[[[Note from Kim:
Alternate layout for the following section:
put each example on a child page and just put links to those pages here, e.g.
1. [PLACEHOLDER example page link Mobile Form Labels]
2. [PLACEHOLDER example page link Touch Target]
]]]

1. Mobile Form Labels

Form layout can be challenging when screen space is at a minimum. A horizontal layout with adjacent label and form makes the form fields difficult to work with because the text is so small. And if you zoom in to see the form input, the label might not be visible on the screen, making it more difficult to complete the form.

Approach 1: Vertically Stacked Forms

Positioning labels above each form element allows both the label and the form element to be visible at the same time. Make sure there is enough spacing between every form element that it is clear which label belongs with each form element.

HTML
<div class="field">
<label for="first">First Name</label>
<input id="first" type="text">
</div>
<div class="field">
<label for="middle">Middle Name</label>
<input id="middle" type="text">
</div>
<div class="field">
<label for="last">Last Name</label>
<input id="last" type="text">
</div>
CSS

.field {
margin-bottom:2em;
}

.field input {
display:block;
}

.field label {
display:block;
}

Approach 2: Vertically Stacked Forms with Floating Labels

It’s popular to minimize the space required for form fields by using placeholder attributes to provide visual labels for the form elements. But the placeholder text goes away after text has been entered, so the "label" is no longer presented visually to the user. This makes it difficult to review entries on a form to ensure they’re correct.

Here’s a different approach that’s more accessible. The label element can be positioned where the placeholder text would normally be positioned. Once a form field receives focus, or when text is entered, the label is repositioned above the form element so the label is still available visually and programmatically.

HTML
<div class="field">
<label for="first">First Name</label>
<input id="first" type="text">
</div>
<div class="field">
<label for="middle">Middle Name</label>
<input id="middle" type="text">
</div>
<div class="field">
<label for="last">Last Name</label>
<input id="last" type="text">
</div>
CSS

.field {
position:relative;
margin-bottom:1em;
}

.field input {
font-size:1em;
padding-top:.75em;
padding-bottom:.75em;
padding-left:0.5em;
}

.field.hasContent input {
padding-top: 1.25em;
padding-bottom:.25em;
}

.field label {
position: absolute;
top: 1em;
left: 1em;
color: #666666;
font-size:1em;
transition: top .2s, left .2s;
}

.field.hasContent label {
top:.25em;
left:.375em;
color:#000;
font-size: 0.8em;
font-weight:bold;
transition: top .2s ease-out, left .2s;
}
JavaScript

var floatingLabelFocus = function() {
this.parentNode.classList.add("hasContent");
};

var floatingLabelBlur = function() {
if(this.value.length > 0){
this.parentNode.classList.add("hasContent");
} else {
this.parentNode.classList.remove("hasContent");
}
};

var classname = document.getElementsByClassName("field");
for (var i = 0; i < classname.length; i++) {
var el = classname[i].getElementsByTagName("input")[0];
if(el.value.length > 0){
el.parentNode.classList.add("hasContent");
}
el.addEventListener('focus', floatingLabelFocus, false);
el.addEventListener('blur', floatingLabelBlur, false);
}

2. Touch Target

PLACEHOLDER

What to watch for

  • Support for smaller screen sizes, including different screen resolutions and sizes and the expectation that screens can be oriented vertically or horizontally
  • Support for users who use multiple input methods, and multiple input methods simultaneously. These may include
  • Touch
  • Gesture
  • Stylus
  • Mouse
  • Keyboard
  • Device sensors including actuator, compass
  • Touch with multiple pressure points
  • Stylus with multiple pressure points and angle variables

Desktop users have long been combining keyboard and mouse on the desktop. Speech input desktop users often combine speech and mouse. Mobile users are increasingly combining touch and speech.

  • Support for specific assistive technology and device accessibility settings

Trialing and contributing

You can contribute to new work under development in WCAG 2.1.

Start by taking a look at the Mobile Accessibility Task Force issues

Acknowledgements

  • Status: [EDITOR’S DRAFT] (PLACEHOLDER] updated PLACEHOLDER
  • Authors: Kim Patch and Kathy Wahlbin
  • Editor: Judy Brewer
  • The Education and Outreach Working Group (EOWG)
  • [Developed with support from the U.S. Access Board, WCAG TA Project] (https://www.w3.org/WAI/WCAGTA/)