-
Notifications
You must be signed in to change notification settings - Fork 128
/
Copy pathindex.html
17305 lines (17252 loc) · 946 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>Accessible Rich Internet Applications (WAI-ARIA) 1.3</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<meta name="color-scheme" content="light dark" />
<script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove"></script>
<script class="remove" src="common/script/aria.js"></script>
<script src="common/script/resolveReferences.js" class="remove"></script>
<script src="common/script/participants.js" class="remove"></script>
<script class="remove">
var respecConfig = {
github: "w3c/aria",
doJsonLd: 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: "2024-01-23",
// the specifications short name, as in https://www.w3.org/TR/short-name/
shortName: "wai-aria-1.3",
// if you wish the publication date to be other than today, set this
//publishDate: "2014-12-11",
copyrightStart: "2013",
// 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: "https://www.w3.org/TR/wai-aria/",
//previousDiffURI: "https://www.w3.org/TR/2014/REC-wai-aria-20140320/",
// if there a publicly available Editors Draft, this is the link
edDraftURI: "https://w3c.github.io/aria/",
// 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: "James Nurthen",
company: "Adobe",
companyURL: "https://www.adobe.com/",
w3cid: 37155,
},
{
name: "Peter Krautzberger",
company: "krautzource UG",
companyURL: "https://www.krautzource.com",
w3cid: 60398,
},
{
name: "Daniel Montalvo",
company: "W3C",
companyURL: "https://www.w3.org",
w3cid: 114058,
},
],
formerEditors: [
{
name: "Michael Cooper",
company: "W3C",
companyURL: "https://www.w3.org",
w3cid: 34017,
note: "Editor until 2023",
},
{
name: "Joanmarie Diggs",
company: "Igalia, S.L.",
companyURL: "https://www.igalia.com",
w3cid: 68182,
note: "Editor until 2021",
},
{
name: "Shane McCarron",
company: "Spec-Ops",
// companyURL: "https://www.spec-ops.io",
w3cid: 89030,
note: "Editor until 2018",
},
{
name: "Richard Schwerdtfeger",
company: "Knowbility",
companyURL: "https://knowbility.org/",
w3cid: 2460,
note: "Editor until October 2017",
},
{
name: "James Craig",
company: "Apple Inc.",
companyURL: "https://www.apple.com/accessibility",
w3cid: 42459,
note: "Editor until May 2016",
},
],
// 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: "https://example.org/",
// company: "Your Company", companyURL: "https://example.com/" },
//],
/*
alternateFormats: [
{ uri: 'aria-diff.html', label: "Diff from Previous Recommendation" } ,
{ uri: 'aria.ps', label: "PostScript version" },
{ uri: 'aria.pdf', label: "PDF version" }
],
*/
// errata: 'https://www.w3.org/2010/02/rdfa/errata.html',
// name of the WG
group: "aria",
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: [ariaAttributeReferences],
xref: ["dom", "accname-1.2", "core-aam-1.2", "infra", "HTML"],
definitionMap: [],
};
function respecChangelogFilter(commit) {
// if (commit.message.toLowerCase().startsWith("generated by")) return false;
// else if (commit.message.toLowerCase().startsWith("travis-ci")) return false;
// else if (commit.message.toLowerCase().startsWith("fix")) return false;
// else if (commit.message.toLowerCase().startsWith("editorial")) return false;
// else if (commit.message.toLowerCase().includes("typo")) return false;
// else return true;
return !/^Merge pull|^tidy|^TRAVIS|^ADMIN|^Generated by|respec|(editorial)|.md|editorial|Editiorial|edtiorial|^chore|^refactor|^tests?|^docs|w3cgruntbot|index.html|typo|^nit/i.test(
commit.message,
);
}
</script>
<script src="common/biblio.js" class="remove"></script>
</head>
<body>
<section id="abstract">
<p>
Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with
disabilities. This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and
interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive
technologies in document-level markup. This version adds features new since WAI-ARIA 1.1 [[wai-aria-1.1]] to improve interoperability with assistive technologies to form a more consistent
accessibility model for [[HTML]] and [[SVG2]]. This specification complements both [[HTML]] and [[SVG2]].
</p>
<p>
This document is part of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> suite described in the
<a href="https://www.w3.org/WAI/standards-guidelines/aria/"><abbr title="Accessible Rich Internet Applications">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/aria/issues/new">file an issue in the <abbr title="World Wide Web Consortium">W3C</abbr> ARIA GitHub repository</a>. If this is not
feasible, send email to <a href="mailto:[email protected]?subject=Comment%20on%20WAI-ARIA%201.2">[email protected]</a> (<a href="https://lists.w3.org/Archives/Public/public-aria/"
>comment archive</a
>). In-progress updates to the document can be viewed in the <a href="https://w3c.github.io/aria/">publicly visible editors' draft</a>.
</p>
</section>
<section class="informative" id="introduction">
<h1>Introduction</h1>
<p>The goals of this specification include:</p>
<ul>
<li>expanding the accessibility information that can be supplied by the author;</li>
<li>
requiring that supporting host languages provide full keyboard support that can be implemented in a device-independent way, for example, by telephones, handheld devices, e-book readers, and
televisions;
</li>
<li>improving the accessibility of dynamic content generated by scripts; and</li>
<li>providing for interoperability with <a>assistive technologies</a>.</li>
</ul>
<p>
WAI-ARIA is a technical specification that provides a framework to improve the accessibility and interoperability of web content and applications. This document is primarily for developers
creating custom widgets and other web application components. Please see the <a href="https://www.w3.org/WAI/standards-guidelines/aria/">WAI-ARIA Overview</a> for links to related documents
for other audiences, such as
<cite
><a href="" class="practices"><abbr title="Accessible Rich Internet Applications">ARIA</abbr> Authoring Practices Guide</a></cite
>
[[WAI-ARIA-PRACTICES-1.2]] that introduces developers to the accessibility problems that WAI-ARIA is intended to solve, the fundamental concepts, and the technical approach of WAI-ARIA.
</p>
<p>
This document currently handles two aspects of <a>roles</a>: user interface functionality and structural <a>relationships</a>. For more information and use cases, see
<cite
><a href="" class="practices"><abbr title="Accessible Rich Internet Applications">ARIA</abbr> Authoring Practices Guide</a></cite
>
[[WAI-ARIA-PRACTICES-1.2]] for the use of roles in making interactive content accessible.
</p>
<p>
Roles defined by this specification are designed to support the roles used by platform <a>accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a
>. Declaration of these roles on elements within dynamic web content is intended to support interoperability between the web content and assistive technologies that utilize
<a>accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a
>.
</p>
<p>
The schema to support this standard has been designed to be extensible so that custom roles can be created by extending base roles. This allows [=user agents=] to support at least the base
role, and user agents that support the custom role can provide enhanced access. Note that much of this could be formalized in [[XMLSCHEMA11-2]]. However, being able to define similarities
between roles, such as <a href="#baseConcept">baseConcepts</a> and more descriptive definitions, would not be available in <abbr title="Extensible Markup Language Schema Datatypes">XSD</abbr>.
</p>
<p>
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.2 is a member of the
<a href="https://www.w3.org/WAI/intro/aria"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.2 suite</a> that defines how to expose semantics of WAI-ARIA and other web
content languages to <a>accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a
>.
</p>
<section class="section" id="intro_ria_accessibility">
<h2>Rich Internet Application Accessibility</h2>
<p>
The domain of web accessibility defines how to make web content usable by persons with disabilities. Persons with certain types of disabilities use <a>assistive technologies</a> (<abbr
title="Assistive Technologies"
>AT</abbr
>) to interact with content. Assistive technologies can transform the presentation of content into a format more suitable to the user, and can allow the user to interact in different ways.
For example, the user might need to, or choose to, interact with a slider widget via arrow keys, instead of dragging and dropping with a mouse. In order to accomplish this effectively, the
software needs to understand the <a>semantics</a> of the content. Semantics is the science of meaning; in this case, used to assign roles, states, and properties that apply to user interface
and content elements as a human would understand. For instance, if a paragraph is semantically identified as such, assistive technologies can interact with it as a unit separable from the
rest of the content, knowing the exact boundaries of that paragraph. An adjustable range slider or collapsible list (a.k.a. a tree <a>widget</a>) are more complex examples, in which various
parts of the widget have semantics that need to be properly identified for assistive technologies to support effective interaction.
</p>
<p>
New technologies often overlook semantics required for accessibility, and new authoring practices often misuse the intended semantics of those technologies. [=Elements=] that have one
defined meaning in the language are used with a different meaning intended to be understood by the user.
</p>
<p>
For example, web application developers create collapsible tree widgets in HTML using CSS and JavaScript even though HTML has no semantic <code>tree</code> element. To a non-disabled user,
it might look and act like a collapsible tree widget, but without appropriate semantics, the tree widget might not be <a>perceivable</a> to, or <a>operable</a> by, a person with a disability
because assistive technologies might not recognize the role. Similarly, web application developers create interactive button widgets in SVG using JavaScript even though SVG has no semantic
<code>button</code> element. To a non-disabled user, it might look and act like a button widget, but without appropriate semantics, the button widget might not be <a>perceivable</a> to, or
<a>operable</a> by, a person with a disability because assistive technologies might not recognize the role.
</p>
<p>
The incorporation of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is a way for an author to provide proper semantics for custom widgets to make these widgets
accessible, usable, and interoperable with assistive technologies. This specification identifies the types of widgets and structures that are commonly recognized by accessibility products,
by providing an <a>ontology</a> of corresponding <a>roles</a> that can be attached to content. This allows elements with a given role to be understood as a particular widget or structural
type regardless of any semantics inherited from the implementing host language. Roles are a common property of platform
<a>accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a> which assistive technologies use to provide the user with effective presentation and interaction.
</p>
<p>
The Roles Model includes interaction <a>widgets</a> and elements denoting document structure. The Roles Model describes inheritance and details the [=attributes=] each role supports.
Information about mapping of roles to accessibility <abbr title="Application Programming Interfaces">APIs</abbr> is provided by the
<cite><a href="" class="core-mapping">Core Accessibility API Mappings</a></cite> [[CORE-AAM-1.2]].
</p>
<p>
Roles are element types and will not change with time or user actions. Role information is used by assistive technologies, through interaction with the user agent, to provide normal
processing of the specified element type.
</p>
<p>
States and properties are used to declare important attributes of an element that affect and describe interaction. They enable the <a>user agent</a> and operating system to properly handle
the element even when the attributes are dynamically changed by client-side scripts. For example, alternative input and output technology, such as screen readers and speech dictation
software, need to be able to recognize and effectively manipulate and communicate various interaction states (e.g., disabled, checked) to the user.
</p>
<p>
While it is possible for assistive technologies to access these properties directly through the <cite><a href="https://dom.spec.whatwg.org/">Document Object Model</a></cite> [[DOM]], the
preferred mechanism is for the user agent to map the states and properties to the accessibility <abbr title="Application Programming Interfaces">API</abbr> of the operating system. See the
<cite><a href="" class="core-mapping">Core Accessibility API Mappings</a></cite> [[CORE-AAM-1.2]] and the
<cite><a href="" class="accname">Accessible Name and Description Computation</a></cite> [[ACCNAME-1.2]] for details.
</p>
<p id="desc_contractmodel">
<a href="#fig-contractmodel"></a> illustrates the relationship between user agents (e.g., browsers), accessibility APIs, and assistive technologies. It describes the "contract" provided by
the user agent to assistive technologies, which includes typical accessibility information found in the accessibility <abbr title="Application Programming Interfaces">API</abbr> for many of
our accessible platforms for GUIs (role, state, selection, <a>event</a> notification, <a>relationship</a> information, and descriptions). The DOM, usually HTML, acts as the data model and
view in a typical model-view-controller relationship, and JavaScript acts as the controller by manipulating the style and content of the displayed data. The user agent conveys relevant
information to the operating system's accessibility API, which can be used by any assistive technologies, such as screen readers.
</p>
<figure id="fig-contractmodel">
<img alt="The contract model with accessibility APIs" height="389" src="img/accessibleelement.png" width="723" />
<figcaption>The contract model with accessibility <abbr title="Application Programming Interfaces">APIs</abbr></figcaption>
</figure>
<p>
For more information see
<cite
><a href="" class="practices"><abbr title="Accessible Rich Internet Applications">ARIA</abbr> Authoring Practices Guide</a></cite
>
for the use of roles in making interactive content accessible.
</p>
<p>
Users of alternate input devices need <a>keyboard accessible</a> content. The new semantics, when combined with the recommended keyboard interactions provided in
<cite
><a href="" class="practices"><abbr title="Accessible Rich Internet Applications">ARIA</abbr> Authoring Practices Guide</a></cite
>, will allow alternate input solutions to facilitate command and control via an alternate input solution.
</p>
<p>
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> introduces navigational <a>landmarks</a> through its Roles Model and the
<abbr title="Extensible Hypertext Markup Language">XHTML</abbr> role landmarks, which can help persons with dexterity and vision impairments by providing for improved keyboard navigation.
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> can also be used to assist persons with cognitive learning disabilities. The additional semantics allow authors to
restructure and substitute alternative content as needed.
</p>
<p>
<a>Assistive technologies</a> need the ability to support alternative inputs by getting and setting the current value of <a>widget</a> states and properties. Assistive technologies also need
to determine what <a>objects</a> are selected and manage widgets that allow multiple selections, such as list boxes and grids.
</p>
<p>
Speech-based command and control systems can benefit from <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics like the <code>role</code> attribute to assist in
conveying audio information to the user. For example, upon encountering an element with a role of <rref>menu</rref> with child elements of role <rref>menuitem</rref> each containing text
content representing a different flavor, a speech system might state to the user, "Select one of three choices: chocolate, strawberry, or vanilla."
</p>
<p>
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a
feature that provides equivalent accessibility to the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> feature, use the host language feature.
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> should only be used in cases where the host language lacks the needed <a>role</a>, <a>state</a>, and [=ARIA/property=]
indicators. Use a host language feature that is as similar as possible to the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> feature, then refine the meaning by adding
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. For instance, a multi-selectable grid could be implemented as a table, and then
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> used to clarify that it is an interactive grid, not just a static data table. This allows for the best possible fallback
for user agents that do not support <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and preserves the integrity of the host language semantics.
</p>
</section>
<section id="target-audience">
<h2>Target Audience</h2>
<p>
This specification defines the basic model for <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>, including roles, states, properties, and values. It impacts several
audiences:
</p>
<ul>
<li>[=user agents=] that process content containing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> features;</li>
<li><a>Assistive technologies</a> that present content in special ways to user with disabilities;</li>
<li>Authors who create content;</li>
<li>Authoring tools that help authors create conforming content; and</li>
<li>Conformance checkers that verify appropriate use of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>.</li>
</ul>
<p>Each conformance requirement indicates the audience to which it applies.</p>
<p>
Although this specification is applicable to the above audiences, it is not specifically targeted to, nor is it intended to be the sole source of information for, any of these audiences. The
following documents provide important supporting information:
</p>
<ul>
<li>[[[WAI-ARIA-PRACTICES-1.2]]] addresses authoring recommendations for HTML, and is also of interest to developers of authoring tools and conformance checkers.</li>
<li>[[[CORE-AAM-1.2]]] addresses developers of [=user agents=] and <a class="termref">assistive technologies</a>.</li>
<li>[[[ACCNAME-1.2]]] also addresses developers of [=user agents=] and <a class="termref">assistive technologies</a>.</li>
</ul>
</section>
<section id="ua-support">
<h2>User Agent Support</h2>
<p><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> relies on user agent support for its features in two ways:</p>
<ul>
<li>
Mainstream [=user agents=] use <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> to alter how host language features are exposed to <a>accessibility APIs</a> in order to
improve accessibility. The mechanism for this is defined in the <cite><a href="" class="core-mapping">Core Accessibility API Mappings</a></cite
>.
</li>
<li>
<a>Assistive technologies</a> use the enhanced information available in an accessibility API, or uses the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> markup
directly via the <abbr title="Document Object Model">DOM</abbr>, to convey semantic and interaction information to the user.
</li>
</ul>
<p>
Aside from using <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> markup to improve what is exposed to accessibility APIs, user agents behave as they would natively.
Assistive technologies react to the extra information in the accessibility API as they already do for the same information on non-web content. User agents that are not assistive
technologies, however, need do nothing beyond providing appropriate updates to the accessibility API.
</p>
<p>
The <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> specification neither requires nor forbids user agents from enhancing native presentation and interaction behaviors on
the basis of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> markup. Mainstream user agents might expose
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> navigational landmarks (for example, as a dialog box or through a keyboard command) with the intention to facilitate
navigation for all users. User agents are encouraged to maximize their usefulness to users, including users without disabilities.
</p>
<p>
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is intended to provide missing semantics so that the intent of the author can be conveyed to assistive technologies.
Generally, authors using <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> will provide the appropriate presentation and interaction features. Over time, host languages can
add <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> equivalents, such as new form controls, that are implemented as standard accessible user interface controls by the
user agent. This allows authors to use them instead of custom <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> enabled user interface components. In this case the user
agent would support the native host language feature. Developers of host languages that implement <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> are advised to continue
supporting <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics when they do not adversely conflict with implicit host language semantics, as
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics more clearly reflect the intent of the author if the host language features are inadequate to meet the author's
needs.
</p>
</section>
<section id="co-evolution">
<h2>Co-Evolution of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and Host Languages</h2>
<p>
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is intended to augment semantics in supporting languages like [[HTML]] and [[SVG2]], or to be used as an accessibility
enhancement technology in other markup-based languages that do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of
objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them
appears in web languages.
</p>
<p>
It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of object. While
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the
object natively. For example, it's better to use an <code>h1</code> element in HTML than to use the <rref>heading</rref> role on a <code>div</code> element.
</p>
<p>
It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. This is natural and desirable, as one goal of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is to
help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and
stop using <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> for that feature. Legacy content can continue to use
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>, however, so the need for user agents to support
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> remains.
</p>
<p>
While specific features of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> might lose importance over time, the general possibility of
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> to add semantics to web pages is expected to be a persistent need. Host languages might not implement all the semantics
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> provides, and various host languages can implement different subsets of the features. New types of objects are continually
being developed, and one goal of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is to provide a way to make such objects accessible, because authoring practices often
advance faster than host language standards. In this way, <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and host languages both evolve together but at different rates.
</p>
<p>
Some host languages exist to create semantics for features other than the user interface. For example, SVG expresses the semantics behind production of graphical objects, not of user
interface components that those objects can represent. Host languages might, by design, not provide native semantics that map to
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> features. In these cases, <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> could be adopted as a
long-term approach to add semantic information to user interface components.
</p>
</section>
<section id="authoring_practices">
<h2>Authoring Practices</h2>
<section id="authoring_tools">
<h3>Authoring Tools</h3>
<p>
Many of the requirements in the definitions of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a>roles</a>, <a>states</a>, and [=ARIA/properties=] can be checked
automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating custom widgets, authoring tools can
compare widget roles, states, and properties to those supported in <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> as well as those supported in related and
cross-referenced roles, states, and properties. Authoring tools can notify authors of errors in widget design patterns, and can also prompt developers for information that cannot be
determined from context alone. For example, a scripting library can determine the labels for the tree items in a tree view, but would need to prompt the author to label the entire tree. To
help authors visualize a logical accessibility structure, an authoring environment might provide an outline view of a web resource based on the
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> markup.
</p>
<p>
In both HTML and SVG, <code>tabindex</code> is an important way browsers support keyboard <a href="#host_general_focus">focus navigation</a> for implementations of
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>; authoring and debugging tools can check to make sure <code>tabindex</code> values are properly set. For example, error
conditions can include cases where more than one treeitem in a tree has a <code>tabindex</code> value greater than or equal to 0, where <code>tabindex</code> is not set on any treeitem, or
where <pref>aria-activedescendant</pref> is not defined when the element with the role tree has a <code>tabindex</code> value of greater than or equal to 0.
</p>
</section>
<section id="authoring_testing">
<h3>Testing Practices and Tools</h3>
<p>
The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to <a>widgets</a> and
applications, and should verify accessibility <abbr title="Application Programming Interface">API</abbr> access to all content and changes during user interaction.
</p>
</section>
</section>
<section id="at_support">
<h2>Assistive Technologies</h2>
<p>
Programmatic access to accessibility semantics is essential for assistive technologies. Most assistive technologies interact with user agents, like other applications, through a recognized
accessibility API. Perceivable objects in the user interface are exposed to assistive technologies as accessible objects, defined by the accessibility API interfaces. To do this properly,
accessibility information – role, states, properties as well as contextual information – needs to be accurately conveyed to the assistive technologies through the accessibility API. When a
state change occurs, the user agent provides the appropriate event notification to the accessibility API. Contextual information, in many host languages like HTML, can be determined from the
<abbr title="Document Object Model">DOM</abbr> itself as it provides a contextual tree hierarchy.
</p>
<p>
While some assistive technologies interact with these accessibility APIs, others might access the content directly from the <abbr title="Document Object Model">DOM</abbr>. These technologies
can restructure, simplify, style, or reflow the content to help a different set of users. Common use cases for these types of adaptations might be the aging population, persons with
cognitive impairments, or persons in environments that interfere with use of their tools. For example, the availability of regional navigational landmarks can allow for a mobile device
adaptation that shows only portions of the content at any one time based on its semantics. This could reduce the amount of information the user needs to process at any one time. In other
situations it might be appropriate to replace a custom user interface control with something that is easier to navigate with a keyboard, or touch screen device.
</p>
</section>
</section>
<section class="informative" id="terms">
<h1>Important Terms</h1>
<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 <abbr title="Application Programming Interface">API</abbr></dfn>
</dt>
<dd>
<p>
Operating systems and other platforms provide a set of interfaces that expose information about <a class="termref">objects</a> and <a class="termref">events</a> to
<a>assistive technologies</a>. Assistive technologies use these interfaces to get information about and interact with those <a class="termref">widgets</a>. Examples of accessibility APIs
are <a href="https://learn.microsoft.com/en-us/windows/win32/winauto/microsoft-active-accessibility">Microsoft Active Accessibility</a> [[MSAA]],
<a href="https://learn.microsoft.com/en-us/windows/win32/winauto/entry-uiauto-win32">Microsoft User Interface Automation</a> [[UI-AUTOMATION]],
<abbr title="Microsoft Active Accessibility">MSAA</abbr> with
<cite
><a href="https://learn.microsoft.com/en-us/windows/win32/winauto/iaccessibleex"><abbr title="User Interface Automation">UIA</abbr> Express</a></cite
>
[[UIA-EXPRESS]], the <a href="https://developer.apple.com/documentation/appkit/nsaccessibility">Mac <abbr title="OS Ten">OS X</abbr> Accessibility Protocol</a> [[AXAPI]], the
<cite><a href="https://gnome.pages.gitlab.gnome.org/atk/">Linux/Unix Accessibility Toolkit</a></cite> [[ATK]] and
<cite><a href="https://gnome.pages.gitlab.gnome.org/at-spi2-core/libatspi/">Assistive Technology Service Provider Interface</a></cite> [[AT-SPI]], and
<a href="https://wiki.linuxfoundation.org/accessibility/iaccessible2/start">IAccessible2</a> [[IAccessible2]].
</p>
</dd>
<dt><dfn data-export="">Accessible object</dfn></dt>
<dd>
<p>
A [=nodes|node=] in the <a class="termref">accessibility tree</a> of a platform <a>accessibility <abbr title="Application Programming Interface">API</abbr></a
>. Accessible objects expose various <a class="termref">states</a>, [=ARIA/properties=], and <a class="termref">events</a> for use by <a>assistive technologies</a>. In the context of
markup languages (e.g., HTML and SVG) in general, and of WAI-ARIA in particular, markup [=elements=] and their [=attributes=] are represented as accessible objects.
</p>
</dd>
<dt><dfn data-export="">Assistive Technologies</dfn></dt>
<dd>
<p>Hardware and/or software that:</p>
<ul>
<li>relies on services provided by a <a>user agent</a> to retrieve and render Web content</li>
<li>works with a user agent or web content itself through the use of APIs, and</li>
<li>provides services beyond those offered by the user agent to facilitate user interaction with web content by people with disabilities</li>
</ul>
<p>This definition might differ from that used in other documents.</p>
<p>Examples of assistive technologies that are important in the context of this document include the following:</p>
<ul>
<li>screen magnifiers, which are used to enlarge and improve the visual readability of rendered text and images;</li>
<li>screen readers, which are most-often used to convey information through synthesized speech or a refreshable Braille display;</li>
<li>text-to-speech software, which is used to convert text into synthetic speech;</li>
<li>speech recognition software, which is used to allow spoken control and dictation;</li>
<li>alternate input technologies (including head pointers, on-screen keyboards, single switches, and sip/puff devices), which are used to simulate the keyboard;</li>
<li>alternate pointing devices, which are used to simulate mouse pointing and clicking.</li>
</ul>
</dd>
<dt><dfn data-local-lt="deprecate|deprecation">Deprecated</dfn></dt>
<dd>
<p>
A deprecated <a class="termref" href="#dfn-role">role</a>, <a class="termref" href="#dfn-state">state</a>, or <a class="termref" href="#dfn-property">property</a> is one which has been
outdated by newer constructs or changed circumstances, and which might be removed in future versions of the
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> specification. [=user agents=] are encouraged to continue to support items identified as deprecated for backward
compatibility. For more information, see <a href="#deprecated" class="specref">Deprecated Requirements</a> in the Conformance section.
</p>
</dd>
<dt><dfn>Defines</dfn></dt>
<dd>
<p>
Used in an attribute description to denote that the value <a href="#propcharacteristic_value">type</a> is an <a href="#valuetype_integer">integer</a>,
<a href="#valuetype_number">number</a>, or <a href="#valuetype_string">string</a>.
</p>
<p>Related Terms: <a>Identifies</a>, <a>Indicates</a></p>
</dd>
<dt><dfn data-local-lt="desktop focus">Desktop focus event</dfn></dt>
<dd>
<p>Event from/to the host operating system via the accessibility <abbr title="Application Programming Interface">API</abbr>, notifying of a change of input focus.</p>
</dd>
<dt><dfn>Event</dfn></dt>
<dd>
<p>
A programmatic message used to communicate discrete changes in the <a>state</a> of an <a>object</a> to other objects in a computational system. User input to a web page is commonly
mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object. In some programming languages, events are more
commonly known as notifications.
</p>
</dd>
<dt><dfn>Expose</dfn></dt>
<!--Not used-->
<dd>
<p>Translated to platform-specific <a class="termref">accessibility APIs</a> as defined in the <a href="" class="core-mapping">Core Accessibility API Mappings</a>.</p>
</dd>
<dt><dfn>Graphical Document</dfn></dt>
<dd>
<p>
A document containing graphic representations with user-navigable parts. Charts, maps, diagrams, blueprints, and dashboards are examples of graphical documents. A graphical document is
composed using any combination of symbols, images, text, and graphic primitives (shapes such as circles, points, lines, paths, rectangles, etc).
</p>
</dd>
<dt><dfn data-dfn-for="element" data-export="">Hidden</dfn></dt>
<dd>
<p>Indicates that the <a>element</a> is excluded from the accessibility tree and therefore not exposed to accessibility APIs.</p>
<p>Related: <a href="#tree_exclusion">Excluding Elements in the Accessibility Tree</a>, [=element/hidden from all users=], <sref>aria-hidden</sref>.</p>
</dd>
<dt><dfn data-dfn-for="element" data-lt="hide from all users" data-export="">Hidden From All Users</dfn></dt>
<dd>
<p>
Indicates that the <a>element</a> is not visible, <a>perceivable</a>, or interactive for <em>any</em> user. Note that an <a>element</a> can be [=element/hidden=] but not [=element/hidden
from all users=] by using <code>aria-hidden</code>.
</p>
<p>Related: <a href="#tree_exclusion">Excluding Elements in the Accessibility Tree</a>, [=element/hidden=], <sref>aria-hidden</sref>.</p>
<p></p>
</dd>
<dt><dfn>Identifies</dfn></dt>
<dd>
<p>
Used in an attribute description to denote that the value <a href="#propcharacteristic_value">type</a> is an <a href="#valuetype_idref">ID reference</a> (identifying a single element) or
<a href="#valuetype_idref_list">ID reference list</a> (identifying one or more elements).
</p>
<p>Related Terms: <a>Defines</a>, <a>Indicates</a></p>
</dd>
<dt><dfn>Indicates</dfn></dt>
<dd>
<p>
Used in an attribute description to denote that the value <a href="#propcharacteristic_value">type</a> is a named token or otherwise token-like, including the Boolean-like
<a href="#valuetype_true-false">true/false</a>, <a href="#valuetype_true-false-undefined">true/false/undefined</a>, <a href="#valuetype_tristate">tristate (true/false/mixed)</a>, a
single named <a href="#valuetype_token">token</a>, or a <a href="#valuetype_token_list">token list</a>.
</p>
<p>Related Terms: <a>Defines</a>, <a>Identifies</a></p>
</dd>
<dt><dfn>Keyboard Accessible</dfn></dt>
<dd>
<p>
Accessible to the user using a keyboard or <a>assistive technologies</a> that mimic keyboard input, such as a sip and puff tube. References in this document relate to
<cite
><a href="https://www.w3.org/TR/WCAG21/#keyboard-accessible"
><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.1 Guideline 2.1: Make all functionality available from a keyboard</a
></cite
>
[[WCAG21]].
</p>
</dd>
<dt><dfn>Landmark</dfn></dt>
<dd>
<p>
A type of region on a page to which the user might want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user
purpose, such as navigating, searching, perusing the primary content, etc.
</p>
</dd>
<dt><dfn data-export="">Live Region</dfn></dt>
<dd>
<p>
Live regions are perceivable regions of a web page that are typically updated as a result of an external event. These regions are not always updated as a result of a user interaction and
can receive these updates even when they do not have focus. Examples of live regions include a chat log, stock ticker, or a sport scoring section that updates periodically to reflect
game statistics. Since these asynchronous areas are expected to update outside the user's area of focus, assistive technologies such as screen readers have either been unaware of their
existence or unable to process them for the user. WAI-ARIA has provided a collection of properties that allow the author to identify these live regions and process them: aria-live,
aria-relevant, aria-atomic, and aria-busy.
</p>
</dd>
<dt><dfn data-export="">Managed State</dfn></dt>
<dd>
<p>
<a>Accessibility API</a> <a>state</a> that is controlled by the user agent, such as focus and selection. These are contrasted with "unmanaged states" that are typically
controlled by the author. Nevertheless, authors can override some managed states, such as aria-posinset and aria-setsize. Many managed states have corresponding CSS pseudo-classes, such
as :focus, and pseudo-elements, such as ::selection, that are also updated by the user agent.
</p>
</dd>
<dt><dfn>Nemeth Braille</dfn></dt>
<dd>
<p>
The Nemeth Braille Code for Mathematics is a braille code for encoding mathematical and scientific notation. See
<cite><a href="https://en.wikipedia.org/wiki/Nemeth_Braille">Nemeth Braille on Wikipedia</a>.</cite>
</p>
</dd>
<dt><dfn>Object</dfn></dt>
<dd>
<p>In the context of user interfaces, an item in the perceptual user experience, represented in markup languages by one or more [=elements=], and rendered by [=user agents=].</p>
In the context of programming, the instantiation of one or more classes and interfaces which define the general characteristics of similar objects. An object in an
<a>accessibility <abbr title="Application Programming Interfaces">API</abbr></a> can represent one or more DOM objects. <a class="termref">Accessibility APIs</a> have defined interfaces
that are distinct from DOM interfaces.
</dd>
<dt><dfn>Ontology</dfn></dt>
<dd>
<p>A description of the characteristics of classes and how they relate to each other.</p>
</dd>
<dt><dfn>Operable</dfn></dt>
<dd>
<p>
Usable by users in ways they can control. References in this document relate to
<cite
><a href="https://www.w3.org/TR/WCAG21/#operable"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.1 Principle 2: Content must be operable</a></cite
>
[[WCAG21]]. See <a>Keyboard Accessible</a>.
</p>
</dd>
<dt><dfn data-export="">Perceivable</dfn></dt>
<dd>
<p>
Presentable to users in ways they can sense. References in this document relate to
<cite
><a href="https://www.w3.org/TR/WCAG21/#perceivable"><abbr title="Web Content Accessibility Guidelines">WCAG</abbr> 2.1 Principle 1: Content must be perceivable</a></cite
>
[[WCAG21]].
</p>
</dd>
<dt><dfn data-export="" data-dfn-for="ARIA">Property</dfn></dt>
<dd>
<p>
[=attributes=] that are essential to the nature of a given <a>object</a>, or that represent a data value associated with the object. A change of a property can significantly impact the
meaning or presentation of an object. Certain properties (for example, <pref>aria-multiline</pref>) are less likely to change than <a class="termref" href="#dfn-state">states</a>, but
note that the frequency of change difference is not a rule. A few properties, such as <pref>aria-activedescendant</pref>, <pref>aria-valuenow</pref>, and <pref>aria-valuetext</pref> are
expected to change often. See <a class="specref" href="#statevsprop">clarification of states versus properties</a>.
</p>
</dd>
<dt><dfn data-export="">Relationship</dfn></dt>
<dd>
<p>A connection between two distinct things. Relationships can be of various types to indicate which <a>object</a> labels another, controls another, etc.</p>
</dd>
<dt><dfn data-export="">Role</dfn></dt>
<dd>
<p>
Main indicator of type.
<!-- (removing, vague) The object's role is the class of <a class="termref">objects</a> of which it is a member. -->
This <a class="termref" data-lt="semantics">semantic</a> association allows tools to present and support interaction with the object in a manner that is consistent with user expectations
about other objects of that type.
</p>
</dd>
<dt><dfn data-export="" data-local-lt="semantically">Semantics</dfn></dt>
<dd>
<p>
The meaning of something as understood by a human, defined in a way that computers can process a representation of an <a>object</a>, such as [=elements=] and [=attributes=], and reliably
represent the object in a way that various humans will achieve a mutually consistent understanding of the object.
</p>
</dd>
<dt><dfn data-export="">State</dfn></dt>
<dd>
<p>
A state is a dynamic <a class="termref" href="#dfn-property">property</a> expressing characteristics of an <a>object</a> that can change in response to user action or automated
processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities. See
<a class="specref" href="#statevsprop">clarification of states versus properties</a>.
</p>
</dd>
<dt><dfn>Target Element</dfn></dt>
<dd>
<p>
An element specified in a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> relation. For example, in <code> <div aria-controls=”elem1”></code>, where
<code>“elem1”</code> is the ID for the target element.
</p>
</dd>
<dt><dfn data-lt="unicode braille">Unicode Braille Patterns</dfn></dt>
<dd>
<p>
In Unicode, braille is represented in a block called Braille Patterns (U+2800..U+28FF). The block contains all 256 possible patterns of an 8-dot braille cell; this includes the complete
6-dot cell range which is represented by U+2800..U+283F. In all braille systems, the braille pattern dots-0 (U+2800) is used to represent a space or the lack of content; it is also
called a blank Braille pattern. See <cite><a href="https://en.wikipedia.org/wiki/Braille_Patterns">Braille Patterns on Wikipedia</a>.</cite>
</p>
</dd>
<dt><dfn data-export="">Widget</dfn></dt>
<dd>
<p>
Discrete user interface <a class="termref" href="#dfn-object">object</a> with which the user can interact. Widgets range from simple objects that have one value or operation (e.g., check
boxes and menu items), to complex objects that contain many managed sub-objects (e.g., trees and grids).
</p>
</dd>
</dl>
</div>
</section>
<section class="normative override" id="conformance">
<h2>Conformance</h2>
<p>
The main content of Accessible Rich Internet Applications is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as
"non-normative" and their subsections, diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but
does not create requirements that impact a conformance claim.
</p>
<p>
Normative sections provide requirements that authors and [=user agents=] must follow for an implementation to conform to this specification. The keywords <em class="rfc2119">MUST</em>,
<em class="rfc2119">MUST NOT</em>, <em class="rfc2119">REQUIRED</em>, <em class="rfc2119">SHALL</em>, <em class="rfc2119">SHALL NOT</em>, <em class="rfc2119">SHOULD</em>,
<em class="rfc2119">RECOMMENDED</em>, <em class="rfc2119">MAY</em>, and <em class="rfc2119">OPTIONAL</em> in this document are to be interpreted as described in
<cite><a href="https://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 an 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>
Non-normative (informative) sections provide information useful to understanding the specification. Such sections might contain examples of recommended practice, but it is not required to
follow such recommendations in order to conform to this specification.
</p>
<section id="ua_noninterference">
<h2>Non-interference with the Host Language</h2>
<p>
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> processing by the <a>user agent</a> MUST NOT interfere with the normal operation of the built-in features of the host
language.
</p>
<p>
If a CSS selector includes a WAI-ARIA attribute (e.g., <code class="highlight css">input[aria-invalid="true"]</code>), user agents MUST update the visual display of any elements matching (or
no longer matching) the selector any time the attribute is added/changed/removed in the <abbr title="Document Object Model">DOM</abbr>. The user agent MAY alter the mapping of the host
language features into an <a>accessibility <abbr title="Application Programming Interface">API</abbr></a
>, but the user agent MUST NOT alter the <abbr title="Document Object Model">DOM</abbr> in order to remap <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> markup into host
language features.
</p>
</section>
<section id="ua_dom">
<h2>All <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> in <abbr title="Document Object Model">DOM</abbr></h2>
<p>
A conforming <a>user agent</a> which implements a document object model that does not conform to the W3C DOM specification MUST include the content attribute for role and its
<a href="#roles_categorization">WAI-ARIA role values</a>, as well as the <a href="#states_and_properties">WAI-ARIA States and Properties</a> in the DOM as specified by the author, even
though processing might affect how the elements are exposed to accessibility APIs. Doing so ensures that each role attribute and all
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties, including their values, are in the document in an unmodified form so other tools, such as assistive
technologies, can access them. A conforming W3C <abbr title="Document Object Model">DOM</abbr> meets this criterion.
</p>
</section>
<section id="ua_domchanges">
<h2>Assistive Technology Notifications Communicated to Web Applications</h2>
<p>
<a>Assistive technologies</a>, such as speech recognition systems and alternate input devices for users with mobility impairments, require the ability to control a web application in a
device-independent way. <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a>states</a> and [=ARIA/properties=] reflect the current state of rich internet application
components. The ability for assistive technologies to notify web applications of necessary changes is essential because it allows these alternative input solutions to control an application
without being dependent on the standard input device which the user is unable to effectively control directly.
</p>
<p>
User agents MUST provide a method to notify the web application when a change occurs to states or properties in the system accessibility API. Likewise, authors SHOULD update the web
application accordingly when notified of a change request from the user agent or assistive technology.
</p>
</section>
<section id="conformance_checkers">
<h2>Conformance Checkers</h2>
<p>
Any application or script verifying document conformance or validity SHOULD include a test for all of the normative author requirements in this specification. If testing for a given
requirement, conformance checkers MUST issue an error if an author "MUST" requirement isn't met, and MUST issue a warning if an author "SHOULD" requirement isn't met.
</p>
</section>
<section id="deprecated">
<!-- Deprecated requirements should begin with <p><em>This requirement is <a href="#deprecated">deprecated</a>.</em></p> -->
<h2>Deprecated Requirements</h2>
<p>
As the technology evolves, sometimes new ways to meet a use case become available, that work better than a feature that was previously defined. But because of existing implementation of the
older feature, that feature cannot be removed from the conformance model without rendering formerly conforming content non-conforming. In this case, the older feature is marked as
"deprecated". This indicates that the feature is allowed in the conformance model and expected to be supported by user agents, but it is recommended that authors do not use it for new
content. In future versions of the specification, if the feature is no longer widely used, the feature could be removed and no longer expected to be supported by user agents.
</p>
</section>
</section>
<section class="normative" id="usage">
<h1>Using <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></h1>
<p>
Complex web applications become inaccessible when <a>assistive technologies</a> cannot determine the <a>semantics</a> behind portions of a document or when the user is unable to effectively
navigate to all parts of it in a usable way (see
<cite
><a href="" class="practices"><abbr title="Accessible Rich Internet Applications">ARIA</abbr> Authoring Practices Guide</a></cite
>). <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> divides the semantics into <a>roles</a> (the type defining a user interface element) and <a>states</a> and
[=ARIA/properties=] supported by the roles.
</p>
<p>
Authors need to associate [=elements=] in the document to a WAI-ARIA role and the appropriate states and properties (aria-* [=attributes=]) during its life-cycle, unless the elements already
have the appropriate <a href="#implicit_semantics">implicit WAI-ARIA semantics</a> for states and properties. In these instances the equivalent host language states and properties take
precedence to avoid a conflict while the role attribute will take precedence over the implicit role of the host language element.
</p>
<section id="introroles" class="normative">
<h2><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Roles</h2>
<p>
A <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a>role</a> is set on an <a>element</a> using a <code>role</code> <a>attribute</a>, similar to the
<code>role</code> attribute defined in <cite><a href="https://www.w3.org/TR/role-attribute/">Role Attribute</a></cite> [[ROLE-ATTRIBUTE]].
</p>
<pre class="example highlight html"><li role="menuitem">Open file…</li></pre>
<p>The definition of each role in the model provides the following information :</p>
<ul>
<li>an informative description of the role;</li>
<li>hierarchical information about related roles (e.g., a <rref>searchbox</rref> is a type of <rref>textbox</rref>);</li>
<li>context of the role (e.g., a <rref>listitem</rref> is contained inside a <rref>list</rref>);</li>
<li>references to related concepts in other specifications;</li>
<li>supported <a>states</a> and [=ARIA/properties=] for each role (e.g., a <rref>checkbox</rref> supports being checked via <sref>aria-checked</sref>).</li>
</ul>
<p>
Attaching a role gives <a>assistive technologies</a> information about how to handle each element. 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>.
</p>
<p>
User agents MUST use the first token in the sequence of tokens in the <code>role</code> <a>attribute</a> value that matches the name of any non-abstract
<abbr title="Accessible Internet Application">WAI-ARIA</abbr> <a>role</a>. Refer to the section on <a href="#host_general_role">`role` attribute implementation in Host Languages</a> for
further details.
</p>
</section>
<section id="introstates">
<h2><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> States and Properties</h2>
<p>
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> provides a collection of accessibility <a>states</a> and [=ARIA/properties=] which are used to support platform
<a>accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a> on various operating system platforms. <a>Assistive technologies</a> can access this information through an
exposed <a>user agent</a> DOM or through a mapping to the platform accessibility <abbr title="Application Programming Interfaces">API</abbr>. When combined with <a>roles</a>, the user agent
can supply the assistive technologies with user interface information to convey to the user at any time. Changes in states or properties will result in a notification to assistive
technologies, which could alert the user that a change has occurred.
</p>
<p>
In the following example, a list item (<code>html:li</code>) has been used to create a checkable menu item, and JavaScript <a>events</a> will capture mouse and keyboard events to toggle the
value of <sref>aria-checked</sref>. A role is used to make the behavior of this simple <a>widget</a> known to the user agent. [=attribute|Attributes=] that change with user actions (such as
<sref>aria-checked</sref>) are defined in the <a href="#states_and_properties">states and properties</a> section.
</p>
<pre class="example highlight html"><li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li></pre>
<p>
Some accessibility states, called <em><a>managed states</a></em
>, are controlled by the user agent. Examples of managed state include keyboard focus and selection. Managed states often have corresponding
<abbr title="Cascading Style Sheets">CSS</abbr> pseudo-classes (such as <code>:focus</code> and <code>::selection</code>) to define style changes. In contrast, the states in this
specification are typically controlled by the author and are called <em>unmanaged states.</em> Some states are managed by the user agent, such as <pref>aria-posinset</pref> and
<pref>aria-setsize</pref>, but the author can override them if the <abbr title="Document Object Model">DOM</abbr> is incomplete and would cause the user agent calculation to be incorrect.
User agents map both managed and unmanaged states to the platform accessibility <abbr title="Application Programming Interfaces">APIs</abbr>.
</p>
<p>
Most modern user agents support
<cite
><a href="https://www.w3.org/TR/css3-selectors/#attribute-selectors"><abbr title="Cascading Style Sheets">CSS</abbr> attribute selectors</a></cite
>
([[CSS3-SELECTORS]]), and can allow the author to create <abbr title="User Interface">UI</abbr> changes based on <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> attribute
information, reducing the amount of scripts necessary to achieve equivalent functionality. In the following example, a <abbr title="Cascading Style Sheets">CSS</abbr> selector is used to
determine whether or not the text is bold and an image of a check mark is shown, based on the value of the <sref>aria-checked</sref> attribute.
</p>
<pre class="example highlight css">
[aria-checked="true"] { font-weight: bold; }
[aria-checked="true"]::before { background-image: url(checked.gif); }</pre
>
<p>
If CSS is not used to toggle the visual representation of the check mark, the author could include additional markup and scripts to manage an image that represents whether or not the
<rref>menuitemcheckbox</rref> is checked.
</p>
<pre class="example highlight html"><li role="menuitemcheckbox" aria-checked="true">
<img src="checked.gif" alt="">
<span class="comment"><!-- note: additional scripts required to toggle image source --></span>
Sort by Last Modified
</li></pre>
</section>
<section id="managingfocus" class="normative">
<h2>Managing Focus and Supporting Keyboard Navigation</h2>
<p>
When using standard <abbr title="Hypertext Markup Language">HTML</abbr> interactive elements and simple <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a>widgets</a>,
application developers can manipulate the tab order or associate keyboard shortcuts with elements in the document.
</p>
<p>
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> includes a number of "managing container" widgets, also known as "composite" widgets. When
appropriate, the container is responsible for tracking the last descendant that was active (the default is usually the first item in the container). It is essential that a container maintain
a usable and consistent strategy when focus leaves a container and is then later refocused. While there can be exceptions, it is recommended that when a previously focused container is
refocused, the active descendant be the same element as the active descendant when the container was last focused. Exceptions include cases where the contents of a container widget have
changed, and widgets like a menubar where the user expects to always return to the first item when focus leaves the menu bar. For example, if the second item of a tree group was the active
descendant when the user tabbed out of the tree group, then the second item of the tree group remains the active descendant when the tree group gets focus again. The user can also activate
the container by clicking on one of the descendants within it. When the container or its active descendant has focus, the user can navigate through the container by pressing additional keys,
such as the arrow keys, to change the currently active descendant. Any additional press of the main navigation key (generally the <kbd>TAB</kbd> key) will move out of the container to the
next widget.
</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>,
<pref>aria-activedescendant</pref> 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>
When implementing <pref>aria-activedescendant</pref> as described below, the user agent keeps the <abbr title="Document Object Model">DOM</abbr> focus on the container element or on an input
element that controls the container element. However, the user agent communicates <a>desktop focus events</a> and states to the assistive technology as if the element referenced by
<pref>aria-activedescendant</pref> has focus. User agents are not expected to validate that the active descendant is a descendant of the container element. It is the responsibility of the
user agent to ensure that keyboard events are processed at the <a>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 for processing.
</p>
<section id="managingfocus_authors">
<h3>Information for Authors</h3>
<p>
If the author removes the element with focus, the author SHOULD move focus to a logical element. Similarly, authors SHOULD not scroll the element with focus off screen unless the user
performed a scrolling action.
</p>
<p>
Authors SHOULD ensure that all interactive [=elements=] are focusable and that all parts of composite widgets are either focusable or have a documented alternative method to achieve their
function.
</p>
<p>Authors MUST manage focus on the following container roles:</p>
<ul>
<li><rref>grid</rref></li>
<li><rref>listbox</rref></li>
<li><rref>menu</rref></li>
<li><rref>menubar</rref></li>
<li><rref>radiogroup</rref></li>
<li><rref>tree</rref></li>
<li><rref>treegrid</rref></li>
<li><rref>tablist</rref></li>
</ul>
<p>
User agents that support <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> expand the usage of host language mechanisms such as <code>tabindex</code>, <code>focus</code>,
and <code>blur</code> to allow them on all [=elements=]. Where the host language supports it, 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 supported in both [[HTML]] and [[SVG2]].
</p>
<p>
Authors MAY use <pref>aria-activedescendant</pref> to inform <a>assistive technologies</a> which descendant of a <rref>widget</rref> element is treated as having keyboard focus in the user
interface if the role of the widget element supports <code>aria-activedescendant</code>. This is often a more convenient way of providing keyboard navigation within widgets, such as a
<rref>listbox</rref>, where the widget occupies only one stop in the page <kbd>Tab</kbd> sequence and other keys, typically arrow keys, are used to focus elements inside the widget.
</p>
<p>
Typically, the author will use host language <a>semantics</a> to put the widget in the <kbd>Tab</kbd> sequence (e.g., <code>tabindex="0"</code> in HTML) and
<code>aria-activedescendant</code> to point to the ID of the currently active descendant. The author, not the user agent, 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 the actual focus is on the container.
</p>
<p>
More information on managing focus can be found in the <a href="practices/keyboard-interface" class="practices">Developing a Keyboard Interface</a> section of the
<cite><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices</cite>.