/
core-aam.html
2754 lines (2732 loc) · 259 KB
/
core-aam.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
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>Core Accessibility API Mappings 1.1</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
<script src="../common/script/jquery-1.9.0.min.js"></script>
<script src="https://www.w3.org/Tools/respec/respec-w3c-common" class="remove"></script>
<script src="../common/script/resolveReferences.js" class="remove"></script>
<script src="../common/biblio.js" class="remove"></script>
<link href="../common/css/mapping-tables.css" rel="stylesheet" type="text/css"/>
<link href="../common/css/common.css" rel="stylesheet" type="text/css"/>
<link href="css/core-aam.css" rel="stylesheet" type="text/css"/>
<link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css"/>
<script class="remove">
var respecConfig = {
includePermalinks: true,
// specification status (e.g., WD, LC, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
//crEnd: "2012-04-30",
//perEnd: "2013-07-23",
//publishDate: "2013-08-22",
diffTool: "http://www.aptest.com/standards/htmldiff/htmldiff.pl",
// the specifications short name, as in http://www.w3.org/TR/short-name/
shortName: "core-aam-1.1",
// if you wish the publication date to be other than today, set this
//publishDate: "2014-12-11",
copyrightStart: "2014",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
//previousPublishDate: "2014-06-12",
//previousMaturity: "WD",
prevRecURI: "http://www.w3.org/TR/2014/REC-wai-aria-implementation-20140320/",
//previousDiffURI: "http://www.w3.org/TR/2014/REC-wai-aria-implementation-20140320/",
// if there a publicly available Editors Draft, this is the link
edDraftURI: "http://w3c.github.io/aria/core-aam/core-aam.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2012-02-21",
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Joseph Scheuhammer",
company: "Inclusive Design Research Centre, OCAD University",
companyURI:"http://idrc.ocad.ca"
},
{ name: "Michael Cooper",
company: "W3C",
companyURI: "http://www.w3.org"
},
{ name: "Andi Snow-Weaver (until December 2012)",
company: "IBM",
companyURI: "http://www.ibm.com"
},
{ name: "Aaron Leventhal (until January 2009)",
company: "IBM",
companyURI: "http://www.ibm.com" },
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURI: "http://example.com/" },
//],
/*
alternateFormats: [
{ uri: 'aria-implementation-diff.html',
label: "Diff from Previous Recommendation" } ,
{ uri: 'aria-implementation.ps',
label: "PostScript version" },
{ uri: 'aria-implementation.pdf',
label: "PDF version" }
],
*/
// Working group info
wg: "Accessible Rich Internet Applications Working Group",
wgURI: "http://www.w3.org/WAI/ARIA/",
wgPublicList: "public-aria",
// 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/83726/status",
tocIntroductory: true,
//maxTocLevel: 4,
// Spec URLs
ariaSpecURLs: {
"ED": "http://w3c.github.io/aria/aria/aria.html",
"WD" : "http://www.w3.org/TR/wai-aria-1.1/",
"REC": "http://www.w3.org/TR/wai-aria/"
},
accNameURLs: {
"ED": "http://w3c.github.io/aria/accname-aam/accname-aam.html",
"WD" : "http://www.w3.org/TR/accname-aam-1.1/",
"FPWD": "http://www.w3.org/TR/accname-aam-1.1/",
"REC": "http://www.w3.org/TR/accname-aam-1.1/"
},
localBiblio: biblio,
preProcess: [ linkCrossReferences ]
}
</script>
<script src="../common/script/jquery.details.min.js"></script>
<script src="../common/script/mapping-tables.js"></script>
<script type="text/javascript">
var mappingTableLabels = {
viewByTable: "View as a single table",
expand: "Expand all",
collapse: "Collapse all",
showHideCols: "Show/Hide Columns:",
showActionText: "Show",
hideActionText: "Hide",
showToolTipText: "Show column",
hideToolTipText: "Hide column",
// map where keys are @id of associated mapping table:
viewByLabels: {
"role-mapping-table": "View by roles",
"state-property-mapping-table": "View by state/property",
"event-mapping-table": "View by state/property"
}
}
</script>
</head>
<body>
<section id="abstract">
<p>This document describes how <a class="termref">user agents</a> should expose semantics of web content languages to <a class="termref">accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a>. This helps users with disabilities to obtain and interact with information using <a class="termref">assistive technologies</a>. Documenting these mappings promotes interoperable exposure of roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent. </p>
<p>This Core Accessibility API Mappings specification defines support that applies across multiple content technologies, including general keyboard navigation support and mapping of general-purpose <a class="termref">roles</a>, states, and <a class="termref">properties</a> provided in Web content via <cite><a href="http://www.w3.org/TR/wai-aria-1.1/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></a></cite> [[!WAI-ARIA]]. Other Accessibility API Mappings specifications depend on and extend this Core specification for specific technologies, including native technology features and WAI-ARIA extensions. This document updates and will eventually supercede the guidance in the <a href="http://www.w3.org/TR/wai-aria-implementation/">WAI-ARIA 1.0 User Agent Implementation Guide</a> [[!WAI-ARIA-IMPLEMENTATION]] W3C Recommendation. It is part of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> suite described in the <a href="http://www.w3.org/WAI/intro/aria.php"><abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Overview</a>.</p>
</section>
<section id="sotd">
</section>
<section id="intro">
<h2>Introduction</h2>
<p>This section is <a class="termref">informative</a>.</p>
<p>In traditional desktop graphical user interface (GUI) applications, components of the user interface (UI) are displayed when needed and hidden when not needed based on user interactions. <a class="termref" data-lt="Accessibility APIs">Accessibility application programming interfaces (APIs)</a> are used to communicate <a class="termref">semantic</a> information about the user interface to <a class="termref">assistive technology</a> software used by people with disabilities. These <abbr title="application programming interfaces">APIs</abbr> constitute a contract between applications and assistive technologies, such as screen readers, magnifiers, alternate input devices, and speech command and control, to enable them to access the appropriate semantics needed to produce a usable alternative to interactive applications. For example, screen reading software for blind users can determine whether a particular <abbr title="user interface">UI</abbr> component is a menu, button, text field, list box, etc.</p>
<p>In traditional static Web pages, the <abbr title="Hypertext Markup Language">HTML</abbr> <a class="termref">elements</a> provided the necessary semantic information. The <a class="termref">user agent</a> provides keyboard navigation but only to the <abbr title="Hypertext Markup Language">HTML</abbr> elements that are known to be interactive, specifically links and form elements. Assistive technologies obtain the semantic information from the Document Object Model (<abbr title="Document Object Model">DOM</abbr>) or, in the case of links and form elements, through the Accessibility <abbr title="Application Programming Interface">API</abbr>. In both cases, the assistive technology expects that nothing changes until a new page is loaded based on a user action. </p>
<p>Yet technologies such as JavaScript, Ajax, and <abbr title="cascading style sheets">CSS</abbr> have enabled Web pages to look and behave more like interactive desktop <abbr title="graphical user interface">GUI</abbr> applications, without the need to reload the page with each user interaction. Developers can now re-purpose <abbr title="Hypertext Markup Language">HTML</abbr> elements into <abbr title="user interface">UI</abbr> components not previously defined in <abbr title="Hypertext Markup Language">HTML</abbr>. For example, Javascript can be used with <abbr title="cascading style sheets">CSS</abbr> to modify a <code><div></code> element based on user interactions to make it look and behave like a popup menu. Unfortunately, the <code><div></code> element does not provide the author with a vehicle to add semantic metadata that can be exposed through the <abbr title="Document Object Model">DOM</abbr> and mapped to Accessibility <abbr title="Application Programming Interfaces">APIs</abbr>. These accessibility deficiencies in traditional markup render rich Internet applications unusable by people who use assistive technologies or who rely on keyboard navigation.</p>
<p>The <abbr title="Worldwide Web Consortium">W3C</abbr> Web Accessibility Initiative's (WAI) Protocols and Formats working group (PFWG) has addressed these deficiencies through several <abbr title="Worldwide Web Consortium">W3C</abbr> standards efforts, with a focus on the <cite><a class="specref" href="">Accessible Rich Internet Applications</a></cite> [[!WAI-ARIA]] specification.</p>
<p><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> enables rich Internet applications to have the same accessibility features as desktop <abbr title="graphical user interface">GUI</abbr> applications by adding metadata to markup technologies such as <!-- <abbr title="(Extensible) Hypertext Markup Language">-->(X)HTML<!-- </abbr>-->. Authors include <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> in their markup and user agents translate the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> markup to the platform accessibility <abbr title="application programming interfaces">APIs</abbr>.</p>
<p>For an introduction to <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>, see the <a href="http://www.w3.org/WAI/intro/aria.php"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Overview</a>. The User Agent Implementation Guide describes how <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a class="termref">roles</a>, <a class="termref">states</a>, and <a class="termref">properties</a> should be supported in user agents using platform accessibility <abbr title="Application Programming Interfaces">APIs</abbr>. It is part of a set of resources that define and support the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> specification which includes the following documents: </p>
<ul>
<li><cite><a href="http://www.w3.org/TR/wai-aria-primer/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Primer</a></cite> [[WAI-ARIA-PRIMER]], a W3C Working Group Note, introduces developers to the accessibility problems that <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is intended to solve, the fundamental concepts, and the technical approach of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. It provides a good conceptual understanding of how <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> provides for interoperability with assistive technologies and support for a more usable, accessible experience. </li>
<li><cite><a class="specref" href="">Accessible Rich Internet Applications (WAI-ARIA) 1.0</a></cite> [[!WAI-ARIA]], a planned <abbr title="World Wide Web Consortium">W3C</abbr> recommendation, defines the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> standard.</li>
<li><cite><a href="http://www.w3.org/TR/wai-aria-practices/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices Guide</a></cite> [[WAI-ARIA-PRACTICES]], a planned W3C Working Group Note, describes how web content developers can develop accessible rich internet applications using <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. It provides detailed advice and examples directed primarily to web application developers, yet also useful to user agent and developers of assistive technologies.</li>
<li><cite><a href="http://www.w3.org/TR/wai-aria-roadmap/">Roadmap for Accessible Rich Internet Applications (<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Roadmap)</a></cite> [[WAI-ARIA-ROADMAP]], a planned W3C Working Group Note, defines the path to make rich web content accessible, including steps already taken, remaining future steps, and a time line.</li>
</ul>
<p>The <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> User Agent Implementation Guide begins by providing a general overview of accessibility <abbr title="Application Programming Interfaces">APIs</abbr> and the <a class="termref">accessible object</a> hierarchy known as the <a class="termref">accessibility tree</a>. The following sections give guidance on supporting keyboard navigation and mapping <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles, states, and properties to accessibility <abbr title="Application Programming Interfaces">APIs</abbr>. Other sections give guidance on calculating text alternatives, mapping actions to <a class="termref">events</a>, event processing, special document handling procedures, and error handling.</p>
<p>This guide assumes that a user agent already exposes static content to assistive technology via the accessibility <abbr title="Application Programming Interface">API</abbr> on a given platform. Most of the additional work to enable <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> can be divided into three parts:</p>
<ol>
<li>Enabling keyboard navigation on elements that previously were not focusable</li>
<li>Mapping the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> roles and <a class="termref">attributes</a> into the roles, states and other property getters in the accessibility <abbr title="application programming interface">API</abbr></li>
<li>Computing text alternatives and managing states and events</li>
</ol>
<p>In general, <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> attributes should only affect how content is mapped to platform accessibility <abbr title="application programming interfaces">APIs</abbr>. They should not affect the visual rendering of content nor behavior of mainstream desktop browsers, except when style sheets are deliberately keyed off of <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> attributes as recommended in the specification. This allows one of the primary principles of <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> to be upheld—that content still renders and behaves the same for the majority of users.</p>
<p>This document includes information for user agents specifying how to map <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles, states, and properties to platform accessibility <abbr title="application programming interface">API</abbr>s. It also includes host-language specific requirements where necessary to complete the accessibility model. Examples of host languages include HTML and SVG. However, in order to provide the basic, core mappings of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>, discussion of host-language features are generally avoided. How host languages modify or override the core mappings is specified in separate documents.</p>
<section id="intro_aapi">
<h3>Accessibility <abbr title="Application Programming Interfaces">APIs</abbr> </h3>
<p>To provide access to desktop <abbr title="graphical user interface">GUI</abbr> applications, <a class="termref">assistive technologies</a> originally used heuristic techniques to determine the meaning of the user interface and build an alternative off-screen model. For example, a row of labels displayed horizontally near the top of an application window might be a menu. Labels with a border drawn around them might be buttons. Heuristic techniques are not always accurate, however, and require assistive technologies to be updated whenever the software application is updated.</p>
<p>A much better technique is for the software application to provide the necessary information for interoperability with assistive technology. To meet this need, platform owners have developed specialized interfaces, called <a class="termref">accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a>, which can be used to communicate accessibility information about user interfaces to assistive technologies. </p>
<p>In the case of static Web pages, the Document Object Model (DOM) is used to represent the structure and <a class="termref">state</a> of the <a class="termref">elements</a> in the document being rendered by a <a class="termref">user agent</a>. The elements of the document are organized into a hierarchy of nodes known as the <abbr title="document object model">DOM</abbr> tree. For traditional static Web pages, assistive technologies, such as screen readers, interact with user agents using the <abbr title="Document Object Model">DOM</abbr>. For UI elements that are known to be interactive, such as <abbr title="Hypertext Markup Language">HTML</abbr> form elements and desktop applications, assistive technologies may use platform accessibility <abbr title="Application Programming Interfaces">APIs</abbr>.</p>
<p>In the case of rich Internet applications, developers use <abbr title="Document Object Model">DOM</abbr> <abbr title="application programming interfaces">APIs</abbr> to manipulate <a class="termref">objects</a> in the <abbr title="Document Object Model">DOM</abbr> tree to make them behave like interactive desktop <abbr title="graphical user interface">GUI</abbr> applications. In order to make a Web application <a class="termref">understandable</a> to assistive technologies, the user agent needs to map accessibility information from the elements in the <abbr title="document object model">DOM</abbr> tree to the Accessibility <abbr title="Application Programming Interfaces">APIs</abbr> of the underlying operating system or software platform throughout the lifecycle of the application. The information needed is provided when developers use <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> to supply <a class="termref">semantic</a> <a class="termref">role</a>, state, and <a class="termref">property</a> information for elements. The screen reader or other assistive technology uses the semantic information exposed via the accessibility <abbr title="Application Programming Interface">API</abbr> to provide an alternative rendering of an application that is meaningful to a user. </p>
<p>Accessibility <abbr title="Application Programming Interfaces">APIs</abbr> covered by this document are:</p>
<ul>
<li><abbr title="Microsoft Active Accessibility">MSAA</abbr> with <cite><a href="http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2">IAccessible2 1.3</a></cite> [[IAccessible2]]</li>
<li><cite><a href="https://msdn.microsoft.com/en-us/library/ee684013%28VS.85%29.aspx">User Interface Automation</a></cite> [[UI-AUTOMATION]]</li>
<li><cite>Linux/GNOME <a href="https://developer.gnome.org/atk/stable/">ATK - Accessibility Toolkit</a></cite> [[ATK]] and <cite><a href="https://developer.gnome.org/libatspi/stable/">Assistive Technology Service Provider Interface</a></cite> [[AT-SPI]], referred to hereafter as "ATK/AT-SPI"</li>
<li><cite><a href="https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/index.html">Mac OS X Accessibility Protocol Mac OS 10.10</a></cite> [[AXAPI]]</li>
</ul>
<p>If user agent developers need to expose information using other accessibility <abbr title="Application Programming Interfaces">APIs</abbr>, it is recommended that they work closely with the developer of the platform where the <abbr title="application programming interface">API</abbr> runs, and assistive technology developers on that platform.</p>
</section>
<section id="intro_treetypes">
<h3>The Accessibility Tree and the <abbr title="Document Object Model">DOM</abbr> Tree</h3>
<p>The <a class="termref">accessibility tree</a> and the <abbr title="Document Object Model">DOM</abbr> tree are parallel structures. Roughly speaking the accessibility tree is a subset of the <abbr title="Document Object Model">DOM</abbr> tree. It includes the user interface <a class="termref">objects</a> of the <a class="termref">user agent</a> and the objects of the document. <a class="termref">Accessible objects</a> are created in the accessibility tree for every <abbr title="Document Object Model">DOM</abbr> <a class="termref">element</a> that should be exposed to an <a class="termref">assistive technology</a>, either because it may fire an accessibility <a class="termref">event</a> or because it has a <a class="termref">property</a>, relationship or feature which needs to be exposed. Generally if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <code><span></code> with just a style change and no <a class="termref">semantics</a> may not get its own accessible object, but the style change will be exposed by other means.</p>
</section>
<section>
<h4>Comparing Accessibility APIs</h4>
<p>For various technological and historical reasons, accessibility APIs do not all work in the same way. In many cases, there is no simple one-to-one relationship between how each of them names or exposes roles, states, and properties to user agents. The following subsections describe a few of the distinguising characteristics of some of the APIs.</p>
<section>
<h5>ATK/AT-SPI</h5>
<p>MSAA, IAccessible2, UIA, and AXAPI each define an API that is shared by both the software application exposing information about its content and interactive components, and the user agent (assistive technology) consuming that information. Conversely, Linux/GNOME separates that shared interface into its two aspects, each represented by a different accessibility API, ATK or AT-SPI.</p>
<p>ATK defines an interface that is implemented by software in order to expose accessibility information, whereas AT-SPI is a desktop service that gathers accessibility information from active applications and relays it to other interested applications, usually assistive technologies.</p>
<p>For example, the GNOME GUI toolkit [GTK], implements the relevant aspects of ATK for each widget (menu, comobox, checkbox, etc.) in order that GTK widgets expose accessibility information about themselves. AT-SPI then acquires the information from applications built with GTK and makes it available to interested parties.</p>
<p>ATK is most relevant to implementors, wherease AT-SPI is relevant to consumers. In the context of mapping WAI-ARIA roles, states and properties, user agents are implementors and use ATK. Asisstive Technologies are consumers, and use AT-SPI.</p>
</section>
<section>
<h5>Accessible Names and Descriptions</h5>
<p>Each platform accessibility API includes a way to assign and retrieve <a class="termref">accessible name</a> and <a class="termref">accessible description</a> properties for each <a class="termref">accessible object</a> created in the <a class="termref">accessibility tree</a>. How these the relevant properties are implemented and what they are called vary depending on the API.</p>
<p>For instance, in MSAA, all <a class="termref">accessible objects</a> support the <code>accName</code> property, which stores the object's <a class="termref">accessible name</a>. Where the object also supports having an <a class="termref">accessible description</a>, MSAA stores this property in the object's <code>accDescription</code> property.</p>
<p>Software using ATK can read and write to an object's <code>accessible-name</code> and <code>accessible-description</code> properties. In turn, AT-SPI can query the values of those properties through its <code>atspi_accessible_get_name</code> and <code>atspi_accessible_get_description</code> functions.</p>
<p>Automation elements in the UIA accessibility tree have a <code>Name</code> property. [what about description in UIA?].</p>
<p>The approach to <a class="termref">accessible names</a> and <a class="termref" data-lt="accessible description">accessible descriptions</a> in AXAPI is somewhat different to the other platform APIs. <a class="termref">Accessible names</a> are exposed using the <code>AXTitle</code> property when the name is visually rendered, while the <code>AXDescription</code> property is used when the object's name is not rendered visually. An object's <a class="termref">accessible description</a>, where provided, should always be exposed in the <code>AXHelp</code> property.</p>
<p>For more detail, see the <a class="accname" href="">Accessible Name and Description Computation and API Mappings</a> specification.</p>
</section>
</section>
</section>
<section id="normative" class="normative">
<h2>Normative User Agent Implementation Requirements for <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></h2>
<p>This section is <a class="termref">normative</a>.</p>
<p>This specification indicates whether a section is <a class="termref">normative</a> or <a class="termref">informative</a> and the classification applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.</p>
<p>Normative sections provide requirements that <a class="termref">user agents</a> must follow for an implementation to conform to this specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in <cite><a href="http://www.rfc-editor.org/rfc/rfc2119.txt">Keywords for use in RFCs to indicate requirement levels</a></cite> [[!RFC2119]]. RFC-2119 keywords are formatted in uppercase and contained in a <code>strong</code> element with <code>class="rfc2119"</code>. When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.</p>
<p>Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.</p>
</section>
<section id="glossary">
<h2>Important Terms</h2>
<p>This section is <a class="termref">normative</a>.</p>
<div data-include="../common/terms.html" data-oninclude="restrictReferences"></div>
</section>
<section class="section" id="keyboard-focus">
<h2>Supporting Keyboard Navigation</h2>
<p>This section is <a class="termref">normative</a>.</p>
<p>Enabling keyboard navigation in web applications is a necessary step toward making them accessible. <a class="termref">User agents</a> MUST provide a mechanism for authors to specify that any renderable <a class="termref">element</a> may be focusable without placing the element in a pre-defined tabbing order.</p>
<p>User agents MUST also provide programmatic access to all focusable elements. This allows for device-independent access, is needed to conform to the <cite><a href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/">User Agent Accessibility Guidelines</a></cite> [[UAAG10]], and is vital for a successful implementation of <abbr title="accessible rich internet applications">WAI-ARIA</abbr>.</p>
<p>Usable keyboard navigation in a rich Internet application is different from the tabbing paradigm among interactive elements, such as links and form controls, in a static document. In rich internet applications, the user tabs to significantly complex <a class="termref">widgets</a>, such as a menu or spreadsheet, and uses the arrow keys to navigate within the widget. The changes that <abbr title="accessible rich internet applications">WAI-ARIA</abbr> introduces to keyboard navigation make this enhanced accessibility possible. In <abbr title="accessible rich internet applications">WAI-ARIA</abbr>, any element can be keyboard focusable. In addition to host language mechanisms such as <code>tabindex</code>, <a class="property-reference" href="#aria-activedescendant"><code>aria-activedescendant</code></a> provides another mechanism for keyboard operation. Most other aspects of <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> widget development depend on keyboard navigation functioning properly.</p>
<p><a class="termref">Assistive technologies</a> often need to set the focus. For example, voice input software, onscreen keyboards and screen readers supply their own structured navigation modes, providing additional commands for moving to elements in a page. User agents need to allow assistive technologies to set the focus. See the section titled "<a href="#keyboard-focus_at">Handling focus changes from the Assistive Technology</a>" for details.</p>
<section id="focus_state_event_table">
<h3>Focus States and Events Table</h3>
<p>The following table defines the accessibility <abbr title="Application Programming Interface">API</abbr> keyboard focus states and events used in later sections of the document.</p>
<ul>
<li>If the context is <a href="#keyboard-focus_tabindex">controlling focus with <code>tabindex</code></a>, the <abbr title="Document Object Model">DOM</abbr> focus (<code>document.activeElement</code>) is in sync with the focus states and events listed in the table. </li>
<li>If the context is <a href="#keyboard-focus_aria-activedescendant">controlling focus with <code>aria-activedescendant</code></a>, the <abbr title="Document Object Model">DOM</abbr> focus is separate from the focus states and events for the <abbr title="Microsoft Active Accessibility">MSAA</abbr>, Microsoft <abbr title="User Interface Automation">UIA</abbr>, and <abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr> columns of the table.
<p class="note">An example is a single-selection <code>listbox</code> that controls focus using <code>aria-activedescendant</code> instead of <code>tabindex</code>. The <code>option</code> children are all marked with the focusable state in the accessibility <abbr title="Application Programming Interface">API</abbr>. As the user navigates from one <code>option</code> child to the next, DOM focus is maintained on the <code>listbox</code> parent, but the accessibility <abbr title="Application Programming Interface">API</abbr> emits a focus event and exposes the focused state for the <code>option</code> child that the <code>listbox</code> references as the active descendant.</p>
</li>
</ul>
<table>
<caption>Table of <a class="termref">accessibility <abbr title="application programming interface">APIs</abbr></a> for focus states and <a class="termref">events</a> </caption>
<tr>
<th> </th>
<th><abbr title="Microsoft Active Accessibility">MSAA</abbr></th>
<th>Microsoft <abbr title="User Interface Automation">UIA</abbr></th>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr></th>
<th><abbr title="Mac OS X Accessibility Protocol">AXAPI</abbr></th>
</tr>
<tr>
<th>Focusable state</th>
<td><code>STATE_SYSTEM_FOCUSABLE</code></td>
<td><code>UIA_IsKeyboardFocusablePropertyId</code></td>
<td><code>STATE_FOCUSABLE</code></td>
<td><code>boolean AXFocused</code>: the <code>accessibilityIsAttributeSettable</code> method returns <code>YES</code>.</td>
</tr>
<tr>
<th>Focused state</th>
<td><code>STATE_SYSTEM_FOCUSED</code></td>
<td><code>UIA_HasKeyboardFocusPropertyId</code></td>
<td><code>STATE_FOCUSED</code></td>
<td><code>boolean AXFocused</code></td>
</tr>
<tr>
<th>Focus event</th>
<td><code>EVENT_OBJECT_FOCUS</code></td>
<td><code>UIA_AutomationFocusChangedEventId</code></td>
<td><code>object:state-changed:focused</code> and OPTIONAL <code>focus:</code></td>
<td><code>AXFocusedUIElementChanged</code></td>
</tr>
</table>
</section>
<section id="keyboard-focus_tabindex">
<h3>Controlling focus with <code>tabindex</code></h3>
<p><a class="termref">User agents</a> that support <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> expand the usage of <code>tabindex</code>, <code>focus</code>, and <code>blur</code> to allow them on all <a class="termref">elements</a>. Authors may add any element such as a <code>div</code>, <code>span</code> or <code>img</code> to the default tab order by setting <code>tabindex="0"</code>. In addition, any item with <code>tabindex</code> equal to a negative integer is focusable via script or a mouse click, but is not part of the default tab order. This is not supported in the <abbr title="Hypertext Markup Language version 4">HTML4</abbr> specification but is in compliance with <abbr title="Hypertext Markup Language version 5">HTML5</abbr> and <abbr title="Scalable Vector Graphics verions 2">SVG2</abbr>.</p>
<p>The <code>tabindex</code> system provides one way to develop custom <a class="termref">widgets</a> which are <a class="termref">keyboard accessible</a>, from simple widgets like a <code>slider</code> to container widgets like a <code>menubar</code>, <code>treeview</code> or <code>grid</code>.</p>
<p class="note">Refer to the <a href="#focus_state_event_table">Table of accessibility <abbr title="Application Programming Interfaces">APIs</abbr> for focus states and events</a> for the rules in this section.</p>
<p>The user agent MUST do the following to enable accessible <code>tabindex</code> usage on all elements:</p>
<ol>
<li>Where <code>tabindex</code> equals a negative integer, set the focusable state, but do not include the element in the sequential tab order.</li>
<li>Where <code>tabindex="0"</code>, set the focusable state and include it in the sequential tab order.</li>
<li>Where <code>tabindex</code> is greater than zero, set the focusable state, and include the element in the sequential tab order according to the value of the <code>tabindex</code> <a class="termref">attribute</a> and before any elements with <code>tabindex</code> either omitted or with a value of zero. See <cite><a href="http://www.w3.org/TR/2009/WD-html5-20090825/editing.html#sequential-focus-navigation">Sequential focus navigation</a></cite> [[HTML5]] for details. </li>
<li>Expose the <code>element.tabIndex</code> <a class="termref">property</a> for every element that supports the <code>tabindex</code> attribute.</li>
<li>Support the <code>focus()</code> and <code>blur()</code> methods on element interfaces that support the <code>tabindex</code> attribute, e.g., <code>HTMLElement</code> and <code>SVGElement</code>. This allows scripts to move the focus to the element.</li>
<li>Fire <code>focus</code>, <code>blur</code>, <code>DOMFocusIn</code>, and <code>DOMFocusOut</code> <a class="termref">events</a> for any element that can receive focus.</li>
<li>When a <code>keydown</code> event is cancelled, also cancel the <code>keypress</code> event.</li>
<li>Expose the focusable states for any element in the accessibility tree.</li>
<li>When any object has focus, expose the focused state. When it loses focus, remove the focused state.</li>
<!--
<li>When the user triggers an element that is only focusable because of its <code>tabindex</code> attribute in a manner other than clicking it, such as by pressing <kbd>Enter</kbd>, and the element has no defined <a class="termref">activation behavior</a>, fire a <code>click</code> event.
<p class="ednote">This bullet is currently normative. Its status is considered a <a href="#sotd_atrisk">feature at risk</a> and may be removed if interoperable implementations are not found. If so, it will be re-introduced in the ARIA 1.1. timeframe.</p>
</li>
-->
<!--
<li>When the user triggers an element with a defined activation behavior in a manner other than clicking it, such as by pressing <kbd>Enter</kbd>, simulate a <code>click</code> on the element. The steps to simulate a <code>click</code> include:
<ol>
<li>running pre-click activation steps</li>
<li>firing a <code>click</code> event</li>
<li>running post-click activation steps</li>
</ol>
If the event is cancelled, run cancelled activation steps on the element instead.
<p class="ednote">This bullet is currently normative. Its status is considered a <a href="#sotd_atrisk">feature at risk</a> and may be removed if interoperable implementations are not found. If so, it will be re-introduced in the ARIA 1.1. timeframe.</p>
</li>
-->
</ol>
</section>
<section id="keyboard-focus_aria-activedescendant">
<h3>Controlling focus with <code>aria-activedescendant</code></h3>
<p>When implementing <a class="property-reference" href="#aria-activedescendant"><code>aria-activedescendant</code></a> as described below, the user agent keeps the <abbr title="Document Object Model">DOM</abbr> focus on the container element but communicates <a class="termref" data-lt="desktop focus event">desktop focus events</a> and states to the assistive technology as if the active descendant has focus. It is the responsibility of the user agent to ensure that keyboard events are processed at the container <a class="termref">element</a> that has <abbr title="Document Object Model">DOM</abbr> focus. Any keyboard events directed at the active descendant bubble up to the <abbr title="Document Object Model">DOM</abbr> element with focus, the container element, for processing.</p>
<p>The <code>aria-activedescendant</code> <a class="termref">property</a> may be used to enable keyboard accessibility on <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">elements</a> that support this <a class="termref">attribute</a>. It is often a more convenient way of creating container <a class="termref">widget</a> keyboard navigation (where the entire widget is in the tab order just once, but the user can use other keys, typically <kbd>arrow</kbd> keys, to navigate to descendant items of the container).</p>
<p>Typically, the author will use host language <a class="termref">semantics</a> to put the container element in the sequential tab order (e.g., <code>tabindex="0"</code> in <abbr title="Hypertext Markup Language">HTML</abbr>) and <code>aria-activedescendant</code> to point to the ID of the currently active descendant. The author, not the <a class="termref">user agent</a>, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use <code>:<span class="css-selector">focus</span></code> to style the currently active descendant since actual focus is on the container.</p>
<p class="note">Refer to the <a href="#focus_state_event_table">Table of accessibility <abbr title="Application Programming Interfaces">APIs</abbr> for focus states and events</a> for the rules in this section.</p>
<p>The user agent MUST do the following to implement <code>aria-activedescendant</code>:</p>
<ol>
<li>Implement the host language method for keyboard navigation so that the container widget may be included in the tab order. See <a href="#keyboard-focus_tabindex">Controlling focus with <code>tabindex</code></a>. </li>
<li>For platforms that expose <a class="termref" data-lt="desktop focus event">desktop focus</a> or <a class="termref" href="#dfn-accessibility-api">accessibility <abbr title="application programming interface">API</abbr></a> focus separately from <abbr title="Document Object Model">DOM</abbr> focus, do not expose the focused state in the <a class="termref" href="#dfn-accessibility-api">accessibility <abbr title="application programming interface">API</abbr></a> for any element when it has <abbr title="Document Object Model">DOM</abbr> focus and also has <code>aria-activedescendant</code> which points to a <a class="termref" data-lt="valid idref">valid ID</a>.</li>
<li>When the <code>aria-activedescendant</code> attribute changes on an element that currently has <abbr title="Document Object Model">DOM</abbr> focus, remove the focused state from the previously focused object and fire an accessibility <abbr title="application programming interface">API</abbr> <a class="termref">desktop focus event</a> on the new active descendant. If <code>aria-activedescendant</code> is cleared or does not point to an element in the current document, fire a desktop focus event for the container <a class="termref">object</a> that had the attribute change.</li>
<li>For any element with an ID attribute, where the element is a descendant of an element with the<code> aria-activedescendant</code> attribute, apply the following accessibility <abbr title="Application Programming Interface">API</abbr> states to the target to ensure the object is accessible:
<ol>
<li>Focusable, if the element also has a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">role</a> — because the <code>aria-activedescendant</code> of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because elements that would be focusable would already have the focusable state.</li>
<li>Focused, whenever the container element sets <code>aria-activedescendant</code> to match the ID of this descendant and the container widget with <code>aria-activedescendant</code> has <abbr title="Document Object Model">DOM</abbr> focus.</li>
</ol>
</li>
</ol>
</section>
<section id="keyboard-focus_at">
<h3>Handling focus changes from the Assistive Technology</h3>
<p>Assistive technologies, such as screen readers, voice input software and on-screen keyboards, might request that the keyboard focus be moved using the following accessibility <abbr title="Application Programming Interfaces">APIs</abbr>:</p>
<ul>
<li>MSAA: <code>accSelect(SELFLAG_TAKEFOCUS)</code></li>
<li>UIA: <code>RaiseAutomationEvent</code></li>
<li>ATK/AT-SPI: <code>AtkComponent::grab_focus</code></li>
<li><abbr title="Mac OS X Accessibility Protocol">AXAPI</abbr>: Notification: <code>AXFocusedUIElementChanged</code></li>
</ul>
<p class="note">Refer to the <a href="#focus_state_event_table">Table of accessibility <abbr title="Application Programming Interfaces">APIs</abbr> for focus states and events</a> for the rules in this section.</p>
<p>When an assistive technology requests a change of focus using one of the above <abbr title="Application Programming Interfaces">APIs</abbr>, user agents MUST do the following:</p>
<ul>
<li>Remove the focused state from the previously focused object.</li>
<li>If the <a class="termref">element</a> can take <abbr title="Document Object Model">DOM</abbr> focus, the <a class="termref">user agent</a> MUST set the <abbr title="Document Object Model">DOM</abbr> focus to it. Otherwise, if the current element has an ID and an ancestor with the <a class="property-reference" href="#aria-activedescendant"><code>aria-activedescendant</code></a> <a class="termref">attribute</a> present, the user agent MUST set <abbr title="Document Object Model">DOM</abbr> focus to that ancestor. When it is not possible for the user agent to set <abbr title="Document Object Model">DOM</abbr> focus to the containing element with <code>aria-activedescendant</code>, the user agent MAY attempt to set <abbr title="Document Object Model">DOM</abbr> focus to the child element itself.</li>
<li>If the current element has an ID and an ancestor with the <code>aria-activedescendant</code> attribute present, the user agent MUST set the accessibility <abbr title="Application Programming Interface">API</abbr> focused state and fire an accessibility <abbr title="Application Programming Interface">API</abbr> <a class="termref">desktop focus event</a> on the new active descendant.</li>
</ul>
<p class="note">The inability to set <abbr title="Document Object Model">DOM</abbr> focus to the containing element indicates an author error.</p>
</section>
</section>
<section id="mapping">
<h2>Mapping <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> to Accessibility <abbr title="Application Programming Interfaces">APIs</abbr></h2>
<p>This section is <a class="termref">normative</a>.</p>
<section id="mapping_general">
<h3>General rules for exposing <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> semantics</h3>
<p>Where supported by the platform <a class="termref" href="#dfn-accessibility-api">Accessibility <abbr title="Application Programming Interface">API</abbr></a>, <a class="termref">user agents</a> expose <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">semantics</a> through the standard mechanisms of the desktop accessibility <abbr title="application programming interface">API</abbr>. For example, for <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">widgets</a>, compare how the widget is exposed in a similar desktop widget. In general most <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> widget capabilities are exposed through the <a class="termref">role</a>, value, Boolean <a class="termref">states</a>, and relations of the accessibility <abbr title="application programming interface">API</abbr>.</p>
<p>With respect to <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.0, accessibility <abbr title="application programming interfaces">APIs</abbr> operate in one direction only. User agents publish <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> information (roles, states, and <a class="termref">properties</a>) via an accessibility <abbr title="application programming interface">API</abbr>, and an <abbr title="assistive technology">AT</abbr> can acquire that information using the same <abbr title="application programming interface">API</abbr>. However, the other direction is not supported. <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.0 does not define mechanisms for assistive technologies to directly modify <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> information.</p>
<section id="exclude_elements2">
<h4>Excluding Elements from the Accessibility Tree</h4>
<p>The following <a class="termref">elements</a> are not exposed via the <a class="termref" href="#dfn-accessibility-api">accessibility <abbr title="Application Programming Interface">API</abbr></a> and <a class="termref">user agents</a> MUST NOT include them in the <a class="termref">accessibility tree</a>:</p>
<ul>
<li>Elements with <a class="role-reference" href="#none"><code>none</code></a > or <a class="role-reference" href="#presentation"><code>presentation</code></a> as the first mappable role in the role attribute string, according to the rules for the <code>none</code> and the <code>presentation</code> <a class="termref">role</a> defined in <cite><a class="specref" href="#">Accessible Rich Internet Applications (WAI-ARIA) 1.0</a></cite> [[!WAI-ARIA]]. </li>
<li>Elements, including their descendants, that have host language semantics specifying that the element is not displayed, such as CSS <code>display:none</code> or <code>visibility:hidden</code> or HTML 5 <code>hidden</code> attribute. </li>
</ul>
<p>If not already excluded from the accessibility tree per the above rules, user agents SHOULD NOT include the following elements in the accessibility tree: </p>
<ul>
<li>Elements, including their descendants, that have a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> global attribute of <a class="property-reference" href="#aria-hidden"><code>aria-hidden</code></a><code>="true".</code> In other words, <code>aria-hidden="true"</code> on a parent overrides <code>aria-hidden="false"</code> on descendants. </li>
<li>Children of <a class="termref">objects</a> which have the characteristic "<a class="specref" href="#childrenArePresentational">Children Presentational: True</a>":
<ul>
<li><a class="role-reference" href="#button"><code>button</code></a></li>
<li><a class="role-reference" href="#img"><code>img</code></a></li>
<li><a class="role-reference" href="#math"><code>math</code></a></li>
<li><a class="role-reference" href="#progressbar"><code>progressbar</code></a></li>
<li><a class="role-reference" href="#separator"><code>separator</code></a></li>
<li><a class="role-reference" href="#scrollbar"><code>scrollbar</code></a></li>
<li><a class="role-reference" href="#slider"><code>slider</code></a></li>
</ul>
</li>
</ul>
</section>
<section id="include_elements">
<h4>Including Elements in the Accessibility Tree</h4>
<p>If not already excluded from the accessibility tree per the rules above in <a href="#exclude_elements2">Excluding Elements in the Accessibility Tree</a>, <a class="termref">user agents</a> MUST provide an <a class="termref">accessible object</a> in the <a class="termref">accessibility tree</a> for <abbr title="Document Object Model">DOM</abbr> <a class="termref">elements</a> that meet any of the following criteria:</p>
<ul>
<li>Text elements</li>
<li>Elements that may fire an accessibility <abbr title="Application Program Interface">API</abbr> <a class="termref">event</a></li>
<li>Elements that are focusable, or have an ID <a class="termref">attribute</a> and an ancestor with the <a class="property-reference" href="#aria-activedescendant"><code>aria-activedescendant</code></a> attribute that matches the implicit or explicit <a class="termref">semantics</a> of the required context role. In either case, the element may receive focus and need to fire a<code> FOCUS </code>event.</li>
<li>Elements that have a mappable role in the role attribute string (see <a href="#mapping_role">Role Mapping</a> below). </li>
<li>Elements that have a global <abbr title="Accessible Rich Internet Application">WAI-ARIA attribute </abbr> but do not have <a class="property-reference" href="#aria-hidden"><code>aria-hidden</code></a><code>="true"</code>. (See <a href="#exclude_elements2">Excluding Elements in the Accessibility Tree</a> for additional guidance on <code>aria-hidden</code>.)</li>
<li>Elements that have an ID which is referenced by another element via a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> relation (<a class="property-reference" href="#aria-controls"><code>aria-controls</code></a>, <a class="property-reference" href="#aria-describedby"><code>aria-describedby</code></a>, <a class="property-reference" href="#aria-flowto"><code>aria-flowto</code></a>, <a class="property-reference" href="#aria-labelledby"><code>aria-labelledby</code></a> or <a class="property-reference" href="#aria-owns"><code>aria-owns</code></a>) and are not <a class="termref">hidden</a>.
<p class="note">Text equivalents for hidden referenced objects may still be used in the <a href="#mapping_additional_nd">name and description calculation</a> even when not included in the accessibility tree. </p>
</li>
</ul>
</section>
<section id="notify_state_changes">
<h4>Notification of State Changes</h4>
<p>User agents notify assistive technologies of state and property changes as defined in <a href="#mapping_events">Events</a>.</p>
</section>
</section>
<section id="mapping_conflicts">
<h3>Conflicts between native markup semantics and <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr></h3>
<p><abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> roles, states, and properties are intended to add <a class="termref">semantic</a> information when native host language <a class="termref">elements</a> with these semantics are not available, and are generally used on elements that have no native semantics of their own. They can also be used on elements that have similar but not identical semantics to the intended object (for instance, a nested list could be used to represent a tree structure). This method can be part of a fallback strategy for older browsers that have no <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> implementation, or because native presentation of the repurposed element reduces the amount of style and/or script needed. Except for the cases outlined below, <a class="termref">user agents</a> MUST always use the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> semantics to define how it exposes the element to <a class="termref" href="#dfn-accessibility-api">accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a>, rather than using the host language semantics.</p>
<p>Host languages can have features that have implicit <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> semantics corresponding to <a class="termref">roles</a>. When a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role is provided that has a corresponding role in the accessibility <abbr title="Application Programming Interface">API</abbr>, user agents MUST use the semantic of the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role for processing, not the native semantic, unless the role requires <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties whose attributes are explicitly forbidden on the native element by the host language. Values for roles do not conflict in the same way as values for states and properties, and because authors are expected to have a valid reason to provide a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role even on elements that would not normally be repurposed. For example, spin buttons are typically constructed from text fields (<code><input type="text"></code>) in order to get most of the default keyboard support. But, the native role, "text field", isn't correct because it doesn't properly communicate the additional features of a spin button. The author will add the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role of spinbutton (<code><input type="text" role="spinbutton" ...></code>) so that the control gets properly mapped in the accessibility <abbr title="Application Programming Interface">API</abbr>. When a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role is provided that does not have a corresponding role in the accessibility <abbr title="Application Programming Interface">API</abbr>, user agents MAY expose the native semantic in addition to the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role.</p>
<p class="ednote">The above text differs slightly from the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> specification. The requirement for user agents to expose the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role instead of the native role was intended to only apply in cases where there is a direct mapping from the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role to a corresponding role in the accessibility <abbr title="Application Programming Interface">API</abbr>. The wording of the requirement is not clear in the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> specification, however, and has been interpreted differently by implementers. The requirement has been clarified here and an additional statement added to indicate that user agents may expose native semantics if there is not a direct mapping to a role in the accessibility <abbr title="Application Programming Interface">API</abbr>. Because there are differing implementations, authors will be advised against adding such <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> roles to native elements that have their own semantics in the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Authoring Practices Guide.</p>
<p>When <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties correspond to host language features that have the same implicit <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantic, it can be problematic if the values become out of sync. For example, the <abbr title="Hypertext Markup Language">HTML</abbr> <code>checked</code> attribute and the <code>aria-checked</code> attribute could have conflicting values. Therefore to prevent providing conflicting states and properties to assistive technologies, host languages will explicitly declare where the use of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> attributes on a host language element conflict with native attributes for that element. When a host language declares a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a class="termref">attribute</a> to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> attribute and instead use the host language attribute with the same implicit semantic. </p>
<p>Host languages might also document features that cannot be overridden with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> (these are called "strong native semantics"). These can be features that have implicit <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics as well as features where the processing would be uncertain if the semantics were changed with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. While conformance checkers might signal an error or warning when a <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role is used on elements with strong native semantics, user agents MUST still use the value of the semantic of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role when exposing the element to accessibility <abbr title="Application Programming Interfaces">APIs</abbr>.</p>
</section>
<section id="mapping_nodirect">
<h3>Exposing attributes that do not directly map to accessibility <abbr title="application programming interface">API</abbr> properties</h3>
<p>Platform <a class="termref" href="#dfn-accessibility-api">accessibility <abbr title="application programming interfaces">APIs</abbr></a> might have features that are not in <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr>. Likewise, <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> exposes capabilities that are not supported by accessibility <abbr title="Application Programming Interfaces">APIs</abbr> at the time of publication. There typically is not a one to one relationship between all <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">attributes</a> and platform accessibility <abbr title="application programming interfaces">APIs</abbr>. When <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> <a class="termref">roles</a>, <a class="termref">states</a> and <a class="termref">properties</a> do not directly map to an accessibility <abbr title="application programming interface">API</abbr>, and there is a mechanism in the <abbr title="application programming interface">API</abbr> to expose the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role, states, and properties and their values, <a class="termref">user agents</a> MUST expose the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> data using that mechanism as follows: </p>
<ul>
<li>In IAccessible2 and <abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr>, use object attributes to expose <a class="termref">semantics</a> that are not directly supported in the <abbr title="application programming interfaces">APIs</abbr>. Object attributes are name-value pairs that are loosely specified, and very flexible for exposing things where there is no specific interface in an accessibility <abbr title="application programming interface">API</abbr>. For example, at this time, the <a class="property-reference" href="#aria-live"><code>aria-live</code></a> attribute can be exposed via an object attribute because accessibility <abbr title="application programming interfaces">APIs</abbr> have no such property available. Specific rules for exposing object attribute name-value pairs are described throughout this document, and rules for the general cases are in <a href="#mapping_state-property">State and Property Mapping</a>.</li>
<li>In Microsoft <abbr title="User Interface Automation">UIA</abbr>, use the <code>AriaRole</code> and <code>AriaProperties</code> properties to expose semantics that are not directly supported in the control type.</li>
</ul>
<p class="ednote">MSAA does not provide a mechanism for exposing attributes that do not map directly to the <abbr title="application programming interface">API</abbr> and among implementers, there is no agreement on how to do it.</p>
<p>User agents MUST also expose the entire role string through this mechanism and MAY also expose <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> attributes and values through this mechanism even when there is a direct mapping to an accessibility <abbr title="application programming interface">API</abbr>.</p>
<p>Browser implementers are advised to publicly document their <abbr title="application programming interface">API</abbr> methods for exposing any relevant information, so that <a class="termref">assistive technology</a> developers can use the <abbr title="application programming interface">API</abbr> to support user features.</p>
</section>
<section id="mapping_role">
<h2>Role mapping</h2>
<p>Platform <a class="termref" href="#dfn-accessibility-api">accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a> traditionally have had a finite set of predefined <a class="termref">roles</a> that are expected by <a class="termref">assistive technologies</a> on that platform and only one or two roles may be exposed. In contrast, <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> allows multiple roles to be specified as an ordered set of space-separated valid role tokens. The additional roles are fallback roles similar to the concept of specifying multiple fonts in case the first choice font type is not supported.</p>
<section id="roleMappingGeneralRules">
<h2>General rules</h2>
<p>The following rules describe how to expose WAI-ARIA roles using the accessibility <abbr title="application programming interface">API</abbr>:</p>
<ol>
<li>The user agent MUST use the first token in the sequence of tokens in the role <a class="termref">attribute</a> value which matches the name of any non-abstract <abbr title="Accessible Internet Application">WAI-ARIA</abbr> role according to rules that are specified in the <a href="#mapping_role_table">Role Mapping Table</a> below. See <a href="#mapping_conflicts">Conflicts between native markup semantics and WAI-ARIA</a> for additional information. Note that when <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> roles override host language semantics, there are no changes in the <abbr title="Document Object Model">DOM</abbr>, only in the <a class="termref">accessibility tree</a>. In the absence of author-supplied scripts, the presence of <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> roles might not make sense. But user agents MUST map <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> roles even in the absence of author-supplied scripts.
<p>The following steps will correctly identify the applicable <abbr title="Accessible Rich Internet Applicatiaon">WAI-ARIA</abbr> role:</p>
<ol>
<li>Use the rules of the host language to detect that an element has a role attribute and to identify the attribute value string for it.</li>
<li>Separate the attribute value string for that attribute into a sequence of whitespace-free substrings by separating on whitespace.</li>
<li>Do a comparison of the substrings to all the names of the non-abstract <abbr title="Accessible Rich Internet Applicatiaon">WAI-ARIA</abbr> roles. Case-sensitivity of the comparison inherits from the case-sensitivity of the host language.</li>
<li>Use the first such substring in textual order that matches the name of a non-abstract <abbr title="Accessible Rich Internet Applicatiaon">WAI-ARIA</abbr> role for the <abbr title="application programming interface">API</abbr> role mapping. See the <a href="#mapping_role_table">Role Mapping Table</a> below for details.</li>
</ol>
</li>
<li>User agents MUST NOT map roles defined in the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> specification as "abstract" via the standard role mechanism of the accessibility <abbr title="application programming interface">API</abbr>. Use the fallback procedure specified in the next rule if only an abstract role is provided. The abstract roles are:
<ul>
<li><a class="role-reference" href="#command"><code>command</code></a></li>
<li><a class="role-reference" href="#composite"><code>composite</code></a></li>
<li><a class="role-reference" href="#input"><code>input</code></a></li>
<li><a class="role-reference" href="#landmark"><code>landmark</code></a></li>
<li><a class="role-reference" href="#range"><code>range</code></a></li>
<li><a class="role-reference" href="#roletype"><code>roletype</code></a></li>
<li><a class="role-reference" href="#section"><code>section</code></a></li>
<li><a class="role-reference" href="#sectionhead"><code>sectionhead</code></a></li>
<li><a class="role-reference" href="#select"><code>select</code></a></li>
<li><a class="role-reference" href="#structure"><code>structure</code></a></li>
<li><a class="role-reference" href="#widget"><code>widget</code></a></li>
<li><a class="role-reference" href="#window"><code>window</code></a></li>
</ul>
</li>
<li>If the element does not have a role attribute, or if the role attribute contains no tokens matching the name of a non-abstract <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role, the user agent MUST fall back on normal processing of the base markup for the element. For example, for <samp><table role="foo"></samp> use the <abbr title="Hypertext Markup Language">HTML</abbr> <code>table</code> element to determine the platform accessibility <abbr title="application programming interface">API</abbr> role mapping. For <samp><input type="text" role="bar"></samp>, use the mapping for an <abbr title="Hypertext Markup Language">HTML</abbr> <code>text input</code>.</li>
<li>When an explicit or inherited role of <code>none</code> or <code>presentation</code> is applied to an element, the user agent MUST implement the rules for the <a class="role-reference" href="#none"><code>none</code></a> or the <a class="role-reference" href="#presentation"><code>presentation</code></a> <a class="termref">role</a> defined in <cite><a class="specref" href="">Accessible Rich Internet Applications (WAI-ARIA) 1.0</a></cite> [[!WAI-ARIA]]. </li>
<li id="exposeRoleString">User agents MUST expose the <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role string if the <abbr title="application programming interface">API</abbr> supports a mechanism to do so. This allows assistive technologies to do their own additional processing of roles.
<ul>
<li>
<abbr title="Microsoft Active Accessibility">MSAA</abbr>: <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/dd373608(v=vs.85).aspx" title="Object Roles (Windows)">not supported</a>. User agents SHOULD NOT expose a custom role in MSAA's <code>accRole</code> property.</li>
<li>IAccessible2: expose as an object attribute pair (<code>xml-roles:"string"</code>)</li>
<li><abbr title="User Interface Automation">UIA</abbr>: expose as <code>AriaRole</code> property. The <code>AriaRole property</code> can also support secondary roles using a space as a separator.</li>
<li><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr>: expose as an object attribute pair (<code>xml-roles:"string"</code>)</li>
</ul>
</li>
<li>Platform accessibility <abbr title="application programming interfaces">APIs</abbr> typically do not provide a vehicle to notify assistive technologies that a role has changed. Due to this and document caching, assistive technologies are unlikely to process a change in role attribute value. Authors who wish to change a role are advised by the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> specification to delete the associated element and its children and replace it with a new element having the appropriate role. If a role is changed, however, user agents SHOULD update the mapping in order to reflect the content in the <abbr title="Document Object Model">DOM</abbr>. Since assistive technologies will not know that the role has changed, user agents MAY address this error condition by treating it as removing a subtree item and inserting a new one as described in <a href="#mapping_events_visibility">Changes to document content or node visibility</a>.</li>
</ol>
</section>
<section id="mapping_role_table">
<h3>Role Mapping Table</h3>
<p class="ednote">Translators: For label text associated with the following table and its toggle buttons, see the <code>mappingTableLabels</code> object in the <code><head></code> section of this document.</p>
<div class="table-container">
<table class="map-table elements" id="role-mapping-table">
<caption>Table describing mapping of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles to accessibility <abbr title="application programming interfaces">APIs</abbr>.</caption>
<thead>
<tr>
<th><abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role</th>
<th>MSAA + IAccessible2 Role + Other IAccessible2 Features</th>
<th><abbr title="User Interface Automation">UIA</abbr> Control Type + Other Features</th>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr> Role</th>
<th><abbr title="Mac OS X Accessibility Protocol">AXAPI</abbr><sup>[<a href="#ftn.note1">Note 1</a>]</sup></th>
</tr>
</thead>
<tbody>
<tr id="role-map-alert">
<th><a class="role-reference" href="#alert"><code>alert</code></a></th>
<td><code>ROLE_SYSTEM_ALERT</code><br />
<p>The user agent SHOULD fire <code>EVENT_SYSTEM_ALERT</code> <sup>[<a href="#ftn.note2">Note 2</a>]</sup></p></td>
<td><code>Text</code><br />
<p>The user agent SHOULD fire a system alert <a class="termref">event</a>.<sup>[<a href="#ftn.note2">Note 2</a>]</sup></p></td>
<td><code>ROLE_ALERT</code><br />
<p>The user agent SHOULD fire a system alert event.<sup>[<a href="#ftn.note2">Note 2</a>]</sup></p></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXApplicationAlert</code><br />
AXRoleDescription: <code>'alert'</code>
<p>The user agent SHOULD fire a system alert event.<sup>[<a href="#ftn.note2">Note 2</a>]</sup></p></td>
</tr>
<tr id="role-map-alertdialog">
<th><a class="role-reference" href="#alertdialog"><code>alertdialog</code></a></th>
<td><code>ROLE_SYSTEM_DIALOG</code><br />
<p>The user agent SHOULD fire <code>EVENT_SYSTEM_ALERT</code> <sup>[<a href="#ftn.note2">Note 2</a>]</sup></p></td>
<td><code>Pane</code><br />
<p>The user agent SHOULD fire a system alert event.<sup>[<a href="#ftn.note2">Note 2</a>]</sup></p></td>
<td><code>ROLE_DIALOG</code><br />
<p>The user agent SHOULD fire a system alert event.<sup>[<a href="#ftn.note2">Note 2</a>]</sup></p></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXApplictionAlertDialog</code><br />
AXRoleDescription: <code> 'alert dialog'</code>
<p>The user agent SHOULD fire a system alert event.<sup>[<a href="#ftn.note2">Note 2</a>]</sup></p></td>
</tr>
<tr id="role-map-application">
<th><a class="role-reference" href="#application"><code>application</code></a></th>
<td><code>ROLE_SYSTEM_APPLICATION</code></td>
<td>
<ul>
<li>Control type/role is <code>Pane</code>.</li>
<li>Localized Control Type is <code>application</code>.</li>
</ul>
</td>
<td><code>ROLE_EMBEDDED</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXLandmarkApplication</code><br />
AXRoleDescription: <code>'application'</code></td>
</tr>
<tr id="role-map-article">
<th><a class="role-reference" href="#article"><code>article</code></a></th>
<td><code>ROLE_SYSTEM_DOCUMENT</code> + <code>STATE_SYSTEM_READONLY</code>
<p>IAccessible2: Object attribute <code>xml-roles:article</code> </p></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>article</code>.</li>
</ul>
</td>
<td><code>ROLE_ARTICLE</code> + do not expose <code>STATE_EDITABLE</code>
<p>Object attribute <code>xml-roles:article</code> </p></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXDocumentArticle</code><br />
AXRoleDescription: <code>'article'</code></td>
</tr>
<tr id="role-map-banner">
<th><a class="role-reference" href="#banner"><code>banner</code></a></th>
<td>IAccessible2: Object attribute <code>xml-roles:banner</code></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>banner</code>.</li>
</ul>
</td>
<td><code>ROLE_LANDMARK</code> and object attribute <code>xml-roles:banner</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXLandmarkBanner</code><br />
AXRoleDescription: <code>'banner'</code></td>
</tr>
<tr id="role-map-button">
<th><a class="role-reference" href="#button"><code>button</code></a></th>
<td><code>ROLE_SYSTEM_PUSHBUTTON</code>
<p>If <a class="property-reference" href="#aria-haspopup"><code>aria-haspopup</code></a><code>="true"</code>, expose as <code>ROLE_SYSTEM_BUTTONMENU</code></p>
IAccessible2: If <a class="state-reference" href="#aria-pressed"><code>aria-pressed</code></a> is not <strong>undefined</strong>, expose as <code>IA2_ROLE_TOGGLE_BUTTON</code></td>
<td><code>Button</code></td>
<td><code>ROLE_PUSH_BUTTON</code>
<p>If <a class="state-reference" href="#aria-pressed"><code>aria-pressed</code></a> is not <strong>undefined</strong>, expose as <code>ROLE_TOGGLE_BUTTON</code></p></td>
<td><p>If <a class="property-reference" href="#aria-pressed"><code>aria-pressed</code></a> is defined (true/false/mixed) use:</p>
AXRole: <code>AXCheckBox</code><br />
AXSubrole: <code>AXToggleButton</code><br />
AXRoleDescription: <code>'toggle button'</code>
<p>If <a class="property-reference" href="#aria-pressed"><code>aria-pressed</code></a> is not defined use:</p>
AXRole: <code>AXButton</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'button'</code>
</td>
</tr>
<tr id="role-map-cell">
<th><a class="role-reference" href="#cell"><code>cell</code></a> [ARIA 1.1]</th>
<td><code>ROLE_SYSTEM_CELL</code>.
<p>IAccessible2: Use <code>IAccessibleTableCell</code> interface.</p>
</td>
<td>
<ul>
<li>Control type/role is <code>TableItem</code>.</li>
<li>Supports the <code>selection</code> pattern.</li>
<li>MUST NOT support the <code>invoke</code> pattern.</li>
</ul>
</td>
<td><code>ROLE_TABLE_CELL</code>.
<p>Use <code>TableCell</code> interface.</p>
</td>
<td>AXRole: <code>AXCell</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'cell'</code></td>
</tr>
<tr id="role-map-checkbox">
<th><a class="role-reference" href="#checkbox"><code>checkbox</code></a></th>
<td><code>ROLE_SYSTEM_CHECKBUTTON</code>
<p>IAccessible2: Object attribute <code>checkable:true</code></p></td>
<td><code>Checkbox</code></td>
<td><code>ROLE_CHECK_BOX</code> + <code>STATE_CHECKABLE</code></td>
<td>AXRole: <code>AXCheckBox</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'check box'</code></td>
</tr>
<tr id="role-map-columnheader">
<th><a class="role-reference" href="#columnheader"><code>columnheader</code></a></th>
<td><code>ROLE_SYSTEM_COLUMNHEADER</code>
<p>IAccessible2: Used to help support <a href="http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_table2.html"><code>AccessibleTable</code></a> for the container <a class="role-reference" href="#grid"><code>grid</code></a> role</p></td>
<td><code>HeaderItem</code></td>
<td><code>ROLE_COLUMN_HEADER</code></td>
<td>AXRole: <code>AXCell</code> or <code>AXSortButton</code> if using <code>aria-sort</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'cell</code>'
<p>Parent table also implements <code>AXColumnHeaderUIElements</code> property that is a list of pointers to the column header cells.</p>
<p>Parent table also implements <code>AXHeader</code> property that is a pointer to the row or group containing the columnheader cells.</p></td>
</tr>
<tr id="role-map-combobox">
<th><a class="role-reference" href="#combobox"><code>combobox</code></a></th>
<td><code>ROLE_SYSTEM_COMBOBOX</code> + <code>STATE_SYSTEM_HASPOPUP</code>.
<p>If <a class="state-reference" href="#aria-expanded"><code>aria-expanded</code></a> is not <code>"true"</code>, expose <code>STATE_SYSTEM_COLLAPSED</code>.</p></td>
<td><code>Combobox</code></td>
<td><code>ROLE_COMBO_BOX</code> + <code>STATE_EXPANDABLE</code> + <code>STATE_HAS_POPUP</code></td>
<td>AXRole: <code>AXComboBox</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'combo box'</code></td>
</tr>
<tr id="role-map-complementary">
<th><a class="role-reference" href="#complementary"><code>complementary</code></a></th>
<td>IAccessible2: Object attribute <code>xml-roles:complementary</code></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>complementary</code>.</li>
</ul>
</td>
<td><code>ROLE_LANDMARK</code> and object attribute <code>xml-roles:</code><code>complementary</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXLandmarkComplementary</code><br />
AXRoleDescription: <code>'complementary'</code></td>
</tr>
<tr id="role-map-contentinfo">
<th><a class="role-reference" href="#contentinfo"><code>contentinfo</code></a></th>
<td>IAccessible2: Object attribute <code>xml-roles:contentinfo</code></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>content information</code>.</li>
</ul>
</td>
<td><code>ROLE_LANDMARK</code> and object attribute <code>xml-roles:</code><code>contentinfo</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXLandmarkContentInfo</code><br />
AXRoleDescription: <code>'content'</code></td>
</tr>
<tr id="role-map-definition">
<th><a class="role-reference" href="#definition"><code>definition</code></a></th>
<td>IAccessible2: Object attribute <code>xml-roles:definition</code></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>definition</code>.</li>
</ul>
</td>
<td>Object attribute <code>xml-roles:definition</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXDefinition</code><br />
AXRoleDescription: <code>'definition'</code></td>
</tr>
<tr id="role-map-dialog">
<th><a class="role-reference" href="#dialog"><code>dialog</code></a></th>
<td><code>ROLE_SYSTEM_DIALOG</code></td>
<td><code>Pane</code></td>
<td><code>ROLE_DIALOG</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXApplicationDialog</code><br />
AXRoleDescription: <code>'dialog'</code></td>
</tr>
<tr id="role-map-directory">
<th><a class="role-reference" href="#directory"><code>directory</code></a></th>
<td><code>ROLE_SYSTEM_LIST</code></td>
<td><code>List</code></td>
<td><code>ROLE_LIST</code></td>
<td>AXRole: <code>AXList</code><br />
AXSubrole: <code>AXContentList</code><br />
AXRoleDescription: <code>'content list'</code></td>
</tr>
<tr id="role-map-document">
<th><a class="role-reference" href="#document"><code>document</code></a></th>
<td><code>ROLE_SYSTEM_DOCUMENT</code> + <code>STATE_SYSTEM_READONLY</code></td>
<td><code>Document</code></td>
<td><code>ROLE_DOCUMENT_FRAME</code> + do not expose <code>STATE_EDITABLE</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXDocument</code><br />
AXRoleDescription: <code>'document'</code></td>
</tr>
<tr id="role-map-form">
<th><a class="role-reference" href="#form"><code>form</code></a></th>
<td><code>IAccessible2: IA2_ROLE_FORM</code></td>
<td>Expose as text string in <code>AriaRole</code></td>
<td><code>ROLE_FORM</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'group'</code></td>
</tr>
<tr id="role-map-grid">
<th><a class="role-reference" href="#grid"><code>grid</code></a></th>
<td><code>ROLE_SYSTEM_TABLE</code> + object attribute <code>xml-roles:grid</code>.
<p>IAccessible2: Use <code>IAccessibleTable2</code> interface.</p></td>
<td><code>DataGrid</code> with <code>selection</code> pattern.</td>
<td><code>ROLE_TABLE</code> + object attribute <code>xml-roles:grid</code>.
<p>Use <code>table</code> interface.</p>
</td>
<td>AXRole: <code>AXTable</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'grid'</code></td>
</tr>
<tr id="role-map-gridcell">
<th><a class="role-reference" href="#gridcell"><code>gridcell</code></a></th>
<td><code>ROLE_SYSTEM_CELL</code>
<p>IAccessible2: Use <code>IAccessibleTableCell</code> interface.</p>
</td>
<td><code>DataItem</code>
<p>Also requires <code>selectionitem</code> pattern; <code>selectionContainer</code> property must reference the parent <code>grid</code> object</p></td>
<td><code>ROLE_TABLE_CELL</code>
<p>Use <code>TableCell</code> interface.</p>
</td>
<td>AXRole: <code>AXCell</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'cell'</code></td>
</tr>
<tr id="role-map-group">
<th><a class="role-reference" href="#group"><code>group</code></a></th>
<td><code>ROLE_SYSTEM_GROUPING</code></td>
<td><code>Group</code></td>
<td><code>ROLE_PANEL</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'group'</code></td>
</tr>
<tr id="role-map-heading">
<th><a class="role-reference" href="#heading"><code>heading</code></a>
<span class="el-context">– The heading level is specified by the <a href="#ariaLevel"><code>aria-level</code></a> property.</span></th>
<td>Expose as object attribute <code>xml-roles:heading</code>.<p>Also, expose <code>IAccessible2: IA2_ROLE_HEADING</code></p></td>
<td><code>Text</code></td>
<td><code>ROLE_HEADING</code></td>
<td>AXRole: <code>AXHeading</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'heading'</code></td>
</tr>
<tr id="role-map-img">
<th><a class="role-reference" href="#img"><code>img</code></a></th>
<td><code>ROLE_SYSTEM_GRAPHIC</code></td>
<td><code>Image</code></td>
<td><code>ROLE_IMAGE</code></td>
<td>AXRole: <code>AXImage</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'image'</code></td>
</tr>
<tr id="role-map-link">
<th><a class="role-reference" href="#link"><code>link</code></a></th>
<td><code>ROLE_SYSTEM_LINK</code> + <code>STATE_LINKED</code>
<p>Also, expose <code>STATE_LINKED</code> on all descendants</p>
IAccessible2: Use <code>AccessibleHypertext</code> interface</td>
<td><code>HyperLink</code></td>
<td><code>ROLE_LINK</code></td>
<td>AXRole: <code>AXLink</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'link'</code></td>
</tr>
<tr id="role-map-list">
<th><a class="role-reference" href="#list"><code>list</code></a></th>
<td><code>ROLE_SYSTEM_LIST</code> + <code>STATE_SYSTEM_READONLY</code></td>
<td><p><code>List</code></p>
<p>When the <code>list</code> contains <code>listitems</code>, it must implement the <code>selection</code> pattern.</p></td>
<td><code>ROLE_LIST</code> + do not expose <code>STATE_EDITABLE</code></td>
<td>AXRole: <code>AXList</code><br />
AXSubrole: <code>AXContentList</code><br />
AXRoleDescription: <code>'content list'</code></td>
</tr>
<tr id="role-map-listbox">
<th><a class="role-reference" href="#listbox"><code>listbox</code></a></th>
<td><code>ROLE_SYSTEM_LIST</code></td>
<td><code>List</code></td>
<td><code>ROLE_LIST_BOX</code>.
<p>Special case: if a <a class="role-reference" href="#listbox"><code>listbox</code></a> has a parent or is owned by (via <a class="property-reference" href="#aria-owns"><code>aria-owns</code></a>) a <a class="role-reference" href="#combobox"><code>combobox</code></a>, expose as <code>ROLE_MENU</code>. </p></td>
<td>AXRole: <code>AXList</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'list'</code></td>
</tr>
<tr id="role-map-listitem">
<th><a class="role-reference" href="#listitem"><code>listitem</code></a></th>
<td><code>ROLE_SYSTEM_LISTITEM</code> + <code>STATE_SYSTEM_READONLY</code></td>
<td><p><code>ListItem</code></p>
<p>Also requires <code>selectionitem</code> pattern; <code>selectionContainer</code> property must reference the parent <code>list</code> object</p></td>
<td><code>ROLE_LISTITEM</code> + do not expose <code>STATE_EDITABLE</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'group'</code></td>
</tr>
<tr id="role-map-log">
<th><a class="role-reference" href="#log"><code>log</code></a></th>
<td>IAccessible2: object attributes <code>xml-roles:log</code><code>;container-live:polite;live:polite;container-live-role:log</code>. </td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>log</code>.</li>
<li><code>LiveSettingProperty = Polite (1)</code>.</li>
</ul>
</td>
<td><code>ROLE_LOG</code> and object attributes <code>xml-roles:log;container-live:polite;live:polite;container-live-role:log</code>. </td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXApplicationLog</code><br />
AXRoleDescription: <code>'log'</code></td>
</tr>
<tr id="role-map-main">
<th><a class="role-reference" href="#main"><code>main</code></a></th>
<td>IAccessible2: Object attribute <code>xml-roles:main</code></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>main</code>.</li>
<li>Landmark Type is <code>Main</code>.</li>
<li>Localized Landmark Type is <code>main</code>.</li>
</ul>
</td>
<td><code>ROLE_LANDMARK</code> and object attribute <code>xml-roles:main</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXLandmarkMain</code><br />
AXRoleDescription: <code>'main'</code></td>
</tr>
<tr id="role-map-marquee">
<th><a class="role-reference" href="#marquee"><code>marquee</code></a></th>
<td><code>ROLE_SYSTEM_ANIMATION</code> + IAccessible2: object attribute <code>xml-roles:marquee;container-live:off;live:off</code></td>
<td><code>Text</code></td>
<td><code>ROLE_MARQUEE</code> + object attributes <code>container-live:off;live:off</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXApplicationMarquee</code><br />
AXRoleDescription: <code>'marquee'</code></td>
</tr>
<tr id="role-map-math">
<th><a class="role-reference" href="#math"><code>math</code></a></th>
<td><code>ROLE_SYSTEM_EQUATION</code></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>math</code>.</li>
</ul>
</td>
<td><code>ROLE_MATH</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXDocumentMath</code><br />
AXRoleDescription: <code>'math'</code></td>
</tr>
<tr id="role-map-menu">
<th><a class="role-reference" href="#menu"><code>menu</code></a></th>
<td><code>ROLE_SYSTEM_MENUPOPUP</code></td>
<td><code>Menu</code></td>
<td><code>ROLE_MENU</code>
<p>These <a class="termref">objects</a> are not exposed for a submenu if there is a parent menu item spawning the submenu. Since <abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr> allows menuitems to have menuitem children, interposing menu objects are not exposed, except for the root parent. </p></td>
<td>AXRole: <code>AXMenu</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'menu'</code></td>
</tr>
<tr id="role-map-menubar">
<th><a class="role-reference" href="#menubar"><code>menubar</code></a></th>
<td><code>ROLE_SYSTEM_MENUBAR</code></td>
<td><code>MenuBar</code></td>
<td><code>ROLE_MENU_BAR</code></td>
<td>AXRole: <code>AXMenuBar</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'menu bar'</code></td>
</tr>
<tr id="role-map-menuitem">
<th><a class="role-reference" href="#menuitem"><code>menuitem</code></a></th>
<td><code>ROLE_SYSTEM_MENUITEM</code></td>
<td><code>MenuItem</code></td>
<td><code>ROLE_MENU_ITEM</code></td>
<td>If the option's parent has a <a class="role-reference" href="#group"><code>group</code></a> role, then <code>role="menuitem"</code> maps to <code>AXMenuButton</code>
<p>If the option's parent has a <a class="role-reference" href="#menu"><code>menu</code></a> role, then <code>role="menuitem"</code> maps to <code>AXMenuItem</code></p>
<p>AXRole: <code>AXMenuItem</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'menu item</code>'</p></td>
</tr>
<tr id="role-map-menuitemcheckbox">
<th><a class="role-reference" href="#menuitemcheckbox"><code>menuitemcheckbox</code></a></th>
<td><code>ROLE_SYSTEM_CHECKBUTTON</code> or <code>ROLE_SYSTEM_MENUITEM</code>
<p><code>IAccessible2: IA2_ROLE_CHECK_MENU_ITEM</code> + object attribute <code>checkable:true</code></p></td>
<td><code>MenuItem</code> + <code>Toggle</code> Pattern</td>
<td><code>ROLE_CHECK_MENU_ITEM</code> + <code>STATE_CHECKABLE</code></td>
<td>AXRole: <code>AXMenuItem</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'menu item</code>'
<p>If <a class="state-reference" href="#aria-checked"><code>aria-checked</code></a>><code>="true"</code>: <code>AXMenuItemMarkChar</code> ✓<br />
Otherwise: <code>AXMenuItemMarkChar</code> <code><nil></code></p></td>
</tr>
<tr id="role-map-menuitemradio">
<th><a class="role-reference" href="#menuitemradio"><code>menuitemradio</code></a></th>
<td><code>ROLE_SYSTEM_RADIOBUTTON</code> or <code>ROLE_SYSTEM_MENUITEM</code>
<p><code>IAccessible2: IA2_ROLE_RADIO_MENU_ITEM</code> + object attribute <code>checkable:true</code></p></td>
<td><code>MenuItem</code></td>
<td><code>ROLE_RADIO_MENU_ITEM</code> + <code>STATE_CHECKABLE</code></td>
<td>AXRole: <code>AXMenuItem</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'menu item</code>'
<p>If <a class="state-reference" href="#aria-checked"><code>aria-checked</code></a><code>="true"</code>: <code>AXMenuItemMarkChar</code> ✓.<br />
Otherwise: <code>AXMenuItemMarkChar</code> <code><nil></code></p></td>
</tr>
<tr id="role-map-navigation">
<th><a class="role-reference" href="#navigation"><code>navigation</code></a></th>
<td>IAccessible2: Object attribute <code>xml-roles:navigation</code></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>navigation</code>.</li>
</ul>
</td>
<td><code>ROLE_LANDMARK</code> and object attribute <code>xml-roles:navigation</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXLandmarkNavigation</code><br />
AXRoleDescription: <code>'navigation'</code></td>
</tr>
<tr id="role-map-none">
<th><a class="role-reference" href="#none"><code>none</code></a> [ARIA 1.1]</th>
<td>
<p>If the object is in the <a class="termref">accessibility tree</a>, expose as <code>IA2_ROLE_TEXTFRAME</code>.</p>
<p>For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the <a class="termref">accessibility tree</a>, expose it as <code>IA2_ROLE_TEXTFRAME</code>. <a class="termref">User agents</a> SHOULD prune empty descendants from the <a class="termref">accessibility tree</a>. </p>
<p>See <a href="#mapping_general">General rules for exposing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics</a>.</p></td>
<td>
<p>If the object is in the <a class="termref">accessibility tree</a>, expose using the <code>text</code> pattern.</p>
<p>For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the <a class="termref">accessibility tree</a>, expose it using the <code>text</code> pattern. <a class="termref">User agents</a> SHOULD prune empty descendants from the <a class="termref">accessibility tree</a>. </p>
<p>See <a href="#mapping_general">General rules for exposing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics</a>.</p></td>
<td>
<p>If the object is in the <a class="termref">accessibility tree</a>, expose as <code>ROLE_SECTION</code>.</p>
<p>For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the <a class="termref">accessibility tree</a>, expose it as <code>ROLE_SECTION</code>. <a class="termref">User agents</a> SHOULD prune empty descendants from the <a class="termref">accessibility tree</a>. </p>
<p>See <a href="#mapping_general">General rules for exposing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics</a>.</p></td>
<td><p>Not mapped.</p>
<p>See <a href="#mapping_general">General rules for exposing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics</a>.</p></td>
</tr>
<tr id="role-map-note">
<th><a class="role-reference" href="#note"><code>note</code></a></th>
<td><code>IAccessible2: IA2_ROLE_NOTE</code></td>
<td>
<ul>
<li>Control type/role is <code>Group</code>.</li>
<li>Localized Control Type is <code>note</code>.</li>
</ul>
</td>
<td><code>ROLE_COMMENT</code></td>
<td>AXRole: <code>AXGroup</code><br />
AXSubrole: <code>AXDocumentNote</code><br />
AXRoleDescription: <code>'note'</code></td>
</tr>
<tr id="role-map-option">
<th><a class="role-reference" href="#option"><code>option</code></a>
<span class="el-context">– If <a class="state-reference" href="#aria-selected"><code>aria-selected</code></a> is undefined treat as <code>aria-selected = "false"</code>.</span></th>
<td><code>ROLE_SYSTEM_LISTITEM</code>
<p>IAccessible2: If <a class="state-reference" href="#aria-checked"><code>aria-checked</code></a> is not <strong>undefined</strong>, support object attribute <code>checkable:true</code></p></td>
<td><code>ListItem</code> + <code>Invoke</code> pattern </td>
<td><code>ROLE_LIST_ITEM</code>
<p>If <a class="state-reference" href="#aria-checked"><code>aria-checked</code></a> is not <strong>undefined</strong>, support <code>STATE_CHECKABLE</code></p>
<p>Special case: if an <a class="role-reference" href="#option"><code>option</code></a> has a parent that was exposed as a <code>ROLE_MENU</code>, the <a class="role-reference" href="#option"><code>option</code></a> is exposed as an <code>ROLE_MENU_ITEM</code>. </p></td>
<td><!-- If the option's parent has a <a class="role-reference" href="#menu"><code>menu</code></a> role, then <code>role="option"</code> maps to <code>AXMenuItem</code> -->
<!--<p> If the option's parent has a <a class="role-reference" href="#listbox"><code>listbox</code></a> role, then <code>role="option"</code> maps to <code>AXStaticText</code></p> -->
AXRole: <code>AXStaticText</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'text'</code></td>
</tr>
<tr id="role-map-presentation">
<th><a class="role-reference" href="#presentation"><code>presentation</code></a></th>
<td>
<p>If the object is in the <a class="termref">accessibility tree</a>, expose as <code>IA2_ROLE_TEXTFRAME</code>.</p>
<p>For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the <a class="termref">accessibility tree</a>, expose it as <code>IA2_ROLE_TEXTFRAME</code>. <a class="termref">User agents</a> SHOULD prune empty descendants from the <a class="termref">accessibility tree</a>. </p>
<p>See <a href="#mapping_general">General rules for exposing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics</a>.</p></td>
<td>
<p>If the object is in the <a class="termref">accessibility tree</a>, expose using the <code>text</code> pattern.</p>
<p>For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the <a class="termref">accessibility tree</a>, expose it using the <code>text</code> pattern. <a class="termref">User agents</a> SHOULD prune empty descendants from the <a class="termref">accessibility tree</a>. </p>
<p>See <a href="#mapping_general">General rules for exposing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics</a>.</p></td>
<td>
<p>If the object is in the <a class="termref">accessibility tree</a>, expose as <code>ROLE_SECTION</code>.</p>
<p>For objects that have required owned descendants (e.g., a grid owns gridcells, a list owns listitems), and the descendant is in the <a class="termref">accessibility tree</a>, expose it as <code>ROLE_SECTION</code>. <a class="termref">User agents</a> SHOULD prune empty descendants from the <a class="termref">accessibility tree</a>. </p>
<p>See <a href="#mapping_general">General rules for exposing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics</a>.</p></td>
<td><p>Not mapped.</p>
<p>See <a href="#mapping_general">General rules for exposing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics</a>.</p></td>
</tr>
<tr id="role-map-progressbar">
<th><a class="role-reference" href="#progressbar"><code>progressbar</code></a></th>
<td><code>ROLE_SYSTEM_PROGRESSBAR</code> + <code>STATE_SYSTEM_READONLY</code></td>
<td><p><code>ProgressBar</code></p>
<p>If any of the <code>aria-valuenow</code>, <code>aria-valuemax</code>, or <code>aria-valuemin</code> properties are present, also implement the <code>RangeValue</code> pattern.</p></td>
<td><code>ROLE_PROGRESS_BAR</code> + do not expose <code>STATE_EDITABLE</code></td>
<td>AXRole: <code>AXProgressIndicator</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'progress indicator'</code></td>
</tr>
<tr id="role-map-radio">
<th><a class="role-reference" href="#radio"><code>radio</code></a></th>
<td><code>ROLE_SYSTEM_RADIOBUTTON</code></td>
<td><code>RadioButton</code></td>
<td><code>ROLE_RADIO_BUTTON</code></td>
<td>AXRole: <code>AXRadioButton</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'radio button'</code></td>
</tr>
<tr id="role-map-radiogroup">
<th><a class="role-reference" href="#radiogroup"><code>radiogroup</code></a></th>
<td><code>ROLE_SYSTEM_GROUPING</code></td>
<td><code>List</code></td>
<td><code>ROLE_GROUPING</code></td>
<td>AXRole: <code>AXRadioGroup</code><br />
AXSubrole: <code><nil></code><br />
AXRoleDescription: <code>'radio group'</code></td>
</tr>