This repository has been archived by the owner on Oct 30, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 14
/
index.html
717 lines (685 loc) · 49 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
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
<!DOCTYPE html>
<html>
<head>
<title>Mobile Accessibility WCAG Extension</title>
<meta charset='utf-8'>
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/2016/W3C-WD">
<link rel="stylesheet" type="text/css" href="https://www.w3.org/TR/WCAG20/additional.css"/>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
async class='remove'></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
specStatus: "ED",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "mobile-accessibility-extension",
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle : "an excellent document",
// if you wish the publication date to be other than the last modification, set this
// publishDate: "2009-08-06",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "http://w3c.github.io/Mobile-A11y-Extension/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// editors, add as many as you like
// only "name" is required
editors: [
{
name: "Michael Cooper"
},
{
name: "Kim Patch"
},
{
name: "Jeanne Spellman"
},
{
name: "Kathy Wahlbin"
},
],
// name of the WG
wg: "Mobile Accessibililty Task Force",
// URI of the public WG page
wgURI: "http://www.w3.org/WAI/GL/mobile-a11y-tf/",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-mobile-a11y-tf",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/35422/status",
// !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
maxTocLevel: 2,
};
</script>
<style>
.proposed {background-color:#FFFFCC}
</style>
</head>
<body link="#0563c1" dir="ltr" lang="en-US">
<section id='abstract'>
<p>
The Mobile Accessibility Extension to WCAG 2.0 provides new guidelines, success criteria, and mobile Techniques that are an addition to Web Content Accessibility Guidelines (WCAG) 2.0. This extension does not replace WCAG 2.0. </p>
</section>
<section id='sotd'>
<h2>Status</h2>
<p><strong>This document is the internal working draft used by the Mobile Accessibility Task Force and is updated continuously and without notice. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</strong>
</p>
<p>This is a draft of a document that will become a First Public Working Draft (FPWD) of the WCAG Extension on Mobile Accessibility. This document catalogs new mobile guidelines, success criteria and techniques proposed by the Mobile A11y Task Force of the WCAG Working Group. . </p>
<p>This document is intended to become a normative extension of <a href="http://www.w3.org/TR/WCAG20/">Web Content Accessibility Guideline (WCAG 2.0)</a> [[WCAG20]] and is part of a series of technical and educational documents published by the <a href="http://www.w3.org/WAI/">W3C Web Accessibility Initiative (WAI)</a>. </p>
</section>
<section class="introductory">
<h2 id="intro">Introduction</h2>
<p>The Mobile Accessibility Extension to WCAG 2.0 provides guidance to improve accessibility for people with disabilities. While it generally applies to traditional mobile devices, it also applies to touch-enabled desktop devices, kiosks, tablets and other platforms that use technology beyond the traditional mouse and keyboard. While it is primarily oriented toward web and hybrid content, the guidelines and success criteria may also apply to native mobile applications. </p>
<h3>Structure of this Document</h3>
<p>This version of the Mobile Accessibility Extension to WCAG is closely tied with WCAG. The early work of the task force focused on writing Techniques for WCAG that applied to mobile. Many existing WCAG techniques apply to mobile in current form and are listed in the Appendix of the W3C Working Group Note: <a href="https://www.w3.org/TR/mobile-accessibility-mapping/#wcag-techniques-that-apply-to-mobile">Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile</a>. The task force has written new Techniques for <strong>existing</strong> WCAG success criteria that specifically apply to mobile devices. To make it easier to understand the relationship between these new mobile Techniques and WCAG, a bare outline of the WCAG success criteria is included, with the appropriate Mobile Techniques listed below the success criterion. Techniques that are proposed but not written are marked as<strong> [Mobile]</strong>. Completed or in process mobile Techniques are numbered starting with the letter "<strong>M</strong>". </p>
<p>New guidelines and success criteria that are not in WCAG 2.0 at the time of publication are marked as <strong>[MOBILE]</strong>. WCAG Guidelines and success criteria are prefixed with <strong>WCAG</strong>. </p>
</section>
<section class="principle">
<h2 class="principle" id="perceivable">WCAG Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive.</h2>
<section class="guideline">
<div>
<h3>WCAG Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.</h3>
</div>
<h4>1.1.1 Non-text Content</h4>
<p class="proposed">Mobile Technique proposed for WCAG 1.1.1</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M019">M019</a>: Providing media metadata</li>
</ul>
</section>
<section class="guideline">
<div>
<h3>WCAG Guideline 1.2 Time-based Media: Provide alternatives for time-based media.</h3>
</div>
<h4>1.2.1 Audio-only and Video-only (Prerecorded)</h4>
<h4>1.2.2 Captions (Prerecorded)</h4>
<h4>1.2.3 Audio Description or Media Alternative (Prerecorded)</h4>
<h4>1.2.4 Captions (Live)</h4>
<h4>1.2.5 Audio Description (Prerecorded)</h4>
<h4>1.2.6 Sign Language (Prerecorded)</h4>
<h4>1.2.7 Extended Audio Description (Prerecorded)</h4>
<h4>1.2.8 Media Alternative (Prerecorded)</h4>
<h4>1.2.9 Audio-only (Live)</h4>
</section>
<section class="guideline">
<div>
<h3>WCAG Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.</h3>
</div>
<h4>1.3.1 Info and Relationships</h4>
<p class="proposed">Mobile Techniques proposed for WCAG 1.3.1</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M006">M006</a> <strong>Data Type: </strong>Specifying input type for numerical or character data</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M008">M008</a><strong> Data Mask:</strong> Set the virtual keyboard to the type of data entry required</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M023">M023</a>: Set the HTML virtual keyboard to the type of data entry required.</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M024">M024</a>: Set the iOS virtual keyboard to the type of data entry required.</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M025">M025</a>: Set the Android virtual keyboard to the type of data entry required.</li>
</ul>
<h4>1.3.2 Meaningful Sequence</h4>
<p class="proposed">Mobile Technique proposed for WCAG 1.3.2</p>
<ul>
<li>[MOBILE] Changing between device orientations provide correct reading sequence</li>
</ul>
<h4>1.3.3 Sensory Characteristics</h4>
<p class="proposed">Mobile Techniques proposed for WCAG 1.3.3</p>
<ul>
<li>[MOBILE] Provide instructions to help users know the location of elements on the touch screen</li>
</ul>
</section>
<section class="guideline">
<div>
<h3>WCAG Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background. </h3>
</div>
<h4>1.4.1 Use of Color</h4>
<h4>1.4.2 Audio Control</h4>
<h4>1.4.3 Contrast (Minimum)</h4>
<h4>1.4.4 Resize text</h4>
<p class="proposed">Mobile Techniques proposed for WCAG 1.4.4</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M013">M013</a>: Providing a way for users to change font size</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M021">M021</a>: <strong>Pinch Zoom:</strong> Setting viewport meta setting to allow magnification to 200%</li>
<li><strong>[MOBILE] Platform Text Size: </strong>Support for system fonts that follow platform level user preferences for text size to at least 200%.</li>
<li><strong>[MOBILE] On-Page Controls: </strong>Provide on-page controls to change the text size. </li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M016">M016</a>: Providing vertical navigation mechanisms that work without horizontal scrolling on narrow width screens</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M018">M018</a>: Ensuring that menu can be zoomed to 200%</li>
</ul>
<h4>1.4.5 Images of Text</h4>
<h4>1.4.6 Contrast (Enhanced)</h4>
<h4>1.4.7 Low or No Background Audio</h4>
<h4>1.4.8 Visual Presentation</h4>
<p class="proposed">Mobile Technique proposed for WCAG 1.4.8</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M009">M009</a>: Adapting the length of link texts to viewport width</li>
</ul>
<h4>1.4.9 Images of Text (No Exception) </h4>
</section>
</section>
<section class="principle">
<h2 class="principle" id="operable">WCAG Principle 2: Operable - User interface components and navigation must be operable.</h2>
<section class="guideline">
<h3>WCAG Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard. </h3>
<section class="sc">
<h4>2.1.1 Keyboard</h4>
<p class="proposed">Mobile Techniques proposed for WCAG 2.1.1</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M011">M011</a>: Ensuring that the interface can be used with a physical keyboard</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M014">M014</a>: Ensuring that navigation works on different screen sizes</li>
</ul>
</section>
<section class="sc">
<h4>2.1.2 No Keyboard Trap</h4>
</section>
<section class="sc">
<h4>2.1.3 Keyboard (No Exception)</h4>
</section>
</section>
<section class="guideline">
<h3>WCAG Guideline 2.2 Enough Time: Provide users enough time to read and use content. </h3>
<section class="sc">
<h4>2.2.1 Timing Adjustable</h4>
</section>
<section class="sc">
<h4>2.2.2 Pause, Stop, Hide</h4>
</section>
<section class="sc">
<h4>2.2.3 No Timing</h4>
</section>
<section class="sc">
<h4>2.2.4 Interruptions</h4>
</section>
<section class="sc">
<h4>2.2.5 Re-authenticating</h4>
</section>
</section>
<section class="guideline">
<h3><a id="seizure"> </a> WCAG Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.</h3>
<section class="sc">
<h4>2.3.1 Three Flashes or Below Threshold</h4>
</section>
<section class="sc">
<h4>2.3.2 Three Flashes</h4>
</section>
</section>
<section class="guideline">
<h3><a id="navigation-mechanisms"> </a> WCAG Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are. </h3>
<section class="sc">
<h4>2.4.1 Bypass Blocks</h4>
</section>
<section class="sc">
<h4>2.4.2 Page Titled</h4>
</section>
<section class="sc">
<h4>2.4.3 Focus Order</h4>
</section>
<section class="sc">
<h4>2.4.4 Link Purpose (In Context)</h4>
</section>
<section class="sc">
<h4>2.4.5 Multiple Ways</h4>
<p class="proposed">Mobile Techniques proposed for WCAG 2.4.5</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M012">M012</a>: Including shortcuts to allow users to jump to sections of the page</li>
</ul>
</section>
<section class="sc">
<h4>2.4.6 Headings and Labels</h4>
</section>
<section class="sc">
<h4>2.4.7 Focus Visible</h4>
<p class="proposed">Mobile Techniques proposed for WCAG 2.4.7</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M001">M001</a> <strong>Touch Focus</strong>: Defining the hover, focus, selected and touch (regular, long) states</li>
</ul>
</section>
<section class="sc">
<h4>2.4.8 Location</h4>
<p class="proposed">Mobile Techniques proposed for WCAG 2.4.8</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M015">M015</a>: Providing a way for users to see what page they are on</li>
</ul>
</section>
<section class="sc">
<h4>2.4.9 Link Purpose (Link Only)</h4>
</section>
<section class="sc">
<h4>2.4.10 Section Headings </h4>
</section>
</section>
<section class="guideline">
<h3 id="touch-and-pointer"> <span class="proposed">[Proposed New MOBILE Guideline] </span>Guideline 2.5: Touch and Pointer: Make it easier for users to operate touch and pointer functionality. </h3>
<section class="understanding introductory">
<h4>Intent of Guideline 2.5</h4>
<p><span class="proposed">[Proposed text for Understanding] </span>Platforms today can be operated through a number of different devices including touch, stylus, pen, in addition to mouse and keyboard. Some platforms such as a mobile device are designed to be primarily operated via gestures made on a touchscreen. Other devices can be operated by a number of different devices, such as a pen, stylus, or mouse, which may be generically referred to as <a href="#def-pointer-input">pointer inputs</a>. This section also applies to pointer events on non-mobile platforms.</p>
<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). Pointer devices such as stylus, pen or pencil have also gained popularity for providing more precise touch. The mouse has been popular on desktop computers for decades. </p>
<p> Although the definition of "pointer inputs" includes touch, we include touch and pointer for clarity. When we use the term touch, we just mean touch. </p>
</section>
<section class="sc">
<h4 id="sc-touch-with-AT" class="sc"><span class="proposed">[Proposed New MOBILE Success Criteria]</span> Touch with Assistive Technology: All functions available by touch are still available by touch after platform assistive technology that remaps touch gestures is turned on. (Level A)</h4>
<section class="understanding">
<h5><span class="proposed">[Proposed text for Understanding] </span> Intent of this Success Criterion</h5>
<p>The intent of this Success Criterion is to ensure that content can be operated using gestures on a touch screen with platform assistive technology.</p>
<p>Generally, assistive technology such as a screen reader on a touch screen device will change the gestures that are used to interact with content when it is turned on.<p>
<p>For example, on both iOS and Android platforms, when the platform's screen reader (VoiceOver and TalkBack, respectively) is enabled, users will move their focus to the previous/next element using single swipe left/right gestures; using "touch to explore" functionality, a single tap on the touch screen will set focus to the element at that particular location on the screen; a double tap will activate the element.</p>
<p>While content may provide its own gesture-based controls, all functions available by touch when the platform assistive technology is not turned on must be still available when the platform assistive technology is turned on.</p>
<p>Be famililar with your platform's system controls and standards for assistive technology. Use the system controls supported by the platform first and don't overwrite the standard gestures of the platform. Don't use a common gesture for a purpose that is not common. </p>
<h5>Specific Benefits of Success Criterion 2.5.1</h5>
<ul>
<li>People who are blind who rely on the use of a screen reader while interacting with the touch screen</li>
<li>People with low vision who may also need speech turned on while interacting with the touch screen</li>
</ul>
<h5>Examples of Success Criterion 2.5.1</h5>
<ul>
<li>If a developer assigns a double tap as a custom gesture, as the only way to complete an action, a user who is blind using VoiceOver will not have access to that action because VoiceOver reserves the double tap to activate an item.</li>
<li>If a developer assigns a swipe right as the only way to open a menu, the VoiceOver user will not be able to do that action, because VoiceOver takes over the right swipe as a way to move from element to element. To avoid this problem, the developer could ensure there is a mobile menu button that works with touch as another way to bring up the menu.</li>
</ul>
<h5>Related Resources</h5>
<ul>
<li><a href="https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/InteractivityInput.html">Apple iOS Developer Library: Interactivity and Feedback</a></li>
<li><a href="https://developer.apple.com/library/ios/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html">Apple iOS Developer Library: Test Accessibility on Your Device with VoiceOver</a></li>
<li><a href="https://support.google.com/accessibility/android/answer/6151827?hl=en">Android Training: Using Touch Gestures</a></li>
<li><a href="http://developer.android.com/training/gestures/index.html">Google Android Accessibility Help: Use TalkBack gestures</a></li>
<li><a href="http://www.windowsphone.com/en-us/how-to/wp7/start/gestures-flick-pan-and-stretch">Windows Phone: Gestures: flick, pan, and stretch</a></li>
<li><a href="https://www.microsoft.com/en/mobile/accessibility/use-narrator-on-my-phone/">Microsoft: Use Narrator on my phone</a></li>
<li><a href="http://downloadcenter.samsung.com/content/UM/201503/20150303094626458/SM-G920F_UM_EU_Lollipop_Eng_Rev.1.0_150302.pdf">Samsung User Manual (pdf)</a></li>
<li>[jeanne will check UAAG for links to other mobile platforms - Blackberry]</li>
</ul>
<p> </p>
<p>Resources are for information purposes only, no endorsement implied.</p>
<p>(none currently documented)</p>
<h5>Techniques and Failures for Success Criterion 2.5.1</h5>
<ul>
<li><strong>Techniques</strong>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M028">M028</a> Using standard one touch controls</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M027">M027</a> Providing touch access for custom controls</li>
</ul>
</li>
<li><strong>Failures</strong>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM002">FM002</a> Infinite scroll gesture is not available with system screen reader</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM003">FM003</a> Component can be opened but cannot be closed with touch when a system screen reader is running</li>
</ul>
</li>
</ul>
</section>
</section>
<section class="sc">
<h4 id="swipe-trap"><span class="proposed">[Proposed New MOBILE Success Criteria]</span> No Touch Trap: When touch input behavior is modified by platform assistive technology and focus can be moved to a component, then focus can be moved away from the I'component using sequential navigation gestures of assistive technology or the user is advised of the method for moving focus away in the sequential focus order. (Level A) </h4>
<section class="understanding">
<h5 class="intent"><span class="proposed">[Proposed text for Understanding] </span> Intent of this Success Criterion</h5>
<p>Swipe gestures are useful for displaying dynamic content. Giving focus to dynamic content via a swipe gesture also needs a gesture or method to move focus back to prior content — either by swiping to return or by informing the user of the method needed to return. These methods must work with assistive technology. Explore by touch is not a valid solution, because the user can then miss content without knowing it was missed. This success criterion is similar to WCAG 2.1.2 No Keyboard Trap, however, it expands to all sequential navigation methods and compensates for touch specific failure criteria. Relying on touch-to-explore features of mobile ATs to escape such a trap is still a failure under this criteria, because the next sequential item may be offscreen, an explore by touch gesture may cause users to get lost on the page, or the user may be relying on other means of sequential navigation such as a keyboard or switch control.</p>
<h5 class="benefit">Specific Benefits of Success Criterion 2.5.2</h5>
<ul>
<li>Content that is after or outside of infinite scrolling content, or off the visible screen, can be accessed by screenreader users.</li>
</ul>
<h5 class="examples">Examples of Success Criterion 2.5.2</h5>
<ul>
<li>Infinite scroll of content, where there is additional content in the footer, but the user with assistive technology (e.g. screenreader) cannot move focus to the footer and therefore cannot read the footer content and may not even know that the footer content exists. </li>
<li>An infinite carousel advances with a swipe gesture. The instructions indicate that a touch outside the carousel will exit the carousel. The user can touch outside the carousel with assistive technology (e.g. screenreader) turned on.</li>
<li>Popup dialog that cannot be closed when assistive technology is turned on. </li>
</ul>
<h5 class="resources">Related Resources</h5>
<p>Resources are for information purposes only, no endorsement implied.</p>
<p>(none currently documented)</p>
<h5 class="techniques">Techniques and Failures for Success Criterion 2.5.2</h5>
<ul>
<li> <a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM003">FM003</a> Component can be opened but cannot be closed with touch when a system screen reader is running</li>
</ul>
</section>
</section>
<section class="sc">
<h4 id="independent-activation"><span class="proposed">[Proposed New MOBILE Success Criteria]</span> Accidental Activation: </h4>
<h4><span>For single touch and pointer activation, at least one of the following is true</span>: (Level A)
<section class="understanding">
</section>
</h4>
<h4>
<ol>
<li>Activation is on the <u><a href="https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3#up-event">up-event</a></u>, either explicitly or implicitly as a platform's generic activation/click event; </li>
<li>A mechanism is available that allows the user to choose the up-event as an option; </li>
<li>Confirmation is provided, which can dismiss activation; </li>
<li>Activation is reversible; or</li>
<li>Timing of activation is essential and waiting for the up-event would invalidate the activity. </li>
</ol>
</h4>
<p><strong>Note:</strong> This success criteria applies when platform assistive technology (e.g. screen reader) that remaps touch gestures is not turned on.</p>
<section class="understanding">
<h5 class="intent"><span class="proposed">[Proposed text for Understanding] </span> Intent of this Success Criterion</h5>
<p>People with various disabilities can inadvertently initiate touch or mouse events with unwanted results. Up-Event activation refers to the activation of a component when the trigger stimulus is released. For example, for touchscreen interaction the event would be triggered when a finger is lifted from the touchscreen at the end of a tap.There is a distinction between when someone touches a screen and when they remove their finger. On a mouse there is a difference between mouse down (initiating a click) and mouse up (releasing the finger). Authors can reduce the problem of users inadvertently triggering an action, by making activation on the up-event. This gives users the opportunity to move their finger (or mouse/pointer), away from the wrong target once they hit it. If touch down activation is necessary, there are several options:</p>
<ul>
<li> A confirmation alert allows the user to change their mind </li>
<li> An undo button or other mechanism allows the user to reverse the action. </li>
<li> A setting in preferences allows the user to choose whether activation happens on the down or up event. </li>
</ul>
<p>Generic platform activation/click events generally trigger on up and when they do, they are also allowed. For example, in the case of mouse interactions, the "click" event in JavaScript triggers on release of the primary mouse button, and is an example of an implicit up-event. An exception would be an activity that would be invalid if activation waited for the up-event. Examples of this could include a piano program or a program for shooting skeets where waiting for the "up" event would invalidate the activation. Long press activation and 3D touch can be used as long as one of the above listed alternatives is present, and there is another conforming way to provide the action performed by the control.</p>
<p>Anywhere where we say "touch and pointer" we recognized that touch is included in the definition of pointer, but we include touch for clarity and ease of reading. </p>
<p>On different platforms the "up-event" may be called different things, such as "touchend", "onclick" or "mouseup" etc..</p>
<h5 class="benefit">Specific Benefits of Success Criterion 2.5.3</h5>
<ul>
<li>Makes it easier for all users to recover from hitting the wrong target.</li>
<li>Helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a control will be accidentally activated or action will occur unexpectedly.</li>
<li>Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site</li>
</ul>
<h5 class="examples">Examples of Success Criterion 2.5.3</h5>
<ul>
<li>Interface elements that require a single tap or a long press as input will only trigger the corresponding event when the finger is lifted inside that element. </li>
<li>The user interface control performs an action when the user lifts the finger away from the control rather than when the user first touches the control.</li>
<li>A phone dialing application has number keys that are activated on touch down. A user can undo an unwanted number by hitting the backspace button to delete a mistaken digit. </li>
</ul>
<h5 class="resources">Related Resources</h5>
<p>Resources are for information purposes only, no endorsement implied.</p>
<p>(none currently documented)</p>
<h5 class="techniques">Techniques and Failures for Success Criterion 2.5.3</h5>
<ul>
<li><a rel="nofollow" href="https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029">M029</a> <span class="note">@@wiki link@@</span> Touch events are only triggered when touch is removed from a control</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001">FM001</a> Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location</li>
<li>Failure @@to be written@@: Actions are only available through long press or 3D touch</li>
</ul>
</section>
</section>
<section class="sc">
<h4 id="touch_target_size"><span class="proposed">[Proposed New MOBILE Success Criteria]</span> Target Size: The size of the <a href="#def-target">target</a> in relation to the visible display at the default viewport size is at least: (Level AA)
<ul>
<li>44px by 44px for pointer inputs with coarse pointing accuracy (such as a touchscreen)</li>
<li>20px by 20px for pointer inputs with fine pointing accuracy (such as a mouse, trackpad or stylus)</li>
</ul>
where px is a CSS <a href="#def-pixel">pixel</a>. </h4>
<p>Note: In situations where multiple input mechanisms with both coarse and fine pointing accuracy are present, and where no mechanisms are present to determine the user's current input (either manual - e.g. providing the user with an explicit toggle to switch to a "touch-optimized" interface - or automatic - e.g. an application switching dynamically based on the type of input the user is currently using), targets must follow the larger minimum dimensions for coarse pointer inputs.</p>
<p>Note: This success criterion applies when platform assistive technology (e.g. magnification) is not turned on.</p>
<p>Editor's Note: We are researching the 20px value for mouse/pointer and 44px for touch. We are seeking research on this and outside input. We also have to define the difference between a touch event and a mouse event, particularly in html and responsive environments.</p>
<p>Editor's Note: this criterion borrows the distinction of "coarse" and "fine" pointing devices from <a href="https://www.w3.org/TR/mediaqueries-4/#descdef-media-pointer">Media Queries Level 4 - Pointing Device Quality: the pointer feature</a></p>
<section class="understanding">
</section>
</h4>
<section class="understanding">
<h5 class="intent"><span class="proposed">[Proposed text for Understanding] </span>
Intent of this Success Criterion</h5>
<p>The intent of this success criterion is to help users who may have trouble activating a small target because of hand tremors, limited dexterity or other reasons. If the target is too small, it may be difficult to aim at the target. Mice and similar pointing devices can be hard to use for these users, and a larger target will help them greatly in having positive outcomes on the web page.</p>
<p>Touch is particularly problematic as it is an input mechanism with coarse precision. Users lack the same level of fine control as on inputs such as a mouse or stylus. A finger is larger than a mouse pointer, and generally obstructs the user's view of the precise location on the screen that is being touched/activated.</p>p>
<p>The issue can be further complicated on for responsive/mobile which need to accommodate different types of fine and coarse inputs (e.g. a site that can be accessed both on a traditional desktop/laptop with a mouse, as well as on a tablet or mobile phone with a touch screen).</p>
<p>While this criterion defines a minimum target size, even large sizes are recommended to reduce the possibility of unintentional actions. This is particularly relevant if any of the following are true:</p>
<ul>
<li>the control is used frequently;</li>
<li>the result of the interaction cannot be easily undone;</li>
<li>the control is positioned where it will be difficult to reach, or is near the edge of the screen;</li>
<li>the control is part of a sequential task.</li>
</ul>
<h5 class="benefit">Specific Benefits of Success Criterion 2.5.4</h5>
<ul>
<li>Users with mobility impairments, such as hand tremors</li>
<li>Users who find fine motor movements difficult</li>
<li>Users who access a device using one hand</li>
<li>Users with large fingers, or who are operating the device with only a part of their finger or knuckle</li>
<li>Users who have low vision may better see the target</li>
</ul>
<h5 class="examples">Examples of Success Criterion 2.5.4</h5>
<ul>
<li>Three buttons are on-screen and the visible portion of each button is 44px by 44px</li>
</ul>
<h5 class="resources">Related Resources</h5>
<ul>
<li>Apple touch target size recommendations</li>
<li>Android touch target size recommendations</li>
<li><a href="http://touchlab.mit.edu/publications/2003_009.pdf">Human Fingertips to Investigate the Mechanics of Tactile Sense</a> (PDF)</li>
<li><a href="http://hcil.cs.umd.edu/trs/2006-11/2006-11.htm">One-Handed Thumb Use on Small Touchscreen Devices</a> </li>
<li><a href="http://blogs.msdn.com/b/ie/archive/2012/04/20/guidelines-for-building-touch-friendly-sites.aspx">Microsoft Guidelines for Building Touch Friendly Sites</a>
</ul>
<h5 class="techniques">Techniques and Failures for Success Criterion 2.5.4</h5>
<ul>
<li><strong><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M030">M030</a> Multiple Elements: </strong>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.</li>
<li><a href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M002">M002</a> <strong>Touch Target</strong>: Ensuring that touch targets are at least 44px by 44px. </li>
<li><a href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM005">FM005</a> Failure: touch target is less than 44px x 44px at the default viewport size</li>
</ul>
</section>
</section>
</section>
<section class="guideline">
<h3 id="touch-and-pointer"> <span class="proposed">[Proposed New MOBILE Guideline]</span> Guideline 2.6: Make it easier to use the physical features of the phone. </h3>
<section class="understanding introductory">
<h4>Intent of Guideline 2.6</h4>
<p><span class="proposed">[Proposed text for Understanding] </span> </p>
</section>
<section class="sc">
<h4><span class="proposed">[Proposed New MOBILE Success Criteria]</span> </span>Device manipulation: When <a href="#def-device-manipulation">device manipulation</a> gestures are provided, touch and keyboard operable alternative control options are available. (Level AA) </h4>
<section class="understanding">
<h5 class="intent"><span class="proposed">[Proposed text for Understanding] </span> Intent of this Success Criterion</h5>
<p>While device operating system is responsible for providing alternatives for using the device buttons and gestures (e.g. shaking, holding, proximity, touch, voice, walking, looking at, angle of holding, etc.), when the content makes use of these gestures in a customized manner not recognized by the operating system, then touch or keyboard alternatives are provided. For example, a shaking motion to undo or cancel may be unavailable to a person whose mobile device is secured to a wheelchair. </p>
<h5 class="benefit">Specific Benefits of Success Criterion 2.6.1</h5>
<ul>
<li> </li>
</ul>
<h5 class="examples">Examples of Success Criterion 2.6.1</h5>
<ul>
<li>Example 1</li>
</ul>
<h5 class="resources">Related Resources</h5>
<p>Resources are for information purposes only, no endorsement implied.</p>
<p>(none currently documented)</p>
<h5 class="techniques">Techniques and Failures for Success Criterion 2.6.1</h5>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M010">M010</a>: Allowing users to interact using device buttons (e.g. arrow keys, ok button)
</li>
</ul>
</section>
</section>
<section class="sc">
<h4><span class="proposed">[Proposed New MOBILE Success Criteria]</span> Visual gestures to the camera</h4>
</section>
<section class="sc">
<h4><span class="proposed">[Proposed New MOBILE Success Criteria]</span> Voice control using microphone</h4>
</section>
</section>
<section class="guideline">
<h3><span class="proposed">[Proposed New MOBILE Guideline]</span> Guideline 2.7: Make it practical for speech input users to operate all functionality</h3>
<section class="understanding">
<h4><span class="proposed">[Proposed text for Understanding] </span></h4>
</section>
<section class="sc">
<h4><span class="proposed">[Proposed New MOBILE Success Criteria]</span> Speech Input: All functionality of the content (including touch and gesture) is operable through the keyboard, and does not obstruct a user's ability to access the keyboard commands through speech input. (Level A)</h4>
<section class="understanding">
<p><span class="proposed">[Proposed text for Understanding] </span></p>
<h5 class="intent">Intent of this Success Criterion</h5>
<p>One means of speech input is speaking keyboard controls. Users can also write custom speech commands that can call keyboard controls. This means that, in general, anything that is accessible by keyboard is accessible by speech.</p>
<h5 class="benefit">Specific Benefits of Success Criterion 2.7.1</h5>
<ul>
<li> </li>
</ul>
<h5 class="examples">Examples of Success Criterion 2.7.1</h5>
<ul>
<li>Example 1</li>
</ul>
<h5 class="resources">Related Resources</h5>
<p>Resources are for information purposes only, no endorsement implied.</p>
<p>(none currently documented)</p>
<h5 class="techniques">Techniques and Failures for Success Criterion 2.7.1</h5>
<ul>
<li> </li>
</ul>
</section>
</section>
<section class="sc">
<h4><span class="proposed">[Proposed New MOBILE Success Criteria]</span> Single key shortcut alternative: The user can adjust any single key shortcut to an alternative control of a string of symbols and letters.</h4>
<section class="understanding">
<p><span class="proposed">[Proposed text for Understanding] </span></p>
<h5 class="intent">Intent of this Success Criterion</h5>
<p>While using single letter keys as controls might be appropriate and efficient for keyboard users, single key shortcuts are disastrous for speech users, who can inadvertently set off multiple controls by speaking a single phrase. To avoid excluding speech users, single key shortcuts must be accompanied by a mechanism that allows the user to customize single key shortcuts. For example, the user could change the single key shortcut "r" for reply to "+r" or to "This Reply". </p>
<h5 class="benefit">Specific Benefits of Success Criterion 2.7.2</h5>
<ul>
<li> </li>
</ul>
<h5 class="examples">Examples of Success Criterion 2.7.2</h5>
<ul>
<li>Example 1</li>
</ul>
<h5 class="resources">Related Resources</h5>
<p>Resources are for information purposes only, no endorsement implied.</p>
<p>(none currently documented)</p>
<h5 class="techniques">Techniques and Failures for Success Criterion 2.7.2</h5>
<ul>
<li> </li>
</ul>
</section>
</section>
</section>
</section>
<section class="principle">
<h2 class="principle" id="understandable">Principle 3: Understandable - Information and the operation of user interface must be understandable.</h2>
<section class="guideline">
<h3>WCAG Guideline 3.1 Readable: Make text content readable and understandable. </h3>
<h4>3.1.1 Language of Page</h4>
<h4>3.1.2 Language of Parts</h4>
<h4>3.1.3 Unusual Words</h4>
<h4>3.1.4 Abbreviations</h4>
<h4>3.1.5 Reading Level</h4>
<h4>3.1.6 Pronunciation</h4>
</section>
<section class="guideline">
<h3>WCAG Guideline 3.2 Predictable: Make Web pages appear and operate in predictable ways. </h3>
<h4>3.2.1 On Focus</h4>
<h4>3.2.2 On Input</h4>
<h4>3.2.3 Consistent Navigation</h4>
<ul>
<li><strong>[MOBILE] Navigation Bar: </strong>If the navigation bar is collapsed into a single icon, the entries in the drop-down list that appear when activating the icon are still in the same relative order as the full navigation menu.</li>
<li><strong>[MOBILE] Orientation Order: </strong>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>
</section>
<section class="guideline">
<h3>WCAG Guideline 3.3 Input Assistance: Help users avoid and correct mistakes. </h3>
<h4>3.3.1 Error Identification</h4>
<h4>3.3.2 Labels or Instructions</h4>
<p class="proposed">Mobile Technique proposed for WCAG 3.3.2</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M005">M005</a>: Providing instructions for custom functions and gestures (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.)</li>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M020">M020</a>: Providing instructions for form data types</li>
</ul>
<h4>3.3.3 Error Suggestion</h4>
<h4>3.3.4 Error Prevention (Legal, Financial, Data)</h4>
<h4>3.3.5 Help</h4>
<h4>3.3.6 Error Prevention (All)</h4>
</section>
<section class="guideline">
<h3> <span class="proposed">[Proposed New MOBILE Guideline] </span> Guideline 3.4 Make content usable in device orientations.[MOBILE] </h3>
<h4>3.4.1 Orientation: Orientation of the content is not locked to landscape or portrait, except where orientation is <a href="https://www.w3.org/TR/WCAG20/#essentialdef">essential</a>. </h4>
<h5><span id="Understanding_Orientation">[Proposed text for Understanding] Intent of this Success Criterion</span></h5>
<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.</p>
<h5><span id="Benefits_of_Orientation">Specific Benefits of Success Criterion 3.4.1</span></h5>
<ul>
<li>Users with dexterity impairments, who have a mounted mobile device will be able to use the content in their fixed orientation</li>
</ul>
<h5><span id="Problems_Orientation">Examples of problems</span></h5>
<ul>
<li>banking website locked in portrait mode</li>
<li>iOS home screen on the iPHone vs. iPad</li>
</ul>
<h5><span id="Examples_of_essential_orientation">Examples of essential</span></h5>
<ul>
<li>banking site where a check deposit has to be in a certain orientation</li>
<li>piano app in landscape mode</li>
</ul>
<p><br>
</p>
<h5><span id="Related_Resources_Orientation">Related Resources</span></h5>
<p>Resources are for information purposes only, no endorsement implied.</p>
<p>(none currently documented)</p>
<h5><span id="Techniques_and_Failures_for_Orientation">Techniques and Failures for Success Criterion 3.4.1</span></h5>
<ul>
<li>Failure: locking the orientation</li>
<li>Technique: Using CSS to set the orientation to allow both landscape and portrait.</li>
</ul>
<p> </p>
</section>
</section>
<section class="principle">
<h2 class="principle" id="robust">Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.</h2>
<div>
<h3>Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.</h3>
</div>
<h4>4.1.1 Parsing </h4>
<h4>4.1.2 Name, Role, Value</h4>
<p class="proposed">Mobile Technique proposed for WCAG 4.1.2</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M017">M017</a>: Providing the open/closed state information in the menu icon</li>
</ul>
<h4><span class="proposed">[Proposed New MOBILE Success Criteria]</span> 4.1.3 Non-interference of AT: Content does not interfere with default functionality of platform level assistive technology </h4>
<p class="proposed">Mobile Technique proposed for WCAG 4.1.3</p>
<ul>
<li><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M007">M007</a>: Supporting the characteristic properties of the platform (e.g. zoom, larger font, captions)</li>
</ul>
</section>
<section>
<h3 class="proposed">Techniques with No Home</h3>
<p><a rel="nofollow" href="http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M003">M003</a><strong> Touch Activation:</strong> Activating elements via the touchend event</p>
<p> </p>
</section>
<section id="glossary" class="appendix">
<h2>Glossary</h2>
<dl>
<dt id="def-device-manipulation"><dfn>device manipulation</dfn></dt>
<dd>Moving or controlling the device with hands, body or machine. Device manipulation includes other methods of controling input to the mobile device outside of using the touch screen. This includes: pressing a physical button on the device, shaking, holding, proximity, touch, walking, angle of holding, input via the accelerometer etc.
Gestures to the camera and voice input to the microphone are addressed
separately. </dd>
<dt id="def-pixel"><dfn>pixel</dfn></dt>
<dd>A CSS pixel based on the ideal viewport device-width. [editor note: we need a better definition of CSS pixel].
<dt id-"def-platform-assistive-technology"><dfn>platform assistive technology</dfn> </dt>
<dd>Platform assistive technology is built into the operating system and is generally updated through OS updates. Examples include VoiceOver on iOS and TalkBack on Android. </dd>
<dt><dfn>pointer input</dfn></dt>
<dd>generic term for an input device (such as a mouse, stylus, or touchscreen) that can target a specific coordinate (or set of coordinates) on a screen. See also [Pointer Events] https://www.w3.org/TR/pointerevents/#dfn-pointer</dd>
<dt id="def-target"><dfn> target</dfn></dt>
<dd>Region of the display that will accept a touch action. If a portion of a touch target is overlapped by another touch target such that it cannot receive touch actions, then that portion is not considered a touch target for purposes of touch target measurements.</dd>
<dt><dfn>touchend</dfn></dt>
<dd>see "<a href="#def-up-event">up event</a>"</dd>
<dt id="def-up-event"><dfn>up event, touchend event</dfn>
</dt>
<dd>The activation of a component when the trigger stimulus is released. Example: For touchscreen interaction, the event is triggered when a finger is lifted from the touchscreen at the end of a tap.</dd>
</dl>
</section>
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
Thanks to current members of the Task Force</p>
<p>Allan, Jim<br>
Avila, Jonathan<br>
Babinszki, Tom<br>
Brough, Matthew<br>
Cooper, Michael<br>
Fischer, Detlev<br>
Foliot, John<br>
Garrison, Alistair<br>
Johlic, Marc<br>
Kirkpatrick, Andrew<br>
Lauke, Patrick<br>
MacDonald, David<br>
McMeeking, Chris<br>
Patch, Kimberly<br>
Pluke, Mike<br>
Richards, Jan<br>
Smith, Alan<br>
Spellman, Jeanne <br>
Vaishnav, Jatin<br>
Velleman, Eric<br>
Wahlbin, Kathleen</p>
<p>Thanks to prior members of the Task Force</p>
<p>Anderson, Kathleen<br>
Evans, Gavin<br>
Kaja, Kiran<br>
LaHart, Andrew<br>
McGrane, Karen<br>
Shebanek, Mike<br>
Shiver, Brent<br>
Thiessen, Peter<br>
Wu, Wei<br>
Zehe, Marco</p>
</section>
</body>
</html>