-
Notifications
You must be signed in to change notification settings - Fork 23
/
index.html
754 lines (712 loc) · 55.5 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
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Using ARIA</title>
<script src='https://www.w3.org/Tools/respec/respec-w3c' class='remove'></script>
<script type="text/javascript" class='remove'>
var respecConfig = {
specStatus: "ED",
noRecTrack: "true",
editors: [
{
name: "Steve Faulkner",
company: "The Paciello Group",
mailto: "sfaulkner@paciellogroup.com",
w3cid: "35007",
},
{
name: "David MacDonald",
company: "CanAdapt Solutions Inc.",
mailto: "david100@sympatico.ca",
w3cid: "35466",
},
],
group: "webapps",
github: "w3c/using-aria",
};
</script>
<style>
table {
border-collapse: collapse;
border: 1px solid #630;
font: normal 95% arial, Verdana, helvetica, sans-serif;
}
caption {
font-weight: bold;
}
th,
td {
text-align: left;
vertical-align: top;
padding: 0.3em;
border: 1px solid #630;
}
td h1 {
font-size: 85%;
margin: 0 0 0 0;
}
td p {
margin: 5px 2px 5px 2px;
}
thead th {
font-weight: bold;
text-align: center;
}
/*td span {border: 2px solid #9acd32;display:inline-block;padding:2px;}
span:focus {background:#f5f5f5;border: 2px solid #a0522d;}
td:focus {background:#f5f5f5;border: 2px solid #a0522d;}*/
caption {
text-align: left;
}
.support {
color: #090;
font-size: 1.2em;
}
.partial {
color: #939393;
font-size: 1.2em;
}
.nosupport {
color: #f00;
font-size: 1.2em;
}
div.example {
border: 1px dashed #b8860b;
padding: 5px;
margin-top: 5px;
background: #ffffff;
}
sup {
font-size: 80%;
}
td ul {
padding-left: 4px;
list-style-type: none;
}
img {
border: none;
}
code.block {
color: #bf3400;
padding: 10px;
display: block;
background: #ebebeb;
min-width: 20em;
max-width: 48em;
}
code.blockat {
color: #bf3400;
padding: 10px;
display: block;
background: #ffffd0;
min-width: 20em;
max-width: 48em;
}
mark {
background-color: #ff9;
}
div,
section,
hr {
margin-top: 10px;
}
code {
color: #bf3400 !important;
}
.example {
margin-left: 30px;
}
div.note {
padding-top: inherit !important;
padding-bottom: inherit !important;
}
div.note-title + p {
margin-top: 0px !important;
}
div.note-title {
font-weight: bold !important;
}
kbd {
background-color: #f1f1f1;
border: 1px solid #666;
border-radius: 5px;
color: #333;
padding: 0px 2px;
margin: 1px;
font-weight: bold;
font-family: Arial, Helvetica, sans-serif;
min-width: 17px;
display: inline-block;
}
</style>
</head>
<body>
<section id="abstract">
<p role="contentinfo">This document is a practical guide for developers on how to add
accessibility information to HTML elements using the
[[[WAI-ARIA-1.2]]] specification , which
defines a way to make Web content and Web applications more accessible to
people with disabilities. This document demonstrates how to use WAI-ARIA in [[HTML]], which especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.</p>
</section>
<section id="sotd">
<p class="note">This document is informative only. Resources are for information purposes only, no endorsement implied.</p>
<p>It is published by the <a href="https://www.w3.org/WebPlatform/WG/">Web Platform Working Group</a>.</p>
<p> It is a draft document and its contents is subject to change without notice.</p>
</section>
<section tabindex="-1" id="intro">
<h2>Introduction</h2>
<p>This document is a practical guide for developers on how to add
accessibility information to HTML elements using the
[[[WAI-ARIA-1.2]]] specification, which
defines a way to make Web content and Web applications more accessible to
people with disabilities. This document demonstrates how to use WAI-ARIA in HTML5, it especially helps with dynamic content and
advanced user interface controls developed with Ajax, HTML, JavaScript, and
related technologies.</p>
<p>This document provides advice for use of ARIA attributes in [[HTML]]. </p>
<p>For general best-practice information about using ARIA, see the
[[WAI-ARIA-PRACTICES-1.2]] document.</p>
<p>The following is a longer list of resources that provide relevant information:</p>
<ul>
<li>[[[HTML-ARIA]]]</li>
<li>[[[WAI-ARIA-PRACTICES-1.2]]]</li>
<li>[[[WAI-ARIA-1.2]]]</li>
<li>[[[HTML]]]</li>
<li><a href="http://www.html5accessibility.com">HTML5 Accessibility</a></li>
</ul>
</section>
<section role="main" id="NOTES">
<h2 tabindex="-1" id="notes2">Notes on ARIA Use in HTML</h2>
<section id="firstrule">
<h3 tabindex="-1" id="rule1">First Rule of ARIA Use</h3>
<p>If you <em>can</em> use a native HTML element [[HTML]] or attribute with the semantics and behavior you require <strong>already built in</strong>, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible<strong>, then do so</strong>.</p>
<p><strong>Under what circumstances may this not be possible?</strong></p>
<ul>
<li>If the feature is available in HTML [[HTML]] but it is not implemented or it is implemented, but <a href="http://www.html5accessibility.com">accessibility support</a> is not.</li>
<li>If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.</li>
<li>If the feature is <a href="https://www.paciellogroup.com/blog/2014/10/aria-in-html-there-goes-the-neighborhood/#html5na">not currently available in HTML</a>.</li>
</ul></section>
<section id="secondrule"> <h3 id="second" tabindex="-1">Second Rule of ARIA Use</h3>
<p>Do not change native semantics, unless you really have to.</p>
<p>For example: Developer wants to build a heading that's a tab.</p>
<p>Do <strong>not</strong> do this:</p>
<pre class="nohighlight"><code class="block"><<mark>h2</mark> <mark>role=tab</mark>>heading tab</<mark>h2</mark>></code> </pre>
<p><strong>Do</strong> this:</p>
<pre class="nohighlight"><code class="block"><div <mark>role=tab</mark>><mark></mark><<mark>h2</mark>>heading tab</<mark>h2</mark>><mark></mark></div></code></pre>
<p class="note">If a non-interactive element is used as the basis for an interactive element, developers have to add the semantics using ARIA and the appropriate interaction behavior using scripting. In the case of a button, for example, it is <strong>much better</strong> and easier to <a href="https://developer.paciellogroup.com/blog/2011/04/html5-accessibility-chops-just-use-a-button/">Just use a (native HTML) button</a>.</p>
<p class="note">It is OK to use native HTML elements, that have similar semantics to ARIA roles used, for fallback. For example, using HTML <a href="https://www.w3.org/TR/html51/grouping-content.html#elementdef-ul">list elements</a> for the skeleton of an ARIA-enabled, scripted <a href="http://hanshillen.github.io/jqtest/#goto_tree">tree widget</a>.</p></section>
<section id="3rdrule"> <h3 tabindex="-1" id="third">Third Rule of ARIA Use</h3>
<p>All interactive ARIA controls must be usable with the keyboard. </p>
<p>If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard.</p>
<p>All interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable.</p>
<p>For example, if using <code>role=button</code> the element must be able to receive focus and a user must be able to activate the action associated with the element using <strong>both</strong> the <kbd>enter</kbd> (on WIN OS) or <kbd>return</kbd> (MAC OS) and the <kbd>space</kbd> key.</p>
<p>Refer to the <a href="https://www.w3.org/TR/wai-aria-practices/#aria_ex">Design Patterns and Widgets</a> and <a href="https://www.w3.org/TR/wai-aria-practices/#keyboard">Developing a Keyboard Interface</a> sections of [[WAI-ARIA-PRACTICES-1.2]]</p>
</section>
<section id="4thrule">
<h3 tabindex="-1" id="fourth">Fourth Rule of ARIA Use</h3>
<p>Do not use <code>role="presentation"</code> or <code>aria-hidden="true"</code> on a <strong>focusable</strong> element .</p>
<p>Using either of these on a <strong>focusable</strong> element will result in some users focusing on 'nothing'.</p>
<p>Do <strong>not</strong> do this:</p>
<pre class="nohighlight"><code class="block"><<mark>button</mark> <mark>role=presentation</mark>>press me</<mark>button</mark>></code> </pre>
<p>Do <strong>not</strong> do this:</p>
<pre class="nohighlight"><code class="block"><<mark>button</mark> <mark>aria-hidden="true"</mark>>press me</<mark>button</mark>></code> </pre>
<p class="note">Applying <code>aria-hidden</code> to a parent/ancestor of a visible interactive element will also result in the interactive element being hidden, so <strong>don't do this either</strong>:</p>
<pre class="nohighlight"><code class="block">
<<mark>div</mark> <mark>aria-hidden="true"</mark>>
<button>press me</button>
<mark></div></mark></code></pre>
<p class="note">If an interactive element <strong>cannot be seen or interacted with</strong>, then you can apply <code>aria-hidden</code>, as long as it's not focusable. For example:</p>
<pre class="nohighlight">
<code class="block"><mark>button {opacity:0}</mark>
<<mark>button</mark> <mark>tabindex="-1" aria-hidden="true"</mark>>press me</<mark>button</mark>></code></pre>
<p class="note">If an interactive element is hidden using <code>display:none</code> or <code>visibility:hidden</code> (either on the element itself, or any of the element's ancestors),
it won't be focusable, and it will also be removed from the <a href="https://www.w3.org/TR/accname-aam-1.1/#dfn-accessibility-tree">accessibility tree</a>. This makes the
addition of <code>aria-hidden="true"</code> or explicitly setting <code>tabindex="-1"</code> unnecessary.</p>
</section>
<section id="fifthrule"><h3 tabindex="-1" id="fifth">Fifth Rule of ARIA Use</h3>
<p>All interactive elements must have an <a href="http://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-name">accessible name</a>. </p>
<p>An interactive element only has an accessible name when its Accessibility API <em>accessible name</em> (or equivalent) property has a value.</p>
<p>For example, the <code>input type=text</code> in the code example below has a visible label 'user name' , but no accessible name:</p>
<pre class="nohighlight"><code class="block">
user name <input type="text">
or
<mark><span></mark>user name<mark></span></mark> <input type="text">
</code></pre>
<p>The control's <a href="https://en.wikipedia.org/wiki/Microsoft_Active_Accessibility">MSAA</a> <code>accName</code> property is empty:</p>
<p><img src="noname.png" width="277" height="143" alt="example control with MSAA name and role information displayed. The accName property has no value, the accRole property is 'editable text'."></p>
<p>In comparison, the <code>input type=text</code> in the code example below has a visible label 'user name' and an accessible name. This example has an accessible name because the <code>input</code> element is a <a href="https://www.w3.org/TR/html51/sec-forms.html#labelable-element">labelable element</a> and the <a href="https://www.w3.org/TR/html51/sec-forms.html#the-label-element"><code>label</code></a> element is used correctly to associate the label text with the input.</p>
<pre class="nohighlight"><code class="block">
<!-- <strong>Note:</strong> use of for/id or wrapping label around text
and control methods will result in an accessible name -->
<mark><input type="text" aria-label="User Name"></mark>
or
<mark><span id="p1">user name</span> <input type="text" aria-labelledby="p1">
</code></pre>
<p>The control's <a href="https://en.wikipedia.org/wiki/Microsoft_Active_Accessibility">MSAA</a> <code>accName</code> property has a value of "user name":</p>
<p><img src="name.png" width="277" height="143" alt="example control with MSAA name and role information displayed. The accName property has a value of 'user name', the accRole property is 'editable text'."></p>
<div class="note"><p>Note: The example above is for ARIA widgets. For regular HTML inputs, follow the First Rule of ARIA, and use the <a href="https://www.w3.org/TR/html52/sec-forms.html#the-label-element"><code>label</code></a> element with a <code>for</code> attribute to associate labels with <code>input</code> elements.</p></div>
<h4>HTML <code>label</code> element and labelable elements</h4>
<p>The following is about using the <code>label</code> in HTML. If you are building ARIA widgets, refer to the <a href="https://www.w3.org/TR/WAI-ARIA-PRACTICES-1.2/">ARIA Authoring Practices Document</a>
<p>The <a href="https://www.w3.org/TR/html51/sec-forms.html#the-label-element"><code>label</code></a> element cannot be used to provide an accessible name for custom controls, unless the <code>label</code> is referencing a native HTML <a href="https://www.w3.org/TR/html51/sec-forms.html#labelable-element">labelable element</a>.</p>
<pre class="nohighlight"><code class="block">
<!-- <strong>HTML input element with combox role</strong> -->
<mark><label></mark>
user name <input type="text" <mark>role="combobox"</mark>>
<mark></label></mark>
</code></pre>
<p>The control's <a href="http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility">MSAA</a> <code>accName</code> property has a value of "user name":</p>
<p><img src="combo1.png" width="280" height="142" alt="example input element with MSAA name and role information displayed. The accName property has a value of 'user name', the accRole property is 'combo box'."></p>
<p>A <code><a href="https://www.w3.org/TR/html51/grouping-content.html#the-div-element">div</a></code> element regardless of what role is assigned is not an HTML <a href="https://www.w3.org/TR/html51/sec-forms.html#labelable-element">labelable element</a>.</p>
<pre class="nohighlight"><code class="block">
<!-- <strong>HTML div element with combox role</strong> -->
<mark><label></mark>
user name <div <mark>role="combobox"</mark>></div>
<mark></label></mark>
</code></pre>
<p>The control's <a href="http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility">MSAA</a> <code>accName</code> property is empty:</p>
<p><img src="combo2.png" width="241" height="147" alt="example div element with MSAA name and role information displayed. The accName property is empty, the accRole property is 'combo box'."></p>
<p class="note">5th rule is a work in progress</p>
<p> </p>
</section>
<section id="nativesemantics"><h3 tabindex="-1" id="do">What Does Adding a Role Do to the Native Semantics?</h3>
<p> Adding an ARIA role <strong>overrides</strong> the native role semantics in the <a href="https://www.w3.org/TR/accname-aam-1.1/#dfn-accessibility-tree">accessibility tree</a> which is reported via the <a href="https://www.w3.org/TR/accname-aam-1.1/#dfn_accessibility_api">accessibility API</a>, and therefore ARIA indirectly affects what is reported to a screen reader or other assistive technology.</p>
<p>For example, this code in the HTML tree:</p>
<pre class="nohighlight"><code class="block"><h1 role=button>text</h1></code></pre>
<p>Becomes this in the accessibility tree:</p>
<code class="block"><img src="heading-button.png" width="199" height="24" alt="button with a label of 'heading text'"></code>
<h4 id="role-not">What Adding a Role Does Not Do</h4>
<p> Adding an ARIA role will not make an element look or act differently for people <strong>not</strong> using assistive technology. It <strong>does not</strong> change the behaviors, states and properties of the host element but only the native role semantics.</p>
<p>For example, this code in the HTML tree:</p>
<pre class="nohighlight"><code class="block"><button <mark>role=heading</mark> <mark>aria-level=1</mark>>text</button></code></pre>
<p>Becomes this in the accessibility tree:</p>
<code class="block"><img src="heading.png" width="167" height="38" alt="a heading"></code>
<p><strong>But</strong> it can still be pressed, it is still in the default tab order, still looks like a button and still triggers any associated actions when pressed. That's why it is an <a href="http://validator.w3.org/nu/?doc=https%3A%2F%2Fspecs.webplatform.org%2Fhtml-aria%2Fwebspecs%2Fmaster%2Fexamples%2Fnonconforming1.html">HTML5 conformance error</a> to change a button into a heading.</p>
<p><strong>Note: </strong>Changing the <code>role</code> of an element <strong>does not</strong> add behaviors, properties or states to the <code>role</code> used. ARIA does not change the way it looks or acts in a browser. For instance, when links are used to behave like buttons, adding <code>role=button</code> alone is not sufficient. It will also be necessary to make act like a button, by including <a href="https://www.paciellogroup.com/blog/2011/04/html5-accessibility-chops-just-use-a-button/"> a key event handler</a> that listens for the <kbd>space</kbd> key which native buttons do, because native buttons can be activated using the <kbd>enter</kbd> key or the <kbd>spacebar</kbd>.</p></section>
<section id="ariainline"> <h3 tabindex="-1" id="inline">Add ARIA Inline or via Script?</h3>
<p>If the ARIA role or aria-* attribute <strong>does not rely</strong> on scripting to provide interaction behavior, then <strong>it is safe</strong> to include the ARIA markup inline. For example, it is fine to add <a href="https://www.paciellogroup.com/blog/2013/02/using-wai-aria-landmarks-2013/">ARIA landmark roles</a> or ARIA labeling and describing attributes inline. </p>
<p>If the content and interaction is <strong>only supported in a scripting-enabled browsing context</strong>, i.e. <a href="http://docs.google.com/">Google docs</a> (its applications require JavaScript enabled to work), it <strong>is also safe</strong> to include the ARIA markup inline as the application simply will not work (for anyone) without JavaScript enabled.</p>
<p><strong>Otherwise </strong>insert, change and remove ARIA via scripting. For instance, a collapsed section of a tree widget might look like this:</p>
<pre class="nohighlight"><code class="block"><li role=treeitem <mark>aria-expanded=false</mark> ...</code></pre>
<p>When the user opens the section, it is changed to this using JavaScript :</p>
<pre class="nohighlight"><code class="block"><li role=treeitem <mark>aria-expanded=true</mark> ...</code></pre>
</section>
<section id="ariavalidate"><h3 tabindex="-1" id="validation">ARIA Validation</h3>
<p>The easiest method is to use the <a href="http://www.w3.org/TR/html51/syntax.html#the-doctype">HTML5 DOCTYPE</a> with ARIA markup and validate using the <a href="http://validator.w3.org/nu/">W3C Nu Markup Checker</a>. ARIA works equally well with any other <code>DOCTYPE</code>, but validation tools will produce errors when they encounter ARIA markup as the associated DTDs have not been updated to recognize ARIA markup and it is unlikely they ever will be. </p>
<p>These validation errors in versions of HTML prior to HTML5 are in no way indicative of ARIA creating any real world accessibility problems nor do they mean there will be a negative user experience. They are merely the result of old automated validation tests that do not accommodate ARIA accessibility annotations.</p>
<p><strong>Note:</strong> The <a href="http://validator.w3.org/nu/">W3C Nu Markup Checker</a> support for ARIA checking is a work in progress, so cannot be wholly relied upon (though it is pretty <em>darn</em> good!) to provide the correct results. It is recommended that if you encounter a result that conflicts with the ARIA conformance requirements in the ARIA specification or the HTML specification, please <a href="https://github.com/validator/validator/issues">raise an issue</a>.</p></section>
<section id="ariapresentation">
<h3 tabindex="-1" id="presentation">Use of Role=presentation or Role=none</h3>
<p><a href="http://www.w3.org/TR/wai-aria-1.2/#presentation"><code>role=presentation</code></a>, or its synonym <code><a href="https://www.w3.org/TR/wai-aria-1.2/#none">role=none</a></code>, removes the semantics from the element it is on.</p>
<p>For example, this code in the HTML tree:</p>
<pre class="nohighlight"><code class="block"><h1 <mark>role="presentation"</mark>>text</h1></code></pre>
<p>Becomes this in the accessibility tree:</p>
<code class="block"><img src="text.png" width="149" height="25" alt="text, no heading"></code>
<p>In other words, it is just reported in the accessibility tree as a text string with <strong>no semantic meaning</strong>. </p>
<p>For elements with no required children, any elements nested inside the element with <code>role=presentation/none</code> preserve their semantics. </p>
<p>For example, this code in the HTML tree:</p>
<pre class="nohighlight"><code class="block"><h1 <mark>role="presentation"</mark>><abbr>API</abbr></h1></code></pre>
<p>Becomes this in the accessibility tree:</p>
<code class="block"><img src="h1.png" width="185" height="53" alt="abbr with text of API"></code>
<p>For elements with required children (such as <code>ul</code> or <code>table</code>) any required child elements nested inside the element with <code>role=presentation/none</code> also have their semantics removed.</p>
<p>For example, this code in the HTML tree:</p>
<pre class="nohighlight"><code class="block"><table <mark>role="presentation"</mark>>
<tr>
<td>
<abbr>API</abbr>
</td>
</tr>
</table></code></pre>
<p>Becomes this in the accessibility tree:</p>
<code class="block"><img src="abbr.png" width="222" height="87" alt="abbr with text of API"></code>
<p><strong>Note:</strong> Any elements that <em>are not</em> required children of the element with a <code>role=presentation/none</code> keep their semantics. This includes other elements with required children such as nested lists or nested tables.</p>
<p>For example this code, consisting of a table with another table nested inside it, in the HTML tree:</p>
<pre class="nohighlight"><code class="block"><table>
<tr>
<td>
<table>
<tr>
<td>
<abbr>API</abbr>
</td>
</tr>
</table>
</td>
</tr>
</table></code></pre>
<p>Becomes this in the accessibility tree:</p>
<code class="block"><img src="table2.png" width="286" height="149" alt="outer ttable with 1 row and 1 cell containg another table with 1 row and 1 cell containing an abbr element."></code>
<p>By adding <code>role=presentation/none</code> to the outer <code>table</code> element, this code in the HTML tree:</p>
<pre class="nohighlight"><code class="block"><table <mark>role="presentation"</mark>>
<tr>
<td>
<table>
<tr>
<td>
<abbr>API</abbr>
</td>
</tr>
</table>
</td>
</tr>
</table></code></pre>
<p>Becomes this in the accessibility tree, the semantics of the outer <code>table</code> including its required children (the <code>tr</code> and <code>td</code> elements)
are removed by the addition of <code>role=presentation/none</code>:</p>
<code class="block"><img src="table.png" width="286" height="145" alt="table with 1 row and 1 cell containing an abbr element"></code>
<h4 tabindex="-1" id="label">Examples of <code>role=presentation/none</code> Use</h4>
<p >Use in fixing an incorrect table structure</p>
<pre class="nohighlight"><code class="block"><div aria-readonly="true" role="grid">
<table <mark>role="presentation"</mark>>
<tbody><tr role="row">
<th role="columnheader">Dog Names</th>
<th role="columnheader">Cat Names</th>
<th role="columnheader">Cow names</th>
</tr>
</tbody></table>
<table <mark>role="none"</mark>>
<tbody><tr role="row">
<td role="gridcell">Fido</td>
<td role="gridcell">Whiskers</td>
<td role="gridcell">Clarabella</td>
</tr>
<tr role="row">
<td role="gridcell">Woofie</td>
<td role="gridcell">Claws</td>
<td role="gridcell">Glenn</td>
</tr>
</tbody></table>
</div></code></pre>
</section>
<section id="label-support">
<h4 tabindex="-1" id="practical-support-aria-label-aria-labelledby-and-aria-describedby">Practical Support: aria-label, aria-labelledby and aria-describedby</h4>
<h5>Well supported elements</h5>
<ul> <li><code>aria-label</code>, <code>aria-labelledby</code> and <code>aria-describedby</code> are robustly supported for <a href="https://www.w3.org/TR/html52/dom.html#interactive-content-2"> interactive content</a> elements such as <a href="https://www.w3.org/TR/html52/textlevel-semantics.html#elementdef-a">links</a> and form controls including the many <a href="https://www.w3.org/TR/html52/sec-forms.html#the-input-element"><code>input</code></a> types. They also work well on <code>div</code> and <code>span</code> elements with interactive roles such as <code>role=link</code>, <code>button</code>. By design, <code>aria-label</code> or <code>aria-labelledby</code> replace any other label text inside the element.</li>
<li>All three are OK on <code>nav</code> and <code>main</code> elements.</li>
<li>They are OK on <code>div</code> elements <strong>IF</strong> they have <code>role=navigation</code>, <code>search</code>, <code>main</code>, <code>img.</code></li>
<li>They are OK on a <code>table</code> element (<em><strong>except</strong></em> ignored by VoiceOver on iOS).</li>
</ul>
<h5 id="p10">Other static elements with <code>aria-label</code>, <code>aria-labelledby</code> and <code>aria-describedby</code></h5>
<p>NOTE: There are no appreciable differences in these tests across popular browsers, platforms or in <code>iframe</code>s.</p>
<table aria-describedby="p10" >
<thead >
<tr>
<th style="width:10%" scope="col"> </th>
<th style="width:15%" scope="col">JAWS</th>
<th style="width:20%" scope="col">NVDA</th>
<th style="width:30%" scope="col">VoiceOver</th>
<th style="width:12%" scope="col">Talkback</th>
</tr>
</thead>
<tbody><tr>
<th scope="row"><code>aria-labelledby</code> and <code>aria-label</code></th>
<td><p>Ok on <code>td</code>, <code>th</code></p>
<p>Ignored on all other static content <em><strong>except</strong></em> those listed above</p></td>
<td ><p><code>h1, h2, h3, h4, h5, h6</code> are overridden. So are elements with <code>role=heading</code>.</p>
<p><code>landmark</code> roles OK.</p>
<p>Ignored on all other static content <em><strong>except</strong></em> those listed above</p></td>
<td><p><code>h1, h2, h3, h4, h5, h6</code> are overridden. So are elements with <code>role=heading</code>. User can interact with heading to hear it, but its not easily discoverable.</p>
<p><code>landmark</code> roles OK.</p>
<p>Other elements read aria-label with virtual cursor and then let user enter and read the contents.</p></td>
<td><p>All the static content is overridden except <code>ul</code> and <code>li</code> which areignored </p></td>
</tr>
<tr>
<th scope="row"><code>aria-describedby</code></th>
<td><p><strong><em>Well supported</em></strong> on static content</p></td>
<td><p><code>h1, h2, h3, h4, h5, h6</code> are OK as are elements with <code>role=heading</code>. </p>
<p>Ignored on static content not listed above unless given an interactive role and <code>tabindex=0</code>, and then only if the users tabs to it (not arrows to it).</p></td>
<td><p>VO on MacOS is different from iOS</p>
<p>VO on MacOS is OK on most static content.</p>
<p>VO on iOS only reads it if on <code>landmark</code> roles. </p></td>
<td><strong><em>Well supported</em></strong> on static content</td></tr></tbody>
</table>
<p><code>aria-label</code> and <code>aria-labelledby</code> have similar behaviour in screen readers and the Accessibility API, but <code>aria-label</code> should be reserved for when there is no visible text on the page to reference or when keeping track of <code>id</code> values would be too difficult. <a href="http://davidmacd.com/blog/does-aria-label-override-static-text.html">Test sources</a></p>
<h4>Internet Explorer notes on aria-labelledby, aria-label, and aria-describedby</h4>
<p>In Internet Explorer, if you use <code>aria-labelledby</code> with multiple <code>id</code> references or <code>aria-describedby</code> with single or multiple <code>id</code> references, the referenced elements <strong>must be</strong> what Microsoft terms as <a href="http://msdn.microsoft.com/en-us/library/ie/gg701963%28v=vs.85%29.aspx#Accessible_HTML_Elements">accessible HTML elements</a>.</p>
<p>The following example of <code>aria-labelledby</code> with multiple references uses a <code>span</code> with a <code>tabindex=-1</code> added. Refer to <a href="http://msdn.microsoft.com/en-us/library/ie/gg701963%28v=vs.85%29.aspx#Making_Nonaccessible_Elements_Accessible">Making Non accessible Elements Accessible</a>.</p>
<code class="block"><label
<mark>id="l1"</mark>
for="f3">label text</label><br>
<br>
<input type="text" id="f3"
<mark>aria-labelledby="l1 l2"</mark>
><br>
<br>
<p>other content</p><br>
<br>
<span
<mark>tabindex="-1"</mark>
<mark>id="l2"</mark>
>more label text</span></code>
<p>Elements also become <a href="http://msdn.microsoft.com/en-us/library/ie/gg701963%28v=vs.85%29.aspx#Accessible_HTML_Elements">accessible HTML elements</a> in Internet Explorer when the element has an ARIA role. For example:</p>
<code class="block"><div aria-describedby="test">text</div><br>
<br>
<div id="test"
<mark>role="tooltip"</mark>
>tooltip text</div> </code>
<h4>Hiding Content Has No Effect on Accessible Name or Description Calculation</h4>
<p>By design, hiding the content (using CSS <code>display:none</code> or <code>visibility:hidden</code> or the HTML <a href="http://www.w3.org/TR/html51/editing.html#the-hidden-attribute">hidden attribute</a>) of the element(s) referenced by <a href="http://www.w3.org/TR/wai-aria-1.2/#aria-labelledby">aria-labelledby</a> and <a href="http://www.w3.org/TR/wai-aria-1.2/#aria-describedby">aria-describedby</a> does not stop the content from being used to provide the name/description.<!--more-->
</p>
<blockquote>By default, <a class="termref internalDFN" href="https://www.w3.org/TR/accname-aam-1.1/#dfn-assistive-technologies">assistive technologies</a> do not relay hidden information, but an author can explicitly override that and include hidden text as part of the <a class="termref internalDFN" href="https://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-name">accessible name</a> or <a class="termref internalDFN" href="https://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-description">accessible description</a> by using <code>aria-labelledby</code> or <code>aria-describedby</code>.
<footer><cite>- <a href="https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd">Accessible Name and Description: Computation and <abbr title="Application Programming Interfaces">API</abbr> Mappings 1.1</a></cite></footer></blockquote>
<p>In the following example the description will be available to assistive technology users in both states: </p>
<p><strong>Non-error state: </strong>message visually hidden
</p>
<pre class="nohighlight"><code class="block">
<label>Name <input type="text" aria-describedby="error-message"></label>
<span id="error-message" <mark>style="display:none"</mark>>
You have provided an incorrect name</span></code>
</pre>
<p><strong>Note:</strong> addition of <code>aria-hidden=true</code> to the referenced element makes no difference:
</p>
<pre class="nohighlight"><code class="block"><span id="error-message" style="display:none" <mark>aria-hidden="true"</mark>>
You have provided an incorrect name</span></code></pre>
<p><strong>Error state:</strong> message visible
</p>
<pre class="nohighlight"><code class="block"><span id="error-message" <mark>style="display:inline"</mark>>
You have provided an incorrect name</span></code></pre>
<h5>Methods to Provide Context Sensitive Name/Description Text</h5>
If you want to associate context sensitive text, such as an error message, you can:
<ul>
<li>Add the referenced element to the DOM when the error state occurs.</li>
<li>Add the error text as child of the referenced element in the DOM when the error state occurs.</li>
<li>Add the id reference in the DOM to the <code>aria-labelledby/aria-describedby</code> attribute, when the error state occurs.</li>
</ul>
<section>
<h3>The Effect of Accessible Name on Background Images</h3>
<p>Try to avoid presenting informational images in CSS backgrounds. If your image contains important information for the end user, then it should be provided in an HTML <code><img></code> tag with proper <code>alt</code> text. The CSS Spec says this: </p>
<blockquote>
For accessibility reasons, authors should not use background images as the sole method of conveying important information. See <a href="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F3">WCAG failure #F3</a> <a href="https://www.w3.org/TR/css3-background/#ref-WCAG20">[WCAG20] </a>. Images are not accessible in non-graphical presentations, and background images specifically might be turned off in high-contrast display modes. <a href="https://www.w3.org/TR/css3-background/#the-background-image"><em>Source</em> </a>.
</blockquote>
<h5>What If You Can't Avoid Using CSS Images or If You Want Alternate Text for "Non-important" Ambient Photos, Etc.? </h5>
<p>The CSS spec makes its discouragement of CSS informational background images a "SHOULD" not a "MUST" because there are times when visual design or existing code makes it difficult to change it to an HTML image without redesigning the front-end. Other times the author may want to provide alternate text for an ambient image that is <em><strong>not</strong></em> "important" to the understanding of the content but as a courtesy to screen reader users who prefer knowing what is in the image. Here is a detailed article on <a href="http://davidmacd.com/blog/what-is-pure-decoration-alt-text-in-wcag.html">ambient images vs pure decoration vs informational images.</a> </p>
<h5>When Providing Alternate Text for the CSS Image, There Are Number of Considerations </h5>
<p>If the <code><div></code> tag has any content inside it, then a <code>role="img"</code> and <code>aria-label</code> could obscure the inside content because of the <a href="https://www.w3.org/TR/html-aam-1.0/#img-element">accessible name calculation</a>, or the assistive technology might just ignore the <code>aria-label</code>.
</p>
<p>So do not put the CSS background image inside a <code><div></code> that contains any content. It's best to use an empty <code><span></code> and an <code>aria-label</code> with <code>role="img"</code></p>
<p><strong>Do this:</strong></p>
<code class="block">
<div><br>
<span class="background-image" role="img" aria-label="[place alt text here]"> </span><br>
[all the rest of my content]<br>
</div></code>
<p><strong>Don't do this:</strong></p>
<code class="block">
<div class="background-image" role="img" aria-label="blah blah blah"><br>
[all the rest of my content]<br>
</div>
</code>
<h4>What If the Author Has to Have a CSS Image on a <code><div></code> that Contains Content?</h4>
<p>Sometimes there are dependencies in the CSS stack and messing with it can upset the design and layout of the site, or a request to change the code could get hung up in approval from various stakeholders. In cases where the author has to have the background image in the <div> that wraps up other content, then here is a fallback.</p>
<code class="block">
<div class="background-image" ><br>
<span role="img" aria-label="[place alt text here]"> </span><br>
[all the rest of my content]<br>
</div>
</code>
<p>This is a hack because semantically the alternate text is not on the element that actually has the image. However, from a screen reader perspective the <code><div> </code> with the background image is ignored and so placing the <code><span> </code> directly following it will provide that information in a way that will seem as if the alternate text was in the same place as the background image.</p>
</section>
</section>
<section id="using-application">
<h3 tabindex="-1">Using ARIA role=application</h3>
<h4 id="not">How Does role="application" Affect a Screen Reader?</h4>
<p>On many popular screen readers today, most keystrokes are captured by the screen reader and not the web page when the user is in browse mode. This is necessary for efficient navigation of a page. As of this writing, when application mode is set, many screen readers stop intercepting keystrokes, and pass all keystrokes directly to the browser. Then the user won't be able to navigate the page as easily. For instance they won't be able to skip around the page by headings or read a paragraph of static text line-by-line. However, several screen readers do not behave differently when there is an application role set.</p>
<h4>So When Should I Use It, and When Not?</h4>
<p>In determining when to use <code>role=application</code>, one should consider, among other things, the advantages of screen reader keyboard shortcuts weighed against the loss of those features. It generally should not be used, and if it is, usability testing with screen reader users should be conducted.</p>
<p>You <strong>do not</strong> use <code>role="application"</code> if a set of controls only contains these widgets, that are all part of standard HTML. This also applies if you mark them up and create an interaction model using WAI-ARIA roles instead of standard HTML widgets:</p>
<p><strong>NOTE:</strong> It's not recommended that authors develop custom text input widgets. It's almost always best to use the native inputs for these.</p>
<ul>
<li><code>text box</code>. This also applies to password, search, tel and other newer input <em>type</em> derivatives</li>
<li><code>textarea</code></li>
<li><code>check box</code></li>
<li><code>button</code></li>
<li><code>radio button</code> (usually inside a fieldset/legend element wrapper)</li>
<li><code>select + option</code>(s)</li>
<li><code>links</code>, <code>paragraphs</code>, <code>headings</code>, and other elements that are classic/native to documents on the Web.</li>
</ul>
<p>You also do <strong>not</strong> use the <code>application</code> role if your widget is one of the following more dynamic and non-native widgets. Screen readers and other assistive technologies that support WAI-ARIA will support switching between browse and focus modes for these by default too:</p>
<ul>
<li><code>tree view</code></li>
<li><code>slider</code></li>
<li><code>table</code> that has focusable items and is being navigated via the <kbd>arrow</kbd> keys, for example, a list of e-mail messages where you provide specific information. Other examples are interactive grids, tree grids, etc.</li>
<li>A list of tabs (<code>tab, tablist</code>) where the user selects tabs via the left and right <kbd>arrow</kbd> keys. Remember that <strong>you</strong> have to implement the keyboard navigation model for this!</li>
<li><code>dialog</code> and <code>alertdialog</code>. These causes some screen readers to go into a sort of application mode (implicitly) once focus moves to a control inside them. Note that for these to work best, set the <code>aria-describedby</code> attribute of the element whose role is <code>dialog</code> to the <code>id</code> of the text that explains the dialog's purpose, and set focus to the first interactive control when you open it:<br>
<pre class="nohighlight"><code class="block"><div <mark>role="dialog"</mark> aria-label="login" <mark>aria-describedby="log1"</mark>>
<div <mark>id="log1"</mark> tabindex="-1">Provide user name and password to login.</div>
...
...
</div></code></pre></li>
<li><code>toolbar</code> and <code>toolbar buttons</code>, <code>menus</code> and <code>menu items</code>, and similar.</li>
</ul>
<p>You <strong>only</strong> want to use <code>role=application</code> if the content you’re providing consists of <code>only</code> focusable, interactive controls, and of those, mostly advanced widgets that emulate a real desktop application. Note that, despite many things now being called a web application, most of the content these web applications work with are still document-based information, be it Facebook posts and comments, blogs, Twitter feeds, or even accordions that show and hide certain types of information dynamically. We primarily still deal with documents on the web, even though they may have a desktop-ish feel to them on the surface.</p>
<p>It is not necessary to use <code>role=application</code> to have control-specific keyboard shortcuts while the user is in forms (focus) mode on their screen reader. For instance, a custom control with ARIA <code>role=listbox</code> can easily capture all keys pressed including <kbd>arrow</kbd> keys, while the user is interacting with it. </p>
<p><strong>In short: </strong>The times when you actually <strong>will</strong> use <code>role=application</code> will probably be <strong>very rare</strong>!</p>
<h4 id="where">So Where Do I Put <code>role=application</code> in the Rare Cases It Is Useful?</h4>
<p>Put it on the closest containing element of your widget, for example, the parent <code>div</code> of your element that is your outer most widget element. If that outer <code>div</code> wraps only widgets that need the application interaction model, this will make sure focus mode is switched off once the user tabs out of this widget.</p>
<p><strong>Only</strong> put it on the body element if your page consists solely of a widget or set of widgets that all need the focus mode to be turned on. If you have a majority of these widgets, but also have something you want the user to browse, use <code>role=document </code>on the outermost element of this document-ish part of the page. It is the counterpart to <code>role=application</code> and will allow you to tell the screen reader to use browse mode for this part. Also make this element tabbable by setting a <code>tabindex=0</code> on it so the user has a chance to reach it. </p>
<p><strong>As a rule of thumb:</strong> If your page consists of over 90 or even 95 percent of widgets, <code>role=application</code> <strong>may be</strong> appropriate. Even then, find someone knowledgeable who can actually test two versions of this: One with and one without <code>role=application</code> set to see which model works best. </p>
<p><strong>NEVER</strong> put <code>role=application</code> on a widely containing element such as <code>body</code> if your page consists mostly of traditional widgets or page elements such as links that the user does <strong>not</strong> have to interact with in focus mode. This will cause huge headaches for any assistive technology user trying to use your site/application.</p>
<p>For further information on the use of <code>role=application</code> refer to <a href="http://www.marcozehe.de/2012/02/06/if-you-use-the-wai-aria-role-application-please-do-so-wisely/">If you use the WAI-ARIA role "application", please do so wisely!</a></p></section>
<section id="ariachecklist">
<h3 tabindex="-1" id="checklist">Custom Control Accessible Development Checklist:</h3>
<p tabindex="-1">Check your custom control against the following design considerations. If the answer to any of them is 'No' then consider fixing before release or at least documenting the issues to inform other developers that your custom control will not be usable by some people due to limited accessibility support.</p>
<table>
<caption>Custom Control Design Considerations</caption>
<tbody>
<tr>
<th scope="col">design Consideration</th>
<th scope="col">description</th>
<th scope="col">Yes/No</th>
</tr>
<tr>
<th scope="row">focusable</th>
<td>Can you get to the control via the keyboard? Refer to <a href="https://www.w3.org/TR/wai-aria-practices/#kbd_shortcuts_assigning">Providing Keyboard Focus <br>
</a></td>
<td></td>
</tr>
<tr>
<th scope="row">keyboard operable</th>
<td>Can you use the control with the keyboard? Refer to <a href="http://www.w3.org/TR/wai-aria-practices/#keyboard">Keyboard Navigation</a></td>
<td></td>
</tr>
<tr>
<th scope="row">touch operable</th>
<td>Can you use the control with touch gestures? With assistive technology enabled?</td>
<td></td>
</tr>
<tr>
<th scope="row">expected operation</th>
<td>Can you operate the control using the standard keys (Refer to <a href="http://www.w3.org/TR/wai-aria-practices/#aria_ex">ARIA Widget Design Patterns</a>) and/or touch gestures for the control type? </td>
<td></td>
</tr>
<tr>
<th scope="row">clear indication of focus</th>
<td>Can you easily see it when the control has focus? Refer to <a href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html">Visible Focus</a> (WCAG2)</td>
<td></td>
</tr>
<tr>
<th scope="row">label</th>
<td>The control has a text label that is exposed as an <a href="https://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-name">accessible name</a> in <a href="https://www.w3.org/TR/accname-aam-1.1/#dfn_accessibility_api">accessibility APIs</a></td>
<td></td>
</tr>
<tr>
<th scope="row">role</th>
<td>The control has an appropriate role exposed in <a href="https://www.w3.org/TR/html-aam-1.0/#intro_aapi">accessibility APIs</a></td>
<td></td>
</tr>
<tr>
<th scope="row">states and properties</th>
<td>The control has any UI states and properties that it has exposed in <a href="https://www.w3.org/TR/html-aam-1.0/#intro_aapi">accessibility APIs</a></td>
<td></td>
</tr>
<tr>
<th scope="row">color contrast</th>
<td> The control label/description/icon and its states are perceivable/usable for low vision users (Use a <a href="https://www.paciellogroup.com/resources/contrastanalyser/">color contrast checker</a>.)</td>
<td></td>
</tr>
<tr>
<th scope="row">high contrast mode</th>
<td>The control is perceivable/usable when High Contrast Mode is enabled (e.g. <a href="https://www.paciellogroup.com/blog/2010/01/high-contrast-proof-css-sprites/">Windows HC mode</a>)</td>
<td></td>
</tr>
</tbody>
</table></section>
<section id="aria-does-nothing">
<h3>ARIA Adds Nothing to Default Semantics of Most HTML Elements</h3>
<p class="note">In some cases the semantics of an HTML element can be expressed by an ARIA role, state or property. This is<em> </em>known as the element's '<a href="http://www.w3.org/TR/wai-aria-1.2/#implicit_semantics">Default Implicit ARIA semantics</a>'</p>
None of the elements defined in HTML4 need ARIA roles added to expose their default semantics. Adding an ARIA role is extra work for no gain and could lead to pain for you or somebody else. The new features defined in HTML5 , where implemented, now have their default semantics exposed by most browsers.
The <a href="http://www.w3.org/TR/html51/dom.html#aria-usage-note">HTML Specification</a> includes this note:
<blockquote>In the majority of cases setting an ARIA <code data-anolis-xref="attr-aria-role"><a href="http://www.w3.org/TR/html5/infrastructure.html#attr-aria-role">role</a></code> and/or <code data-anolis-xref="attr-aria-*">aria-*</code> attribute that matches the <a href="http://www.w3.org/TR/html51/infrastructure.html#default-implicit-aria-semantics">default implicit ARIA semantics</a> is unnecessary and not recommended as these properties are already set by the browser.</blockquote>
<section>
<h4>Some Examples of Redundant ARIA</h4>
<p>Adding default implicit roles to <a href="http://www.w3.org/TR/html51/dom.html#interactive-content">interactive elements</a> listed in the HTML5 Recommendation is a waste of time:
</p>
<pre class="nohighlight"><code class="block"><button <s>role="button"</s>>press me</button></code> </pre>
<p>Adding ARIA state or property attributes <strong>in addition</strong> to their native HTML counterparts is a waste of time:
</p>
<pre class="nohighlight"><code class="block"><input type="text" required <s>aria-required="true"</s>>
<div hidden <s>aria-hidden="true"</s>></code></pre>
Adding ARIA roles and states or properties to long-implemented structural elements is a waste of time:
<pre class="nohighlight"><code class="block"><h1 <s>role="heading" aria-level="1"</s>>heading text</h1></code></pre>
</section>
</section>
<section id="html-aria-gaps">
<h3 tabindex="-1" id="html5na">Aria Roles and Properties Not Available as Features in HTML</h3>
Below are listed the ARIA roles and properties not considered to be available natively in HTML. It is clear that many roles and properties provided by ARIA, which can be used to convey information to users, are not available in HTML.
<section>
<h4>ARIA Roles</h4>
<ol>
<li><a data-cite="wai-aria-1.2#alert">`alert`</a></li>
<li><a data-cite="wai-aria-1.2#alertdialog">`alertdialog`</a></li>
<li><a data-cite="wai-aria-1.2#application">`application`</a></li>
<li><a data-cite="wai-aria-1.2#directory">`directory`</a></li>
<li><a data-cite="wai-aria-1.2#document">`document`</a></li>
<li><a data-cite="wai-aria-1.2#feed">`feed`</a></li>
<li><a data-cite="wai-aria-1.2#grid">`grid`</a></li>
<li><a data-cite="wai-aria-1.2#gridcell">`gridcell`</a></li>
<li><a data-cite="wai-aria-1.2#group">`group`</a></li>
<li><a data-cite="wai-aria-1.2#log">`log`</a></li>
<li><a data-cite="wai-aria-1.2#marquee">`marquee`</a></li>
<li><a data-cite="wai-aria-1.2#menu">`menu`</a></li>
<li><a data-cite="wai-aria-1.2#menubar">`menubar`</a></li>
<li><a data-cite="wai-aria-1.2#menuitemcheckbox">`menuitemcheckbox`</a></li>
<li><a data-cite="wai-aria-1.2#menuitemradio">`menuitemradio`</a></li>
<li><a data-cite="wai-aria-1.2#none">`none`</a></li>
<li><a data-cite="wai-aria-1.2#note">`note`</a></li>
<li><a data-cite="wai-aria-1.2#presentation">`presentation`</a></li>
<li><a data-cite="wai-aria-1.2#scrollbar">`scrollbar`</a></li>
<li><a data-cite="wai-aria-1.2#search">`search`</a></li>
<li><a data-cite="wai-aria-1.2#status">`status`</a></li>
<li><a data-cite="wai-aria-1.2#switch">`switch`</a></li>
<li><a data-cite="wai-aria-1.2#tab">`tab`</a></li>
<li><a data-cite="wai-aria-1.2#tablist">`tablist`</a></li>
<li><a data-cite="wai-aria-1.2#tabpanel">`tabpanel`</a></li>
<li><a data-cite="wai-aria-1.2#timer">`timer`</a></li>
<li><a data-cite="wai-aria-1.2#toolbar">`toolbar`</a></li>
<li><a data-cite="wai-aria-1.2#tooltip">`tooltip`</a></li>
<li><a data-cite="wai-aria-1.2#tree">`tree`</a></li>
<li><a data-cite="wai-aria-1.2#treegrid">`treegrid`</a></li>
<li><a data-cite="wai-aria-1.2#treeitem">`treeitem`</a></li>
</ol>
</section>
<section>
<h4>ARIA States and Properties (aria-* Attributes)</h4>
<ol>
<li><a data-cite="wai-aria-1.2#aria-activedescendant">`aria-activedescendant`</a></li>
<li><a data-cite="wai-aria-1.2#aria-atomic">`aria-atomic`</a></li>
<li><a data-cite="wai-aria-1.2#aria-busy" class="state-reference">`aria-busy` (state)</a></li>
<li><a data-cite="wai-aria-1.2#aria-controls">`aria-controls`</a></li>
<li><a data-cite="wai-aria-1.2#aria-describedby">`aria-describedby`</a></li>
<li><a data-cite="wai-aria-1.2#aria-dropeffect">`aria-dropeffect`</a></li>
<li><a data-cite="wai-aria-1.2#aria-expanded" class="state-reference">`aria-expanded` (state)</a></li>
<li><a data-cite="wai-aria-1.2#aria-flowto">`aria-flowto`</a></li>
<li><a data-cite="wai-aria-1.2#aria-grabbed" class="state-reference">`aria-grabbed` (state)</a></li>
<li><a data-cite="wai-aria-1.2#aria-haspopup">`aria-haspopup`</a></li>
<li><a data-cite="wai-aria-1.2#aria-hidden" class="state-reference">`aria-hidden` (state)</a></li>
<li><a data-cite="wai-aria-1.2#aria-label">`aria-label`</a></li>
<li><a data-cite="wai-aria-1.2#aria-labelledby">`aria-labelledby`</a></li>
<li><a data-cite="wai-aria-1.2#aria-level">`aria-level`</a></li>
<li><a data-cite="wai-aria-1.2#aria-live">`aria-live`</a></li>
<li><a data-cite="wai-aria-1.2#aria-orientation">`aria-orientation`</a></li>
<li><a data-cite="wai-aria-1.2#aria-owns">`aria-owns`</a></li>
<li><a data-cite="wai-aria-1.2#aria-posinset">`aria-posinset`</a></li>
<li><a data-cite="wai-aria-1.2#aria-pressed" class="state-reference">`aria-pressed` (state)</a></li>
<li><a data-cite="wai-aria-1.2#aria-relevant">`aria-relevant`</a></li>
<li><a data-cite="wai-aria-1.2#aria-setsize">`aria-setsize`</a></li>
<li><a data-cite="wai-aria-1.2#aria-sort">`aria-sort`</a></li>
</ol>
</section>
</section>
<section id="aria-mobile">
<h3 tabindex="-1" id="aria-touch">ARIA Design Patterns and Touch Device Support</h3>
<p class="warning">The <a href="https://w3c.github.io/aria-practices/#aria_ex">ARIA Design Patterns</a> in <a href="https://w3c.github.io/aria-practices/">WAI-ARIA Authoring Practices 1.1</a> describe how to implement custom UI elements so that they are usable by keyboard only users and understandable to users of assistive technology. Some of the ARIA design patterns currently specify, and rely on, keyboard-specific event handling. This is not supported on devices which only provide a touch screen, and has limited or no support (depending on the specific operating system) on mobile phones/tablets with an additional physical keyboard. An <em>in progress </em><a href="https://docs.google.com/spreadsheets/d/1gN9oRZPdrJxLDNtT6nVO4fn7E7sn1061L9Xl3__slZ4/edit?usp=sharing">ARIA design patterns - touch UA/AT gap analysis (Google sheet)</a> is available (Also available as a <a href="aria-touch-gap-analysis-150615.ods">static file in .ods format</a>). Related <a href="https://github.com/w3c/aria/issues/60">WAI-ARIA Authoring Practices 1.1 issue</a></p>
</section>
<section>
<h3 tabindex="-1">Recommendations Table:</h3>
<p>Refer to the <a href="https://www.w3.org/TR/html-aria/#docconformance">Document conformance requirements for use of <abbr title="Accessible Rich Internet Applications">ARIA</abbr> attributes in HTML</a> table in the <a href="http://www.w3.org/TR/html-aria/">ARIA in HTML</a> specification.</p>
</section>
<section>
<h3 id="quick" tabindex="-1">ARIA Role, State, and Property Quick Reference</h3>
<p>Refer to the <a href="https://www.w3.org/TR/html-aria/#allowed-aria-roles-states-and-properties">Allowed ARIA roles, states and properties</a> table in the <a href="http://www.w3.org/TR/html-aria/">ARIA in HTML</a> specification.</p>
</section>
</section>
</body>
</html>