This repository has been archived by the owner on Feb 9, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 21
/
index.html
395 lines (382 loc) · 39.2 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
<!DOCTYPE html>
<html>
<head>
<title>Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile</title>
<meta charset='utf-8'>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
async class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "ED",
shortName: "mobile-accessibility-mapping",
edDraftURI: "https://w3c.github.io/Mobile-A11y-TF-Note/",
noRecTrack: true,
editors: [
{
name: "Kim Patch"
, company: "Redstart Systems"
, companyURL: "http://redstartsystems.com/"
},
{
name: "Jeanne Spellman"
, url: "https://orcid.org/0000-0002-9912-0189"
, company: "W3C"
, companyURL: "https://www.w3.org/"
},
{
name: "Kathy Wahlbin"
, company: "Interactive Accessibility"
, companyURL: "https://www.interactiveaccessibility.com"
}
],
wg: "Mobile Accessibility Task Force",
wgURI: "https://www.w3.org/WAI/GL/mobile-a11y-tf/",
wgPublicList: "public-mobile-a11y-tf",
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/35422/status",
tocIntroductory: true,
};
</script>
<style type="text/css">
div.successcriteria {
border:solid #CCCCCC 1px;
background:#F0F0F0;
padding:.75em;
margin-top:1em;
color: black;
}
</style>
</head>
<body>
<section id='abstract'>
<p>
This document, “Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile” describes how the Web Content Accessibility Guidelines (WCAG) 2.0 [[WCAG20]] and its principles, guidelines, and success criteria can be applied to mobile web content, mobile web apps, native apps, and hybrid apps using web components inside native apps. It provides informative guidance, but does not set requirements. It also highlights the relevance of the User Agent Accessibility Guidelines 2.0 [[UAAG20]] in the mobile context.</p>
<p>This document is intended to become a Working Group Note and is part of a series of technical and educational documents published by the <a href="https://www.w3.org/WAI/">W3C Web Accessibility Initiative (WAI)</a>. </p>
</section>
<section id='sotd'>
<p>
This document is an Editor's Draft being developed by the Mobile Accessibility Task Force (Mobile A11Y TF) operating under the terms of its <a href="https://www.w3.org/WAI/GL/mobile-a11y-tf/work-statement">Work Statement</a> under the joint coordination and review of the<a href="https://www.w3.org/WAI/GL/"> Web Content Accessibility Guidelines Working Group</a> (WCAG WG) and the <a href="https://www.w3.org/WAI/UA/">User Agent Accessibility Guidelines Working Group</a> (UAWG), which is part of the <a href="https://www.w3.org/WAI/">Web Accessibility Initiative</a> (WAI) of the <a href="https://www.w3.org/">World Wide Web Consortium</a> (W3C). </p>
<p>
WCAG 2.0 is a stable web standard. Comments on this document will not affect WCAG 2.0 wording.
</p>
<p>
Publication as an Editors' Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. This document should always be cited as a work in progress. </p>
</section>
<section class="introductory">
<h2 id="intro">Introduction</h2>
<p>This document provides informative guidance (but does not set requirements) with regard to interpreting and applying Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] to web and non-web mobile content and applications. </p>
<p>While the World Wide Web Consortium (W3C)'s W3C Web Accessibility Initiative (WAI) is primarily concerned with web technologies, its guidance is also relevant to non-web technologies. The W3C-WAI has published the Note <a href="https://www.w3.org/TR/wcag2ict/">Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)</a> to provide authoritative guidance on how to apply WCAG to non-web technologies such as mobile native applications. The current document is a mobile-specific extension of this effort. </p>
<p>W3C <a href="https://www.w3.org/Mobile/">Mobile Web Initiative</a> Recommendations and Notes pertaining to mobile technologies also include the <a href="https://www.w3.org/TR/mobile-bp">Mobile Web Best Practices</a> and the <a href="https://www.w3.org/TR/mwabp">Mobile Web Application Best Practices</a>. These offer general guidance to developers on how to create content and applications that work well on mobile devices. The current document is focused on the accessibility of mobile web and applications to people with disabilities and is not intended to supplant any other W3C work. </p>
<section class="introductory">
<h3>WCAG 2.0 and Mobile Content/Applications</h3>
<p><em>"Mobile"</em> is a generic term for a broad range of wireless devices and applications that are easy to carry and use in a wide variety of settings, including outdoors. Mobile devices range from small handheld devices (e.g. feature phones, smartphones) to somewhat larger tablet devices. The term also applies to <em>"wearables"</em> such as "smart"-glasses, "smart"-watches and fitness bands, and is relevant to other small computing devices such as those embedded into car dashboards, airplane seatbacks, and household appliances. </p>
<p>While mobile is viewed by some as separate from <em>"desktop/laptop"</em>, and thus perhaps requiring new and different accessibility guidance, in reality there is no absolute divide between the categories. For example: </p>
<ul>
<li>many desktop/laptop devices now include touchscreen gesture control, </li>
<li>many mobile devices can be connected to an external keyboard and mouse, </li>
<li>web pages utilizing responsive design can transition into various screen sizes even on a desktop/laptop when the browser viewport is resized or zoomed in, and </li>
<li>mobile operating systems have been used for laptop devices. </li>
</ul>
<p>Furthermore, the vast majority of user interface patterns from desktop/laptop systems (e.g. text, hyperlinks, tables, buttons, pop-up menus, etc.) are equally applicable to mobile. Therefore, it's not surprising that a large number of existing WCAG 2.0 techniques can be applied to mobile content and applications (see Appendix A). Overall, <strong>WCAG 2.0 is highly relevant to both web and non-web mobile content and applications</strong>. </p>
<p>That said, mobile devices do present a mix of accessibility issues that are different from the typical desktop/laptop. The "Discussion of Mobile-Related Issues" section that follows, explains how these issues can be addressed in the context of WCAG 2.0 as it exists or with additional best practices. All of the advice in this document can be applied to mobile web sites, mobile web applications, and hybrid web-native applications. Most of the advice also applies to native applications (also known as "mobile apps"). </p>
<p><em>Note:</em> WCAG 2.0 does not provide testable success criteria for some of the mobile-related issues. The work of the Mobile Accessibility Task Force has been to develop techniques and best practices in these areas. When the techniques or best practices don't map to specific WCAG success criteria, they aren't given a sufficient, advisory or failure designation. This doesn't mean that they are optional for creating accessible web content on a mobile platform, but rather that they cannot currently be assigned a designation. The Task Force anticipates that some of these techniques will be included as sufficient or advisory in a potential future iteration of WCAG. </p>
<p>The current document references existing WCAG 2.0 Techniques that apply to mobile platform (see Appendix A) and provides new best practices, which may in the future become WCAG 2.0 Techniques that directly address emerging mobile accessibility challenges such as small screens, touch and gesture interface, and changing screen orientation. </p>
</section>
<section class="introductory">
<h2>Other W3C-WAI Guidelines Related to Mobile</h2>
<section class="introductory">
<h3>UAAG 2.0 and Accessible Mobile Browsers</h3>
<p>The User Agent Accessibility Guidelines (UAAG) 2.0 [<a href="https://www.w3.org/TR/UAAG20/">UAAG2</a>] is meant for the developers of user agents (e.g. web browsers and media players), whether for desktop/laptop or mobile operating systems. A user agent that follows UAAG 2.0 will improve accessibility through its
own user interface, through options it provides for rendering and
interacting with
content, and through its ability to communicate with other technologies,
including assistive technologies.</p>
<p>To assist developers of mobile browsers, the <a href="https://www.w3.org/TR/UAAG20-Reference/">UAAG 2.0 Reference</a> support document contains numerous mobile examples. These examples are also available in a separate list of <a href="https://www.w3.org/TR/IMPLEMENTING-UAAG20/mobile">mobile-related examples</a>, maintained by the <a href="https://www.w3.org/WAI/UA/">User Agent Accessibility Guidelines Working Group (UAWG)</a>. </p>
</section>
<section class="introductory">
<h3>ATAG 2.0 and Accessible Mobile Authoring Tools</h3>
<p>The Authoring Tool Accessibility Guidelines (ATAG) 2.0 [<a href="https://www.w3.org/TR/ATAG20/">ATAG2</a>] provides guidelines for the developers of authoring tools, whether for desktop/laptop or mobile operating systems. An authoring tool that follows ATAG 2.0 will be both more accessible to authors with disabilities (Part A) and designed to enable, support, and promote the production of more accessible web content by all authors (Part B). </p>
<p>To assist developers of mobile authoring tools, the <a href="https://www.w3.org/TR/IMPLEMENTING-ATAG20/">Implementing ATAG 2.0</a> support document contains numerous mobile authoring tool examples. </p>
</section>
</section>
</section>
<h2>Discussion of Mobile-Related Issues</h2>
<section>
<h3>Mobile accessibility considerations primarily related to Principle 1: Perceivable</h3>
<section>
<h4>Small Screen Size</h4>
<p>One of the most common characteristics of mobile devices is the small size of their screens. This limited size places practical constraints on the amount of information that can be effectively perceived by users at any one time, even when high screen resolution might enable large amounts of information to be rendered. The amount of information that can be displayed is even further limited when magnification is used, for example by people with low vision. See <a href="#zoom">2.2 Zoom/Magnification</a>.</p>
<p>Some best practices for helping users to make the most of small screens include </p>
<ul>
<li>Consider mobile when initially designing the layout and relevancy of content. </li>
<li>Where necessary, adapt the information provided on mobile compared to desktop/laptop versions with a dedicated mobile version or a responsive design
<ul>
<li>a dedicated mobile version contains content tailored for mobile use. For example, the content may contain fewer content modules, fewer images, or focus on important mobile usage scenarios. </li>
<li>a responsive design contains content that stays the same, but CSS stylesheets are used to render it differently depending on the viewport width. For example, on narrow screens the navigation menus may be hidden until the user taps a menu button. </li>
</ul>
</li>
<li>Minimizing the amount of information that is put on each page compared to desktop/laptop versions by providing a dedicated mobile version or a responsive design: </li>
<li>Providing a reasonable default size for content and touch controls. See <a href="#targetSize"></href>B.2 Touch Target Size and Spacing</a> to minimize the need to zoom in and out for users with low vision. </li>
<li> Adapting the length of link text to the viewport width. </li>
<li> Positioning form fields below, rather than beside, their labels (in portrait layout) </li>
</ul>
</section>
<section>
<h4 id="zoom">Zoom/Magnification</h4>
<p>A variety of methods allow users to control content size on mobile devices with small screens. Some of these features are targeted at all users (e.g. browser “pinch zoom” features), while others tend to be made available as "accessibility features" targeted at people with visual or cognitive disabilities.</p>
<p><em>Note on reflow</em>: There are important accessibility differences between zoom/magnification features that horizontally reflow content, especially text, and those that do not. When text content is not reflowed, users must pan back and forth as they read each line.</p>
<p>Zoom/Magnification features include the following: </p>
<ul>
<li>OS-level features
<ul>
<li> Set default text size (typically controlled from the display settings) <em>Note</em>: System text size is often not supported by mobile browsers. </li>
<li> Magnify entire screen (typically controlled from the accessibility settings). <em>Note</em>: Using this setting requires the user to pan vertically and horizontally. </li>
<li> Magnifying lens view under user's finger (typically controlled from the accessibility settings) </li>
</ul>
</li>
<li>Browser-level features
<ul>
<li> Set default text size of text rendered in the browser's viewport</li>
<li> Reader modes that render the main content without certain types of extraneous content and at a user-specified text size </li>
<li> Magnify browser's viewport (typically "pinch-zoom"). <em>Note</em>: Using this setting typically requires the user to pan vertically and horizontally, although some browsers have features that re-flow the content at the new magnification level, overriding author attempts to prevent pinch-zoom). </li>
</ul>
</li>
</ul>
</li>
</ul>
<p>The WCAG 2.0 success criterion that is most related to zoom/magnification is </p>
<div class="successcriteria">
<ul><li><strong>1.4.4 Resize text</strong> (Level AA) </li></ul>
</div>
<p>SC 1.4.4 requires text to be resizable without assistive technology up to at least 200 percent. To meet this requirement content must not prevent text magnification by the user. </p>
<p>Some methods for supporting magnification/zoom include: </p>
<ul>
<li>Use techniques that support text resizing without requiring horizontal panning. Relying on full viewport zooming (e.g. not blocking the browser's pinch zoom feature) requires the user to pan horizontally as well as vertically. </li>
<li>Ensure that the browser pinch zoom is not blocked by the page's viewport meta element so that it can be used to zoom the page to at least 200%. Restrictive values for user-scalable and maximum-scale attributes of this meta element should be avoided. While this technique meets the success criteria it is less usable than supporting text resizing features that reflow content to the user's chosen viewport size. </li>
<li>Support for OS text size settings. For web content this will depend on browser support.</li>
<li>Provide on-page controls to change the text size. </li>
</ul>
<p>Accessibility features geared toward specific populations of people with disabilities fall under the definition of assistive technology adopted by WCAG and thus cannot be relied upon to meet success criterion 1.4.4. For example, an OS-level zoom feature that magnifies all platform content and has features to specifically support people with low vision is likely considered an assistive technology. </p>
</section>
<section>
<h4>Contrast</h4>
<p>Mobile devices are more likely than desktop/laptop devices to be used in varied environments including outdoors, where glare from the sun or other strong lighting sources is more likely. This scenario heightens the importance of use of good contrast for all users and may compound the challenges that users with low vision have accessing content with poor contrast on mobile devices. </p>
<p>The WCAG 2.0 success criteria related to the issue of contrast are: </p>
<div class="successcriteria">
<ul>
<li> <strong>1.4.3 Contrast (Minimum)</strong> (Level AA) which requires a contrast of at least 4.5:1 (or 3:1 for large-scale text) and </li>
<li> <strong>1.4.6 Contrast (Enhanced)</strong> (Level AAA) which requires a contrast of at least 7:1 (or 4.5:1 for large-scale text). </li>
</ul>
</div>
<p>SC 1.4.3. allows for different contrast ratios for large text. Allowing different contrast ratios for larger text is useful because larger text with wider character strokes is easier to read at a lower contrast. This allows designers more leeway for contrast of larger text, which is helpful for content such as titles. The ratio of 18-point text or 14-point bold text described in the SC 1.4.3 was judged to be large enough to enable a lower contrast ratio for web pages displayed on a 15-inch monitor at 1024x768 resolution with a 24-inch viewing distance. Mobile device content is viewed on smaller screens and in different conditions so this allowance for lessened contrast on large text must be considered carefully for mobile apps. </p>
<p>For instance, the default text size for mobile platforms might be larger than the default text size used on non-mobile devices. When determining which contrast ratio to follow, developers should strive to make sure to apply the lessened contrast ratio only when text is roughly equivalent to 1.2 times bold or 1.5 times (120% bold or 150%) that of the default platform size. Note, however, that the use of text that is 1.5 times the default on mobile platforms does not imply that the text will be readable by a person with low vision. People with low vision will likely need and use additional platform level accessibility features and assistive technology such as increased text size and zoom features to access mobile content. </p>
</section>
<section>
<h4>Non-Linear Screen Layouts</h4>
<p>With limited screen “real estate” but a variety of gesture options available, mobile developers have experimented with a variety of screen layouts beyond the conventional web paradigm in which the user begins at the “top” and generally works down. Some mobile layouts start the user somewhere in the “middle” and provide highly dynamic visual experiences in which new content may be pulled in from any direction or the user’s point of regard may shift in various directions as previously off-screen content is brought on-screen.</p>
<p>Such user interfaces can be disorienting when the only indicators of the state of the user interface and what is happening in response to user actions are visual. </p>
<p>The WCAG 2.0 success criterion related to the issue of non-linear layouts is: </p>
<div class="successcriteria">
<ul>
<li> <strong>1.3.1 Info and Relationships </strong> (Level A)</li>
<li><strong>1.3.2 Meaningful Sequence</strong> (Level A)</li>
</ul>
</div>
</section>
</section>
<section>
<h3>Mobile accessibility considerations primarily related to Principle 2: Operable</h3>
<section>
<h4 id="keyboardControl">Keyboard Control for Touchscreen Devices</h4>
<p>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). </p>
<p>However, keyboard accessibility remains as important as ever. WCAG 2.0 requires keyboard control at Level A and keyboard control is supported by most major mobile operating systems via keyboard interfaces, which allow mobile devices to be operated using external physical keyboards (e.g. keyboards connected via Bluetooth, USB On-The-Go) or alternative on-screen keyboards (e.g. scanning on-screen keyboards). </p>
<p>Supporting these keyboard interfaces benefits several groups with disabilities: </p>
<ul>
<li> 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). </li>
<li> 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. </li>
<li> People who can be confused by the dynamic nature of onscreen keyboards and who can benefit from the consistency of a physical keyboard. </li>
</ul>
<p>Several WCAG 2.0 success criteria are relevant to effective keyboard control: </p>
<div class="successcriteria">
<ul>
<li> <strong>2.1.1 Keyboard</strong> (Level A) </li>
<li> <strong>2.1.2 No Keyboard Trap</strong> (Level A) </li>
<li> <strong>2.4.3 Focus Order</strong> (Level A) </li>
<li> <strong>2.4.7 Focus Visible</strong> (Level AA) </li>
</ul>
</div>
</section>
<section>
<h4 id="targetSize">Touch Target Size and Spacing</h4>
<p>The high screen resolution of mobile devices means that many interactive elements can be shown together on a small screen. But these elements must be big enough and have enough distance from each other so that users can safely target them by touch. </p>
<p>Best practices for touch target size include the following: </p>
<ul>
<li> Ensuring that touch targets are at least 9 mm high by 9 mm wide, independent of the screen size, device or resolution. </li>
<li> Ensuring that touch targets close to the minimum size are surrounded by a small amount of inactive space. </li>
</ul>
<p><em>Note:</em> Screen magnification should not need to be used to obtain this size, because magnifying the screen often introduces the need to pan horizontally as well as vertically, which can decrease usability. </p>
</section>
<section>
<h4>Touchscreen Gestures</h4>
<p>Many mobile devices are designed to be primarily operated via gestures made on a touchscreen. These gestures can be simple, such as a tap with one finger, or very complex, involving multiple fingers, multiple taps and drawn shapes. </p>
<p>Some (but not all) mobile operating systems provide work-around features that let the user simulate complex gestures with simpler ones using an onscreen menu. </p>
<p>Some best practices when deciding on touchscreen gestures include the following: </p>
<ul>
<li> Gestures in apps should be as easy as possible to carry out. This is especially important for screen reader interaction modes that replace direct touch manipulation by a two-step process of focusing and activating elements. It is also a challenge for users with motor or dexterity impairments or people who rely on head pointers or a stylus where multi-touch gestures may be difficult or impossible to perform. Often, interface designers have different options for how to implement an action. Widgets requiring complex gestures can be difficult or impossible to use for screen reader users. Usually, design alternatives exist to allow changes to settings via simple tap or swipe gestures. </li>
<li> Activating elements via the click event. Using the mouseup or touchend event to trigger actions helps prevent unintentional actions during touch and mouse interaction. Mouse users clicking on actionable elements (links, buttons, submit inputs) should have the opportunity to move the cursor outside the element to prevent the event from being triggered. This allows users to change their minds without being forced to commit to an action. In the same way, elements accessed via touch interaction should generally trigger an event (e.g. navigation, submits) only when the touchend event is fired (i.e. when all of the following are true: the user has lifted the finger off the screen, the last position of the finger is inside the actionable element, and the last position of the finger equals the position at touchstart). <br />
<code class="techniquelLink"><a href="Techniques/M003.html">Technique M003 - Activating elements via the click event</a></code></li>
</ul>
<p>Another issue with touchscreen gestures is that they might lack onscreen indicators that remind people how and when to use them. For example, a swipe in from the left side of the screen gesture to open a menu is not discoverable without an indicator or advisement of the gesture. See <a href="#customTouchscreen">4.6 Provide instructions for custom touchscreen and device manipulation gestures</a>.</p>
<p><em>Note:</em> While improving the accessibility of touchscreen gestures is important, keyboard accessibility is still required by some users and to meet WCAG 2.0. See <a href="keyboardControl"></a>3.1 Keyboard Control for Touchscreen Devices</a>.
</p>
</section>
<section>
<h4>Device Manipulation Gestures</h4>
<p>In addition to touchscreen gestures, many mobile operating systems provide developers with control options that are triggered by physically manipulating the device (e.g. shaking or tilting). While device manipulation gestures can help developers create innovative user interfaces, they can also be a challenge for people who have difficulty holding or are unable to hold a mobile device. </p>
<p>Some (but not all) mobile operating systems provide work-around features that let the user simulate device shakes, tilts, etc. from an onscreen menu. </p>
<p>Therefore, even when device manipulation gestures are provided, developers should still provide touch and keyboard operable alternative control options. See <a href="keyboardControl"></a>3.1 Keyboard Control for Touchscreen Devices</a>.</p>
<div class="successcriteria">
<ul>
<li><strong>2.1.1 Keyboard</strong> (Level A)</li></ul>
</div>
<p>Another issue with control via device manipulation gestures is that they might lack onscreen indicators that remind people how and when to use them. See <a href="#customTouchscreen">Touchscreen gesture instructions</a>. See <a href="#customTouchscreen">4.6 Provide instructions for custom touchscreen and device manipulation gestures</a>.</p>
</section>
<section>
<h3>Placing buttons where they are easy to access</h3>
<p>Mobile sites and applications should position interactive elements where they can be easily reached when the device is held in different positions. </p>
<p>When designing mobile web content and applications many developers attempt to optimize use with one hand. This can benefit people with disabilities who may only have one hand available, however, developers should also consider that an easy-to-use button placement for some users might cause difficulties for others (e.g. left- vs. right-handed use, assumptions about thumb range of motion). Therefore, flexible use should always be the goal. </p>
<p>Some (but not all) mobile operating systems provide work-around features that let the user temporarily shift the display downwards or sideways to facilitate one-handed operation. </p>
</section>
</section>
<section>
<h3>Mobile accessibility considerations related primarily to Principle 3: Understandable</h3>
<section>
<h4>Changing Screen Orientation (Portrait/Landscape)</h4>
<p>Some mobile applications automatically set the screen to a particular display orientation (landscape or portrait) and expect that users will respond by rotating the mobile device to match. However, some users have their mobile devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair). </p>
<p>Therefore, mobile application developers should try to support both orientations. If it is not possible to support both orientations, developers should ensure that it is easy for all users to change the orientation to return to a point at which their device orientation is supported. </p>
<p>Changes in orientation must be programmatically exposed to ensure detection by assistive technology such as screen readers. For example, if a screen reader user is unaware that the orientation has changed the user might perform incorrect navigation commands. </p>
</section>
<section>
<h4>Consistent Layout</h4>
<p>Components that are repeated across multiple pages should be presented in a consistent layout. In responsive web design, where components are arranged based on device size and screen orientation, web pages within a particular view (set size and orientation) should be consistent in placement of repeated components and navigational components. Consistency between the different screen sizes and screen orientations is not a requirement under WCAG 2.0. </p>
<p>For example: </p>
<ul>
<li> A Web site has a logo, a title, a search form and a navigation bar at the top of each page; these appear in the same relative order on each page where they are repeated. On one page the search form is missing but the other items are still in the same order. When the Web site is viewed on a small screen in portrait mode, the navigation bar is collapsed into a single icon but entries in the drop-down list that appears when activating the icon are still in the same relative order. </li>
<li> A Web site, when viewed on the different screen sizes and in different orientations, has some components that are hidden or appear in a different order. The components that show, however, remain consistent for any screen size and orientation. </li>
</ul>
<p>The WCAG 2.0 success criteria that are most related to the issue of consistency are: </p>
<div class="successcriteria">
<ul>
<li> <strong>3.2.3 Consistent Navigation</strong> (Level AA) </li>
<li> <strong>3.2.4 Consistent Identification</strong> (Level AA) </li>
</ul>
</div>
</section>
<section>
<h4>Positioning important page elements before the page scroll</h4>
<p>The small screen size on many mobile devices limits the amount of content that can be displayed without scrolling. </p>
<p>Positioning important page information so it is visible without requiring scrolling can assist users with low vision and users with cognitive impairments. </p>
<p>If a user with low vision has the screen magnified only a small portion of the page might be viewable at a given time. Placing important elements before the page scroll allows those who use screen magnifiers to locate important information without having to scroll the view to move the magnified area. Placing important elements before the page scroll also makes it possible to locate content without performing an interaction. This assists users that have cognitive impairments such as short-term memory disabilities. Placing important elements before the page scroll also helps ensure that elements are placed in a consistent location. Consistent and predictable location of elements assists people with cognitive impairments and low vision. </p>
</section>
<section>
<h4>Grouping operable elements that perform the same action</h4>
<p>When multiple elements perform the same action or go to the same destination (e.g. link icon with link text), these should be contained within the same actionable element. This increases the touch target size for all users and benefits people with dexterity impairments. It also reduces the number of redundant focus targets, which benefits people using screen readers and keyboard/switch control. </p>
<p>The WCAG 2.0 success criterion that is most related to grouping of actionable elements is: </p>
<div class="successcriteria">
<ul>
<li> <strong>2.4.4 Link Purpose (In Context) </strong>(Level A) </li>
<li> <strong>2.4.9 Link Purpose (Link Only)</strong> (Level AA) </li>
</ul>
</div>
<p>For more information on grouping operable elements, see <a href="https://www.w3.org/WAI/GL/WCAG20-TECHS/H2.html">H2: Combining adjacent image and text links for the same resource</a> technique. </p>
</section>
<section>
<h4>Provide clear indication that elements are actionable</h4>
<p>Elements that trigger changes should be sufficiently distinct to be clearly distinguishable from non-actionable elements (content, status information, etc.). Providing a clear indication that elements are actionable is relevant for web and native mobile applications that have actionable elements like buttons or links, especially in interaction modes where actionable elements are commonly detected visually (touch and mouse use). Interactive elements must also be detectable by users who rely on a programmatically determined accessible name (e.g. screen reader users). </p>
<p>Visual users who interact with content using touch or visual cursors (e.g. mice, touchpads, joysticks) should be able to clearly distinguish actionable elements such as links or buttons. Existing interface design conventions are aimed at indicating that these visual elements are actionable. The principle of redundant coding ensures that elements are indicated as actionable by more than one distinguishing visual feature. Following these conventions benefits all users, but especially users with vision impairments. </p>
<p>Visual features that can set an actionable element apart include shape, color, style, positioning, text label for an action, and conventional iconography. </p>
<p>Examples of distinguishing features: </p>
<ol>
<li> Conventional shape: Button shape (rounded corners, drop shadows), checkbox, select rectangle with arrow pointing downwards </li>
<li> Iconography: conventional visual icons (question mark, home icon, burger icon for menu, floppy disk for save, back arrow, etc.) </li>
<li> Color offset: shape with different background color to distinguish the element from the page background, different text color </li>
<li> Conventional style: Underlined text for links, color for links </li>
<li> Conventional positioning: Commonly used position such as a top left position for back button (iOS), position of menu items within left-aligned lists in drop-down menus for navigation </li>
</ol>
<p>The WCAG 2.0 success criteria do not directly address issue of clear visual indication that elements are actionable but are related to the following success criteria: </p>
<div class="successcriteria">
<ul>
<li> <strong>3.2.3 Consistent Navigation</strong> (Level AA) </li>
<li> <strong>3.2.4 Consistent Identification</strong> (Level AA) </li>
</ul>
</div>
</section>
<section>
<h4 id="customTouchscreen">Provide instructions for custom touchscreen and device manipulation gestures</h4>
<p>The ability to provide control via custom touchscreen and device manipulation gestures can help developers create efficient new interfaces. However, for many people, custom gestures can be a challenge to discover, perform and remember. </p>
<p>Therefore, instructions (e.g. overlays, tooltips, tutorials, etc.) should be provided to explain what gestures can be used to control a given interface and whether there are alternatives. To be effective, the instructions should, themselves, be easily discoverable and accessible. The instructions should also be available anytime the user needs them, not just on first use, though on first use they may be made more apparent through highlighting or some other mechanism. </p>
<p>These WCAG 2.0 success criteria are relevant to providing instructions for gestures: </p>
<div class="successcriteria">
<ul>
<li> <strong>3.3.2 Labels or Instructions</strong> (Level A) </li>
<li> <strong>3.3.5 Help</strong> (Level AAA) </li>
</ul>
</div>
</section>
</section>
<section>
<h3>Mobile accessibility considerations related primarily to Principle 4: Robust</h3>
<section>
<h4>Set the virtual keyboard to the type of data entry required</h4>
<p>On some mobile devices, the standard keyboard can be customized in the device settings and additional custom keyboards can be installed. Some mobile devices also provide different virtual keyboards depending on the type of data entry. This can be set by the user or can be set to a specific keyboard. For example, using the different HTML5 <code>input</code> types - such as <code><input type="tel"></code> (see <a href="https://www.w3.org/TR/html5/forms.html#states-of-the-type-attribute">HTML5: States of the <code>type</code> attribute</a>) - on a website will show different keyboards automatically when users are entering information into that field. Setting the type of keyboard helps prevent errors and ensures formats are correct but can be confusing for people who are using a screen reader when there are subtle changes in the keyboard. </p>
</section>
<section>
<h4>Provide easy methods for data entry</h4>
<p>Users can enter information on mobile devices in multiple ways such as on-screen keyboard, Bluetooth keyboard, touch, and speech. Text entry can be time-consuming and difficult in certain circumstances. Reduce the amount of text entry needed by providing select menus, radio buttons, check boxes or by automatically entering known information (e.g. date, time, location). </p>
</section>
<section>
<h4>Support the characteristic properties of the platform</h4>
<p>Mobile devices provide many features to help users with disabilities interact with content. These include platform characteristics such as zoom, larger fonts, and captions. The features and functions available differ depending on the device and operating system version. For example, most platforms have the ability to set large fonts, but not all applications honor it for all text. Also, some applications might increase font size but not wrap text, causing horizontal scrolling. </p>
</section>
</section>
<section class='appendix'>
<h2>WCAG Techniques that apply to mobile</h2>
<p><a href="https://www.w3.org/WAI/GL/mobile-a11y-tf/MobileTechniques/">WCAG 2.0 Techniques that Apply to Mobile</a></p>
</section>
<section>
<h2>UAAG 2.0 Success Criteria that apply to mobile</h2>
<p><a href="https://www.w3.org/TR/IMPLEMENTING-UAAG20/mobile.html">UAAG Mobile Accessibility Examples</a></p>
</section>
<section>
<h2>Acknowledgments</h2>
<dl>
<dt>Members of the Mobile Accessibility Task Force: </dt>
<dd>Kathleen Anderson</dd>
<dd>Jonathan Avila</dd>
<dd>Tom Babinszki</dd>
<dd>Matthew Brough</dd>
<dd>Michael Cooper (WCAG WG Staff Contact)</dd>
<dd>Gavin Evans</dd>
<dd>Detlev Fischer</dd>
<dd>Alistair Garrison</dd>
<dd>Marc Johlic</dd>
<dd> </dd>
<dd>Kim Patch (TF Facilitator - UAAG WG)</dd>
<dd>Jan Richards</dd>
<dd>Mike Shebanek</dd>
<dd>Brent Shiver</dd>
<dd>Alan Smith</dd>
<dd>Jeanne Spellman (UAAG WG Staff Contact)</dd>
<dd>Henny Swan</dd>
<dd>Peter Thiessen</dd>
<dd> </dd>
<dd>Kathleen Wahlbin (TF Facilitator - WCAG WG)</dd>
</dl>
<dl>
<dt>Chairs of the WCAG WG and the UAAG WG: </dt>
<dd>Jim Allan (UAAG WG), Texas School for the Blind and Visually Impaired</dd>
<dd>Andrew Kirkpatrick (WCAG WG), Adobe Systems</dd>
<dd>Joshue O'Connor (WCAG WG), NCBI Centre of Inclusive Technology</dd>
</dl>
</section>
</body>
</html>