-
Notifications
You must be signed in to change notification settings - Fork 126
/
Copy pathindex.html
11306 lines (11284 loc) · 540 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
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.2</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove"></script>
<script src="../common/script/resolveReferences.js" class="remove"></script>
<script src="../common/script/utility.js" class="remove"></script>
<script src="../common/biblio.js" class="remove" defer></script>
<script src="../common/script/participants.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" />
<script class="remove">
var respecConfig = {
github: "w3c/core-aam",
doJsonLd: true,
lint: true,
// specification status (e.g., WD, LC, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
crEnd: "2023-01-02",
implementationReportURI: "https://w3c.github.io/test-results/core-aam-1.2/",
//perEnd: "2013-07-23",
//publishDate: "2013-08-22",
// the specifications short name, as in http://www.w3.org/TR/short-name/
shortName: "core-aam-1.2",
// 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: "CR",
prevRecURI: "https://www.w3.org/TR/core-aam-1.1/",
//previousDiffURI: "http://www.w3.org/TR/2014/REC-wai-aria-implementation-20140320/",
// if there a publicly available Editors Draft, this is the link
edDraftURI: "https://w3c.github.io/core-aam/",
// 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: "Valerie Young",
company: "Igalia, S.L.",
companyURL: "https://www.igalia.com",
w3cid: 107953,
},
{
name: "Alexander Surkov",
company: "Igalia, S.L.",
companyURL: "https://www.igalia.com",
w3cid: 51089,
},
],
formerEditors: [
{ name: "Joanmarie Diggs", company: "Igalia, S.L.", companyURL: "https://www.igalia.com", w3cid: 68182, note: "Editor until October 2022" },
{ name: "Richard Schwerdtfeger", company: "Knowbility", companyURL: "https://www.knowbility.org/", w3cid: 2460, note: "Editor until October 2017" },
{ name: "Joseph Scheuhammer", company: "Inclusive Design Research Centre, OCAD University", companyURL: "http://idrc.ocad.ca", w3cid: 42279, note: "Editor until May 2017" },
{ name: "Andi Snow-Weaver", company: "IBM", companyURL: "http://www.ibm.com", w3cid: 35445, note: "Editor until December 2012" },
{ name: "Aaron Leventhal", company: "IBM", companyURL: "http://www.ibm.com", w3cid: 34329, note: "Editor until January 2009" },
{ name: "Michael Cooper", company: "W3C", companyURL: "https://www.w3.org", w3cid: 34017, note: "Editor until July 2023" },
],
// 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: "Benjamin Beaudry",
company: "Microsoft Corp.",
companyURL: "https://microsoft.com/",
note: "UIA",
w3cid: 40117,
},
{
name: "James Craig",
company: "Apple, Inc.",
companyURL: "https://apple.com/accessibility",
note: "AX API",
w3cid: 42459,
},
{ name: "Joanmarie Diggs", company: "Igalia, S.L.", companyURL: "https://www.igalia.com", w3cid: 68182, note: "ATK / AT-SPI" },
{
name: "Alexander Surkov",
company: "Igalia, S.L.",
companyURL: "https://www.igalia.com",
note: "MSAA, IAccessible2",
w3cid: 51089,
},
],
/*
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
group: "aria",
tocIntroductory: true,
//maxTocLevel: 4,
// Spec URLs
ariaSpecURLs: {
ED: "https://w3c.github.io/aria/",
FPWD: "https://www.w3.org/TR/wai-aria-1.3/",
WD: "https://www.w3.org/TR/wai-aria-1.3/",
CR: "https://www.w3.org/TR/wai-aria-1.3/",
REC: "https://www.w3.org/TR/wai-aria-1.3/",
},
accNameURLs: {
ED: "https://w3c.github.io/accname/",
WD: "https://www.w3.org/TR/accname-1.2/",
FPWD: "https://www.w3.org/TR/accname-1.2/",
CR: "https://www.w3.org/TR/accname-1.2/",
REC: "https://www.w3.org/TR/accname-1.2/",
},
coreMappingURLs: {
ED: "https://w3c.github.io/core-aam/",
WD: "https://www.w3.org/TR/core-aam-1.2/",
FPWD: "https://www.w3.org/TR/core-aam-1.2/",
CR: "https://www.w3.org/TR/core-aam-1.2/",
REC: "https://www.w3.org/TR/core-aam-1.2/",
},
dpubModURLs: {
ED: "https://w3c.github.io/dpub-aria/",
FPWD: "https://www.w3.org/TR/dpub-aria-1.1/",
WD: "https://www.w3.org/TR/dpub-aria-1.1/",
REC: "https://www.w3.org/TR/dpub-aria-1.1/",
},
graphicsMappingModURLs: {
ED: "https://w3c.github.io/graphics-aam/",
FPWD: "https://www.w3.org/TR/graphics-aam-1.0/",
WD: "https://www.w3.org/TR/graphics-aam-1.0/",
CR: "https://www.w3.org/TR/graphics-aam-1.0/",
PR: "https://www.w3.org/TR/graphics-aam-1.0/",
REC: "https://www.w3.org/TR/graphics-aam-1.0/",
},
graphicsModURLs: {
ED: "https://w3c.github.io/graphics-aria/",
FPWD: "https://www.w3.org/TR/graphics-aria/",
WD: "https://www.w3.org/TR/graphics-aria/",
REC: "https://www.w3.org/TR/graphics-aria/",
},
htmlMappingURLs: {
ED: "https://w3c.github.io/html-aam/",
FPWD: "https://www.w3.org/TR/html-aam-1.0/",
WD: "https://www.w3.org/TR/html-aam/",
REC: "https://www.w3.org/TR/html-aam/",
},
practicesURLs: {
ED: "https://www.w3.org/WAI/ARIA/apg/",
WD: "https://www.w3.org/WAI/ARIA/apg/",
FPWD: "https://www.w3.org/WAI/ARIA/apg/",
CR: "https://www.w3.org/WAI/ARIA/apg/",
REC: "https://www.w3.org/WAI/ARIA/apg/",
},
preProcess: [linkCrossReferences, getParticipants],
postProcess: [addPlatformMaintainers],
xref: ["dom", "accname", "wai-aria", "infra"],
};
</script>
</head>
<body>
<section id="abstract">
<p>
This document describes how [=user agents=] 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 properties provided in Web content via
<cite
><a href="http://www.w3.org/TR/wai-aria-1.2/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></a></cite
>
[[WAI-ARIA-1.2]]. 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 supersede the guidance in the <a href="http://www.w3.org/TR/core-aam-1.1/">Core Accessibility API Mappings 1.1</a> [[CORE-AAM-1.1]] 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">
<p>
The Accessible Rich Internet Applications Working Group seeks feedback on any aspect of the specification. When submitting feedback, please consider issues in the context of the companion
documents. To comment, <a href="https://github.com/w3c/core-aam/issues/new">file an issue in the <abbr title="World Wide Web Consortium">W3C</abbr> core-aam GitHub repository</a>. If this is
not feasible, send email to <a href="mailto:[email protected]?subject=Comment%20on%20Core-AAM%201.2">[email protected]</a> (<a href="http://lists.w3.org/Archives/Public/public-aria/"
>comment archive</a
>). In-progress updates to the document may be viewed in the <a href="http://w3c.github.io/core-aam/">publicly visible editors' draft</a>.
</p>
</section>
<section id="intro" class="informative">
<h2>Introduction</h2>
<p>
The Core Accessibility API Mappings specifies how <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a class="termref">roles</a>, <a class="termref">states</a>, and
[=ARIA/properties=] are expected to be exposed by user agents via 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 class="specref" href="">Accessible Rich Internet Applications (WAI-ARIA) 1.2</a></cite> [[WAI-ARIA-1.2]], a <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-1.2]], 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]], defines the path to make rich web content accessible, including steps already taken, remaining future steps, and a time line.
</li>
</ul>
<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>.
</p>
<section id="intro_aapi">
<h3>Accessibility <abbr title="Application Programming Interfaces">APIs</abbr></h3>
<p>
<a class="termref">Accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a> make it possible to communicate accessibility information about user interfaces to assistive
technologies. This information includes:
</p>
<ol>
<li>Descriptive properties (role, name, value, position, etc.)</li>
<li>Transient states (pressed, focused, etc.)</li>
<li>Events (text changed, button was clicked, checkbox was toggled)</li>
<li>Actions the user might take (click, check/toggle, drag, etc.)</li>
<li>Relationships (parent/child, description/described object, previous object/next object, etc.)</li>
<li>Textual content</li>
</ol>
<p>Accessibility <abbr title="Application Programming Interfaces">APIs</abbr> covered by this specification are:</p>
<ul>
<li><abbr title="Microsoft Active Accessibility">MSAA</abbr> with <cite>IAccessible2 1.3</cite> [[IAccessible2]]</li>
<li><cite>User Interface Automation</cite> [[UI-AUTOMATION]]</li>
<li><cite>ATK - Accessibility Toolkit</cite> [[ATK]] and <cite>Assistive Technology Service Provider Interface</cite> [[AT-SPI]], referred to hereafter as "ATK/AT-SPI"</li>
<li><cite>macOS Accessibility Protocol</cite> [[AXAPI]]</li>
</ul>
<p>
The <cite><a href="http://www.w3.org/TR/wai-aria-implementation/">WAI-ARIA 1.0 User Agent Implementation Guide</a></cite> included mappings for [[UIA-EXPRESS]], also known as IAccessibleEx,
which was implemented in Microsoft Internet Explorer 8.0 - 11. New implementations are strongly encouraged to use [[[UI-AUTOMATION]]] instead.
</p>
<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>
<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 assistive technologies. The following subsections describe a few of the distinguishing characteristics of some of the APIs.
</p>
<section>
<h5>ATK/AT-SPI</h5>
<p>
MSAA, IAccessible2, UIA, and AX API each define an API that is shared by both the software application exposing information about its content and interactive components, and the 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, combobox, 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, whereas AT-SPI is relevant to consumers. In the context of mapping WAI-ARIA roles, states and properties, user agents are implementors and use ATK.
Assistive Technologies are consumers, and use AT-SPI.
</p>
</section>
<section>
<h5>UIA (UI Automation)</h5>
<p>
UI Automation expresses every element of the application user interface as an automation element. Automation elements form the nodes of the application accessibility tree, that can be
queried, traversed and interacted with by automation clients.
</p>
<p>There are several concepts central to UI Automation:</p>
<ul>
<li>Automation element - controls and some application content are presented as automation elements.</li>
<li>
Element properties - Automation elements have several common properties describing native framework element characteristics in an agnostic way that all automation clients can understand.
There are several ways to access element property values, described below.
</li>
<li>
Control Patterns - Some common interactivity in different frameworks is expressed as control patterns in UIA, allowing different automation clients to interact with controls using common
programmatic interfaces.
</li>
<li>Events - Similar to other accessibility APIs, automation elements support various events that allow automation providers to notify clients on important state changes.</li>
</ul>
<p>
All automation elements inherit from the <code>IUIAutomationElement</code> interface and all properties that are not specific to a particular control pattern can be queried through that
interface. There are several ways to access UI Automation element properties:
</p>
<ul>
<li>Direct property accessors to the current values - <code>Current{PropertyName}</code>, e.g. <code>IUIAutomationElement::CurrentName</code> for the <code>Name</code> property</li>
<li>
Cached property accessors - <code>Cached{PropertyName}</code>, e.g. <code>IUIAutomationElement::CachedName</code> for the <code>Name</code> property. Using cached values is preferred
when providers and clients are used in remote environments.
</li>
<li>
<code>GetCurrentPropertyValue</code> and passing the UIA Property ID enumeration value corresponding to that property to get the current value, e.g.
<code>IUIAutomationElement::GetCurrentPropertyValue(UIA_NamePropertyId)</code> for the <code>Name</code> property.
</li>
<li>
<code>GetCachedPropertyValue</code> and passing the UIA Property ID enumeration value corresponding to that property to get the cached value, e.g.
<code>IUIAutomationElement::GetCachedPropertyValue(UIA_NamePropertyId)</code> for the <code>Name</code> property.
</li>
</ul>
<p>
Properties for specific UIA control patterns are queried the same way using relevant control pattern interfaces. Taking Toggle Pattern as an example, to query the ToggleState property
clients can use IUIAutomationTogglePattern::CurrentToggleState or IUIAutomationTogglePattern::GetCurrentPropertyValue(UIA_ToggleToggleStatePropertyId) to get the current value.
</p>
<p>
The property mappings in this specification provide the <code>{PropertyName}</code> and do not specify all specific ways to access the property value. Automation clients can access current
or cached values using conventions described above, depending on specific needs and coding style conventions.
</p>
</section>
<section>
<h5>Accessible Names and Descriptions</h5>
<p>
Each platform accessibility API includes a way to assign and retrieve <a class="termref" data-cite="accname-1.2#dfn-accessible-name">accessible name</a> and
<a class="termref" data-cite="accname-1.2#dfn-accessible-description">accessible description</a> properties for each <a class="termref">accessible object</a> created in the
<a class="termref">accessibility tree</a>. How these 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" data-cite="accname-1.2#dfn-accessible-name">accessible name</a>. Where the object also supports having an
<a class="termref" data-cite="accname-1.2#dfn-accessible-description">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. Where the object also supports having an
<a class="termref" data-cite="accname-1.2#dfn-accessible-description">accessible description</a>, UIA stores this property in the object's <code>FullDescription</code> property.
</p>
<p>
The approach to <a class="termref" data-cite="accname-1.2#dfn-accessible-name">accessible names</a> and
<a class="termref" data-lt="accessible description" data-cite="accname-1.2#dfn-accessible-description">accessible descriptions</a> in AX API is somewhat different to the other platform
APIs. <a class="termref" data-cite="accname-1.2#dfn-accessible-name">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" data-cite="accname-1.2#dfn-accessible-description">accessible description</a>, where provided by
<a class="state-reference" href="#aria-description"><code>aria-description</code></a> or <a class="state-reference" href="#aria-describedby"><code>aria-describedby</code></a
>, should be exposed in the <code>accessibilityCustomContent</code> API. Otherwise, it should be exposed as <code>AXHelp</code>.
</p>
<p>For more detail, see the <a class="accname" href="">Accessible Name and Description Computation</a> specification.</p>
</section>
</section>
</section>
<section id="conformance">
<section>
<h3>RFC-2119 Keywords</h3>
<p>
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>
</section>
<section>
<h3>Normative and Informative Sections</h3>
<p>The indication whether a section is normative or non-normative (informative) applies to the entire section including sub-sections.</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>
<h3>Features Deprecated in WAI-ARIA</h3>
<p>
The WAI-ARIA specification <a href="#deprecated" class="specref">lists some features as deprecated</a>. Although this means authors are encouraged not to use such features, it is expected
that the features could still be used in legacy content. Therefore, it is important that user agents continue to map these features to accessibility APIs, and doing so is part of conformance
to this specification. When future versions of the WAI-ARIA specification change such features from deprecated to removed, they will be removed from the mappings as well and user agents will
no longer be asked to continue support for those features.
</p>
</section>
</section>
<section class="informative" id="glossary">
<h2>Important Terms</h2>
<div>
<p>While some terms are defined in place, the following definitions are used throughout this document.</p>
<dl class="termlist">
<dt><dfn data-export="">Accessibility Subtree</dfn></dt>
<dd>
<p>
An [=accessible object=] in the <a>accessibility tree</a> and its descendants in that tree. It does not include objects which have relationships other than parent-child in that tree. For
example, it does not include objects linked via <a class="specref" href="#aria-flowto">aria-flowto</a> unless those objects are also descendants in the <a>accessibility tree</a>.
</p>
</dd>
<dt><dfn data-export="">Activation behavior</dfn></dt>
<dd>
<p>
The action taken when an <a>event</a>, typically initiated by users through an input device, causes an element to fulfill a defined role. The role may be defined for that element by the
host language, or by author-defined variables, or both. The role for any given element may be a generic action, or may be unique to that element. For example, the activation behavior of
an <abbr title="Hypertext Markup Language">HTML</abbr> or <abbr title="Scalable Vector Graphics">SVG</abbr> <code><a></code> element shall be to cause the user agent to traverse
the link specified in the <code>href</code> attribute, with the further optional parameter of specifying the browsing context for the traversal (such as the current window or tab, a
named window, or a new window); the activation behavior of an <abbr title="Hypertext Markup Language">HTML</abbr> <code><input></code> element with the <code>type</code> attribute
value <code>submit</code> shall be to send the values of the form elements to an author-defined <abbr title="Internationalized Resource Identifiers">IRI</abbr> by the author-defined
<abbr title="Hypertext Transfer Protocol">HTTP</abbr> method.
</p>
</dd>
</dl>
</div>
</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>
<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">Accessibility API</a>, [=user agents=] 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 and 1.1, 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 properties) 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 and 1.1 do
not define mechanisms for assistive technologies to directly modify <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> information.
</p>
<p>
The terms "exposing", "mapping", and "including" refer to the creation of <a class="termref">accessible object</a> <a class="termref" data-lt="node">nodes</a> within the
<a class="termref">accessibility tree</a>, and populating these objects with <a class="termref">Accessibility API</a> specific <a class="termref">states</a> and [=ARIA/properties=].
</p>
</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, [=user agents=] 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">accessibility APIs</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", is not correct because it
does not properly communicate the additional features of a spin button. The author adds the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role of
<code>spinbutton</code> (<code><input type="text" role="spinbutton" ...></code>) so that the control is 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. If the host language element is overridden by a
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role whose semantics or structure is not equivalent to the native host language semantics or to a subclass of those
semantics, then treat any child elements having roles specified as Allowed Accessibility Child Roles as having <a href="#role-map-presentation">presentation</a> or
<a href="#role-map-none">none</a>.
</p>
<p class="note">
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">accessibility APIs</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 [=ARIA/properties=] 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, [=user agents=] 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="note">
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">accessibility APIs</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 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.
</p>
<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>
</section>
<section id="roleMappingComputedRole">
<h2>Computed Role</h2>
<p>
The `computedrole` of an element is a string that represents the role of the element as computed by the browser engine. The `computedrole` is used primarily for the purposes of developer
tools and specification comformance and interoperability testing.
</p>
<p class="note">
User agents provide this role string, for example, in developer tools, and in response to the WebDriver function
<a href="https://w3c.github.io/webdriver/#get-computed-role">`getComputedRole`</a>, which is used for
<a href="https://github.com/w3c/aria/blob/main/documentation/tests.md">interoperability testing of ARIA, HTML-AAM, and other specifications</a>.
</p>
<aside class="example">
<!-- ReSpec needs these examples to be unindented. -->
<pre>
<button> <!-- computedrole returns "button" -->
<a href="#" role="button"> <!-- computedrole returns "button" --></pre
>
</aside>
<p>
When an element has a role but is not contained in the required context (for example, an orphaned `listitem` without the required accessible parent of role `list`), User Agents MUST ignore
the role token, and return the `computedrole` as if the ignored role token had not been included.
</p>
<aside class="example">
<!-- ReSpec needs these examples to be unindented. -->
<pre>
<div role="listitem"> <!-- Author error: orphaned listitem. computedrole returns "generic" -->
<div role="list"> <!-- computedrole returns "list" -->
<div role="listitem"> <!-- computedrole returns "listitem" in the required context. --></pre
>
</aside>
<p>
When host language elements do not have an exact or equivalent mapping to a valid, non-abstract role, the related Accessibilty API Mapping extension specification MAY specify a unique
`computedrole` string as the return value for interoperability testing purposes, such as `<video> -> "html-video"` in [[HTML-AAM]]. However, authors MUST NOT use any
host-language-prefixed `computedrole` string in the `role` attribute (such as `html-video`), unless the token also matches valid, defined role (such as `dpub-chapter`). User Agents MUST
ignore any abstract or invalid role token.
</p>
<aside class="example">
<!-- ReSpec needs these examples to be unindented. -->
<pre>
<video> <!-- computedrole returns "html-video" -->
<main role="html-video"> <!-- Author error. computedrole returns "main" --></pre
>
</aside>
</section>
<section id="mapping_role_table">
<h3>Role Mapping Tables</h3>
<h4 id="role-map-alert"><code>alert</code></h4>
<table aria-labelledby="role-map-alert">
<tbody>
<tr>
<th>ARIA Specification</th>
<td>
<a class="role-reference" href="#alert"><code>alert</code></a>
</td>
</tr>
<tr>
<th>Computed Role</th>
<td>
<p><code>alert</code></p>
</td>
</tr>
<tr>
<th>MSAA + IAccessible2</th>
<td>
<span class="property">Role: <code>ROLE_SYSTEM_ALERT</code></span
><br />
<span class="event"
>Event: The user agent SHOULD fire <code>EVENT_SYSTEM_ALERT</code>. <sup>[<a href="#ftn.note2">Note 2</a>]</sup></span
>
</td>
</tr>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Control Type: <code>Group</code></span
><br />
<span class="property">Localized Control Type: <code>alert</code></span
><br />
<span class="property">LiveSetting: <code>Assertive (2)</code></span
><br />
<span class="event"
>Event: The user agent SHOULD fire a system alert <a class="termref">event</a>. <sup>[<a href="#ftn.note2">Note 2</a>]</sup></span
>
</td>
</tr>
<tr>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr></th>
<td>
<span class="property">Role: <code>ROLE_NOTIFICATION</code></span
><br />
<span class="event"
>Event: The user agent SHOULD fire a system alert <a class="termref">event</a>. <sup>[<a href="#ftn.note2">Note 2</a>]</sup></span
>
</td>
</tr>
<tr>
<th>
<abbr title="macOS Accessibility Protocol">AX API</abbr><sup>[<a href="#ftn.note1">Note 1</a>]</sup>
</th>
<td>
<span class="property">AXRole: <code>AXGroup</code></span
><br />
<span class="property">AXSubrole: <code>AXApplicationAlert</code></span
><br />
<span class="event"
>Event: The user agent SHOULD fire a system alert <a class="termref">event</a>. <sup>[<a href="#ftn.note2">Note 2</a>]</sup></span
>
</td>
</tr>
</tbody>
</table>
<h4 id="role-map-alertdialog"><code>alertdialog</code></h4>
<table aria-labelledby="role-map-alertdialog">
<tbody>
<tr>
<th>ARIA Specification</th>
<td>
<a class="role-reference" href="#alertdialog"><code>alertdialog</code></a>
</td>
</tr>
<tr>
<th>Computed Role</th>
<td>
<p><code>alertdialog</code></p>
</td>
</tr>
<tr>
<th>MSAA + IAccessible2</th>
<td>
<span class="property">Role: <code>ROLE_SYSTEM_DIALOG</code></span
><br />
<span class="event"
>Event: The user agent SHOULD fire <code>EVENT_SYSTEM_ALERT</code>. <sup>[<a href="#ftn.note2">Note 2</a>]</sup></span
>
</td>
</tr>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Control Type: <code>Pane</code></span
><br />
<span class="event"
>Event: The user agent SHOULD fire a system alert <a class="termref">event</a>. <sup>[<a href="#ftn.note2">Note 2</a>]</sup></span
>
</td>
</tr>
<tr>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr></th>
<td>
<span class="property">Role: <code>ROLE_ALERT</code></span
><br />
<span class="property">Interface: <code>Window</code></span
><br />
<span class="event"
>Event: The user agent SHOULD fire a system alert <a class="termref">event</a>. <sup>[<a href="#ftn.note2">Note 2</a>]</sup></span
>
</td>
</tr>
<tr>
<th>
<abbr title="macOS Accessibility Protocol">AX API</abbr><sup>[<a href="#ftn.note1">Note 1</a>]</sup>
</th>
<td>
<span class="property">AXRole: <code>AXGroup</code></span
><br />
<span class="property">AXSubrole: <code>AXApplicationAlertDialog</code></span
><br />
<span class="event"
>Event: The user agent SHOULD fire a system alert <a class="termref">event</a>. <sup>[<a href="#ftn.note2">Note 2</a>]</sup></span
>
</td>
</tr>
</tbody>
</table>
<h4 id="role-map-application"><code>application</code></h4>
<table aria-labelledby="role-map-application">
<tbody>
<tr>
<th>ARIA Specification</th>
<td>
<a class="role-reference" href="#application"><code>application</code></a>
</td>
</tr>
<tr>
<th>Computed Role</th>
<td>
<p><code>application</code></p>
</td>
</tr>
<tr>
<th>MSAA + IAccessible2</th>
<td>
<span class="property">Role: <code>ROLE_SYSTEM_APPLICATION</code></span>
</td>
</tr>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Control Type: <code>Pane</code></span
><br />
<span class="property">Localized Control Type: <code>application</code></span>
</td>
</tr>
<tr>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr></th>
<td>
<span class="property">Role: <code>ROLE_EMBEDDED</code></span>
</td>
</tr>
<tr>
<th>
<abbr title="macOS Accessibility Protocol">AX API</abbr><sup>[<a href="#ftn.note1">Note 1</a>]</sup>
</th>
<td>
<span class="property">AXRole: <code>AXGroup</code></span
><br />
<span class="property">AXSubrole: <code>AXWebApplication</code></span
><br />
</td>
</tr>
</tbody>
</table>
<h4 id="role-map-article"><code>article</code></h4>
<table aria-labelledby="role-map-article">
<tbody>
<tr>
<th>ARIA Specification</th>
<td>
<a class="role-reference" href="#article"><code>article</code></a>
</td>
</tr>
<tr>
<th>Computed Role</th>
<td>
<p><code>article</code></p>
</td>
</tr>
<tr>
<th>MSAA + IAccessible2</th>
<td>
<span class="property">Role: <code>ROLE_SYSTEM_DOCUMENT</code></span
><br />
<span class="property">State: <code>STATE_SYSTEM_READONLY</code></span
><br />
<span class="property">Object Attribute: <code>xml-roles:article</code></span>
</td>
</tr>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Control Type: <code>Group</code></span
><br />
<span class="property">Localized Control Type: <code>article</code></span>
</td>
</tr>
<tr>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr></th>
<td>
<span class="property">Role: <code>ROLE_ARTICLE</code></span
><br />
<span class="property">Object Attribute: <code>xml-roles:article</code></span>
</td>
</tr>
<tr>
<th>
<abbr title="macOS Accessibility Protocol">AX API</abbr><sup>[<a href="#ftn.note1">Note 1</a>]</sup>
</th>
<td>
<span class="property">AXRole: <code>AXGroup</code></span
><br />
<span class="property">AXSubrole: <code>AXDocumentArticle</code></span
><br />
</td>
</tr>
</tbody>
</table>
<h4 id="role-map-banner"><code>banner</code></h4>
<table aria-labelledby="role-map-banner">
<tbody>
<tr>
<th>ARIA Specification</th>
<td>
<a class="role-reference" href="#banner"><code>banner</code></a>
</td>
</tr>
<tr>
<th>Computed Role</th>
<td>
<p><code>banner</code></p>
</td>
</tr>
<tr>
<th>MSAA + IAccessible2</th>
<td>
<span class="property">Role: <code>IA2_ROLE_LANDMARK</code></span
><br />
<span class="property">Object Attribute: <code>xml-roles:banner</code></span>
</td>
</tr>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Control Type: <code>Group</code></span
><br />
<span class="property">Localized Control Type: <code>banner</code></span
><br />
<span class="property">Landmark Type: <code>Custom</code></span
><br />
<span class="property">Localized Landmark Type: <code>banner</code></span>
</td>
</tr>
<tr>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr></th>
<td>
<span class="property">Role: <code>ROLE_LANDMARK</code></span
><br />
<span class="property">Object Attribute: <code>xml-roles:banner</code></span>
</td>
</tr>
<tr>
<th>
<abbr title="macOS Accessibility Protocol">AX API</abbr><sup>[<a href="#ftn.note1">Note 1</a>]</sup>
</th>
<td>
<span class="property">AXRole: <code>AXGroup</code></span
><br />
<span class="property">AXSubrole: <code>AXLandmarkBanner</code></span
><br />
</td>
</tr>
</tbody>
</table>
<h4 id="role-map-blockquote"><code>blockquote</code></h4>
<table aria-labelledby="role-map-blockquote">
<tbody>
<tr>
<th>ARIA Specification</th>
<td>
<a class="role-reference" href="#blockquote"><code>blockquote</code></a>
</td>
</tr>
<tr>
<th>Computed Role</th>
<td>
<p><code>blockquote</code></p>
</td>
</tr>
<tr>
<th>MSAA + IAccessible2</th>
<td>
<span class="property">Role: <code>ROLE_SYSTEM_GROUPING</code></span
><br />
<span class="property">Role: <code>IA2_ROLE_BLOCK_QUOTE</code></span>
</td>
</tr>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Control Type: <code>Group</code></span
><br />
<span class="property">Localized Control Type: <code>blockquote</code></span>
</td>
</tr>
<tr>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr></th>
<td>
<span class="property">Role: <code>ROLE_BLOCK_QUOTE</code></span
><br />
</td>
</tr>
<tr>
<th>
<abbr title="macOS Accessibility Protocol">AX API</abbr><sup>[<a href="#ftn.note1">Note 1</a>]</sup>
</th>
<td>
<span class="property">AXRole: <code>AXGroup</code></span
><br />
<span class="property">AXSubrole: <code><nil></code></span
><br />
</td>
</tr>
</tbody>
</table>
<h4 id="role-map-button"><code>button</code> with default values for <code>aria-pressed</code> and <code>aria-haspopup</code></h4>
<table aria-labelledby="role-map-button">
<tbody>
<tr>
<th>ARIA Specification</th>
<td>
<a class="role-reference" href="#button"><code>button</code></a> with default values for <a class="property-reference" href="#aria-pressed"><code>aria-pressed</code></a> and
<a class="property-reference" href="#aria-haspopup"><code>aria-haspopup</code></a>
</td>
</tr>
<tr>
<th>Computed Role</th>
<td>
<p><code>button</code></p>
</td>
</tr>
<tr>
<th>MSAA + IAccessible2</th>
<td>
<span class="property">Role: <code>ROLE_SYSTEM_PUSHBUTTON</code></span>
</td>
</tr>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Control Type: <code>Button</code></span>
</td>
</tr>
<tr>
<th><abbr title="Accessibility Toolkit">ATK</abbr>/<abbr title="Assistive Technology - Service Provider Interface">AT-SPI</abbr></th>
<td>
<span class="property">Role: <code>ROLE_PUSH_BUTTON</code></span>
</td>
</tr>
<tr>
<th>
<abbr title="macOS Accessibility Protocol">AX API</abbr><sup>[<a href="#ftn.note1">Note 1</a>]</sup>
</th>
<td>
<span class="property">AXRole: <code>AXButton</code></span