/
aria.html
10931 lines (10885 loc) · 599 KB
/
aria.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
<!--?xml version='1.0' encoding='UTF-8'?-->
<!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.1</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<script src="https://spec-ops.io/respec-w3c-common.js" class="remove"></script>
<!-- <script src="https://www.w3.org/Tools/respec/respec-w3c-common" class="remove"></script> -->
<script src="../common/biblio.js" class="remove"></script>
<link href="../common/css/common.css" rel="stylesheet" type="text/css"/>
<script class="remove" src="script/aria.js"></script>
<script src="../common/script/resolveReferences.js" class="remove"></script>
<script class="remove">
var respecConfig = {
// embed RDFa data in the output
trace: true,
useExperimentalStyles: true,
doRDFa: '1.1',
includePermalinks: true,
permalinkEdge: true,
permalinkHide: false,
// specification status (e.g., WD, LC, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
//crEnd: "2012-04-30",
//perEnd: "2013-07-23",
//publishDate: "2013-08-22",
diffTool: "http://www.aptest.com/standards/htmldiff/htmldiff.pl",
// the specifications short name, as in http://www.w3.org/TR/short-name/
shortName: "wai-aria-1.1",
// 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: "http://www.w3.org/TR/2014/REC-wai-aria-20140320/",
//previousDiffURI: "http://www.w3.org/TR/2014/REC-wai-aria-20140320/",
// if there a publicly available Editors Draft, this is the link
edDraftURI: "https://rawgit.com/w3c/aria/master/aria/aria.html", // until this one is updated via automated script "http://w3c.github.io/aria/aria/aria.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2012-02-21",
// editors, add as many as you like
// only "name" is required
editors: [
{
name: "Joanmarie Diggs",
url: 'http://www.igalia.com',
mailto: "jdiggs@igalia.com",
company: "Igalia, S.L.",
companyURI: "http://www.igalia.com"
},
{
name: "James Craig",
url: 'http://www.apple.com',
mailto: "jcraig@apple.com",
company: "Apple Inc.",
companyURI: "http://www.apple.com"
},
{
name: "Shane McCarron",
url: 'http://blog.halindrome.com',
mailto: "shane@aptest.com",
company: "Applied Testing and Technology, Inc.",
companyURI: "http://www.aptest.com"
},
{
name: "Michael Cooper",
url: 'http://www.w3.org',
mailto: "cooper@w3.org",
company: "W3C",
companyURI: "http://www.w3.org"
}
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURI: "http://example.com/" },
//],
/*
alternateFormats: [
{ uri: 'aria-diff.html', label: "Diff from Previous Recommendation" } ,
{ uri: 'aria.ps', label: "PostScript version" },
{ uri: 'aria.pdf', label: "PDF version" }
],
*/
// errata: 'http://www.w3.org/2010/02/rdfa/errata.html',
// name of the WG
wg: "Accessible Rich Internet Applications Working Group",
// URI of the public WG page
wgURI: "http://www.w3.org/WAI/ARIA/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-aria",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/83726/status",
maxTocLevel: 4,
// Spec URLs
ariaSpecURLs: {
"ED": "",
"WD" : "",
"REC": ""
},
accNameURLs: {
"ED": "http://w3c.github.io/aria/accname-aam/accname-aam.html",
"WD" : "http://www.w3.org/TR/accname-aam-1.1/",
"FPWD": "http://www.w3.org/TR/accname-aam-1.1/",
"REC": "http://www.w3.org/TR/accname-aam-1.1/"
},
localBiblio: biblio,
};
</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.0 [[!WAI-ARIA-10]] to improve interoperability with assistive technologies to form a more consistent accessibility model for [[HTML5]] and [[SVG2]]. This specification complements both [[HTML5]] 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="http://www.w3.org/WAI/intro/aria.php"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Overview</a>.</p>
</section>
<section id="sotd">
</section>
<section class="informative" id="introduction">
<h1>Introduction</h1>
<p>The goals of this specification include:</p>
<ul>
<li>expanding the accessibility information that may be supplied by the author;</li>
<li>requiring that supporting host languages provide full keyboard support that may 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="http://www.w3.org/WAI/intro/aria">WAI-ARIA Overview</a> for links to related documents for other audiences, such as the WAI-ARIA Primer 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 draft currently handles two aspects of <a>roles</a>: user interface functionality and structural <a>relationships</a>. For more information and use cases, see the [[WAI-ARIA-PRIMER]] for the use of roles in making interactive content accessible.</p>
<p>The role <a>taxonomy</a> is designed in part to support the common roles found in platform <a>accessibility <abbr title="Application Programing Interfaces">APIs</abbr></a>. Reference to roles found in this taxonomy by dynamic web content may be used to support interoperability with assistive technologies.</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 <a>user agents</a> 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 [[XMLSCHEMA-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.1 is a member of the <a href="https://www.w3.org/WAI/intro/aria#wai-aria-1_1"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.1 suite</a> that defines how to expose semantics of WAI-ARIA and other web content languages to <a>accessibility <abbr title="Application Programing 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 may 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. <a>Elements</a> 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 may look and act like a collapsible tree widget, but without appropriate semantics, the tree widget may not be <a>perceivable</a> to, or <a>operable</a> by, a person with a disability because assistive technologies may 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 may look and act like a button widget, but without appropriate semantics, the button widget may not be <a>perceivable</a> to, or <a>operable</a> by, a person with a disability because assistive technologies may 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 semantic inherited from the implementing host language. Roles are a common property of platform <a>accessibility <abbr title="Application Programing Interfaces">APIs</abbr></a> which assistive technologies use to provide the user with effective presentation and interaction.</p>
<p>This role <a>taxonomy</a> includes interaction <a>widgets</a> and elements denoting document structure. The role taxonomy describes inheritance and details the <a>attributes</a> each role supports. Information about mapping of roles to accessibility <abbr title="Application Programing Interfaces">APIs</abbr> is provided by the <cite><a href="http://www.w3.org/TR/core-aam-1.1/">Core Accessibility API Mappings 1.1</a></cite> [[CORE-AAM]].</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 manipulated 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://www.w3.org/TR/dom/">Document Object Model</a></cite> [[DOM4]], the preferred mechanism is for the user agent to map the states and properties to the accessibility <abbr title="Application Programing Interfaces">API</abbr> of the operating system. See the <cite><a href="http://www.w3.org/TR/core-aam-1.1/">Core Accessibility API Mappings 1.1</a></cite> [[CORE-AAM]] and the <cite><a href="http://www.w3.org/TR/accname-aam-1.1/">Accessible Name and Description: Computation and API Mappings 1.1</a></cite> [[ACCNAME-AAM]] for details.</p>
<p id="desc_contractmodel">Figure 1.0 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 Programing 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>
<div class="image">
<p><img alt="The contract model with accessibility APIs" height="389" id="contractmodel" src="img/accessibleelement.png" width="723"/></p>
<p class="img-caption">Figure 1: The contract model with accessibility <abbr title="Application Programing Interfaces">APIs</abbr></p>
</div>
<p>For more information see the <cite><a href="http://www.w3.org/TR/wai-aria-primer/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Primer</a></cite> [[WAI-ARIA-PRIMER]] for the use of roles in making interactive content accessible.</p>
<p>In addition to the prose documentation, the role taxonomy is provided in <cite><a href="http://www.w3.org/TR/2004/REC-owl-features-20040210/">Web Ontology Language (OWL)</a></cite> [[OWL-FEATURES]], which is expressed in <cite><a href="http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/">Resource Description Framework (RDF)</a></cite> [[RDF-CONCEPTS]]. Tools can use these to validate the implementation of roles in a given content document. For example, instances of some roles are expected to be children of a specific parent role. Also, some roles may support a specific <a>state</a> or <a>property</a> that another role does not support.</p>
<p class="note">The use of <abbr title="Resource Description Framework">RDF</abbr>/OWL as a formal representation of roles may be used to support future extensibility. Standard RDF/OWL mechanisms can be used to define new roles that inherit from the roles defined in this specification. The mechanism to define and use role extensions in an interoperable manner, however, is not defined by this specification. A future version of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is expected to define how to extend roles.</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="http://www.w3.org/TR/wai-aria-practices/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices</a></cite> [[WAI-ARIA-PRACTICES]], 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 taxonomy 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> may 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, by determining that an element has a role of <rref>menuitem</rref> each containing text content representing a different flavor, a speech system might state to the user that, "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 <a>property</a> 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><a>User agents</a> 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><cite><a href="https://www.w3.org/TR/wai-aria-practices-1.1/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices 1.1 </cite></a> addresses authoring recommendations for HTML, and is also of interest to developers of authoring tools and conformance checkers.</li>
<li><cite><a href="https://www.w3.org/TR/core-aam-1.1/">Core Accessibility API Mappings 1.1</a></cite> addresses developers of <a class="termref">user agents</a> and <a class="termref">assistive technologies</a>.</li>
<li><cite><a href="https://www.w3.org/TR/accname-aam-1.1/">Accessible Name and Description: Computation and API Mappings 1.1</a></cite> also addresses developers of <a class="termref">user agents</a> 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 <a>user agents</a> 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="http://www.w3.org/TR/wai-aria-implementation/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> User Agent Implementation Guide</a></cite> [[WAI-ARIA-IMPLEMENTATION]].</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 may 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 may 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 [[HTML5]] 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 objects. 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 may 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> may 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 may not implement all the semantics <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> provides, and various host languages may 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 web 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 may represent; XForms provides semantics for form controls and does not provide wider user interface features. Host languages such as these 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>state</a>, and <a>properties</a> 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 may 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 may notify authors of errors in widget design patterns, and may 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 may check to make sure <code>tabindex</code> values are properly set. For example, error conditions may 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 programing 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 may 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 may 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 may 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 needed to process at any one time. In other situations it may 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="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 the <cite><a href="http://www.w3.org/TR/wai-aria-primer/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Primer</a></cite> [[WAI-ARIA-PRIMER]]). <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>state</a> and <a>properties</a> supported by the roles.</p>
<p>Authors need to associate <a>elements</a> in the document to a WAI-ARIA role and the appropriate states and properties (aria-* <a>attributes</a>) 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="usage_intro">
<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 the <cite><a href="http://www.w3.org/TR/role-attribute/">Role Attribute</a></cite> [[ROLE-ATTRIBUTE]].</p>
<pre class="example highlight"><li role="menuitem">Open file…</li></pre>
<p>The roles defined in this specification include a collection of <a href="#landmark_roles">document landmarks</a> and the <a href="#role_definitions"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> role taxonomy</a>.</p>
<p>The roles in this <a>taxonomy</a> and their expected behaviors are modeled using <cite><a href="http://www.w3.org/TR/2004/REC-owl-features-20040210/"><abbr title="Resource Description Framework">RDF</abbr>/<abbr title="Web Ontology Language">OWL</abbr></a></cite> [[OWL-FEATURES]]. Features of the role taxonomy provide the following information for each role:</p>
<ul>
<li>an informative description of the role;</li>
<li>hierarchical information about related roles (e.g., a <rref>directory</rref> is a type of <rref>list</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>use of <abbr title="Web Ontology Language">OWL</abbr> to provide a type hierarchy allowing for <a>semantic</a> inheritance (similar to a <a>class</a> hierarchy); and</li>
<li>supported <a>state</a> and <a>properties</a> 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.</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>state</a> and <a>properties</a> which are used to support platform <a>accessibility <abbr title="Application Programing Interfaces">APIs</abbr></a> on various operating system platforms. <a>Assistive technologies</a> may access this information through an exposed <a>user agent</a> DOM or through a mapping to the platform accessibility <abbr title="Application Programing 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 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. <a>Attributes</a> 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"><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 Programing Interfaces">APIs</abbr>.</p>
<p>Most modern user agents support <cite><a href="http://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 lang-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"><li role="menuitemcheckbox" aria-checked="true">
<img src="checked.gif" role="presentation" alt="">
<span class="comment"><!-- note: additional scripts required to toggle image source --></span>
Sort by Last Modified
</li></pre>
</section>
<section id="managingfocus">
<h2>Managing Focus</h2>
<p>An <rref>application</rref> should always have an <a>element</a> with focus when in use, as applications require users to have a place to provide user input. Authors are advised to <em>not</em> destroy the element with focus or scroll it off-screen unless through user intervention. All interactive <a>objects</a> should be focusable. All parts of composite interactive controls need to be focusable or have a documented alternative method to achieve their function, such as a keyboard shortcut. Authors are advised to maintain an obvious, discoverable way, either through tabbing or other standard navigation techniques, for keyboard users to move the focus to any interactive element. See <a href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/guidelines.html#gl-navigation">User Agent Accessibility Guidelines, Guideline 9</a> ([[UAAG10]], Guideline 9).</p>
<p>When using standard <abbr title="Hypertext Markup Language">HTML</abbr> and basic <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a>widgets</a>, application developers can simply manipulate the tab order or use a script to create keyboard shortcuts to elements in the document. Use of more complex widgets requires the author to manage focus within them. SVG Tiny provides a similar navigation "ring" mechanism that by default follows document order and which should be implemented using system dependent input facilities (the TAB key on most desktop computers). SVG authors may place elements in the navigation order by manipulating the <a href="http://www.w3.org/TR/SVGTiny12/interact.html#FocusableAttribute">focusable</a> attribute and they may dynamically <a href="http://www.w3.org/TR/SVGTiny12/interact.html#specifyingnavigation">specify the navigation order</a> by modifying elements <a href="http://www.w3.org/TR/SVGTiny12/intro.html#TermNavigationAttribute">navigation attributes</a>.</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 which 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 may 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 may also activate the container by clicking on one of the descendants within it.</p>
<p>When the container or its active descendant has focus, the user may 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>For example, a <rref>grid</rref> may be used as a spreadsheet with thousands of <rref>gridcell</rref> elements, all of which may not be present in the document at one time. This requires focus to be managed by the container using the <pref>aria-activedescendant</pref> <a>attribute</a> on the managing container element, or by the container managing the <code>tabindex</code> of its child elements and setting focus on the appropriate child. For more information, see <cite><a href="http://www.w3.org/TR/wai-aria-practices/#kbd_focus">Providing Keyboard Focus in <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices</a></cite> ([[WAI-ARIA-PRACTICES]]).</p>
<p>Content authors are required to manage focus on the following container roles:</p>
<ul>
<li><rref>combobox</rref></li>
<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>More information on managing focus can be found in the <a href="http://www.w3.org/TR/wai-aria-practices/#focus_tabindex">Using Tabindex to Manage Focus Among Widgets</a> section of the <cite><a href="http://www.w3.org/TR/wai-aria-practices/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices</a></cite> [[WAI-ARIA-PRACTICES]].</p>
</section>
</section>
<section class="normative" id="conformance">
<p>This specification indicates whether a section is <a>normative</a> or <a>informative</a>. Classifying a section as normative or informative applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.</p>
<p>Normative sections provide requirements that authors, user agents, and assistive technologies MUST follow for an implementation to conform to this specification.</p>
<p>Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.</p>
<section 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 lang-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 Programing 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 may 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 criteria.</p>
</section>
<section id="ua_domchanges">
<h2>Assistive Technology Notifications Communicated to Web Applications</h2>
<p><a>Assistive technologies</a>, such as voice 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>state</a> and <a>properties</a> reflect the current state of rich internet application components. The ability for assistive technologies to notify web application 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, web application authors SHOULD update the web application accordingly when notified of a change request from the user agent or assistive technology.</p>
<p class="note">Many state and properties can be changed by assistive technologies through existing accessibility APIs by responding to a default action event. For example, the <sref>aria-selected</sref> state of a tab in a tabpanel can be changed by triggering the default action on the element.</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 <a href="#dfn-normative">normative</a> 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>
<section class="informative" id="terms">
<h1>Important Terms</h1>
<div data-include="../common/terms.html" data-oninclude="restrictReferences"></div>
</section>
<section class="normative" id="roles">
<h1>The Roles Model</h1>
<p>This section defines the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a>role</a> <a>taxonomy</a> and describes the characteristics and properties of all <a>roles</a>. A formal <abbr title="Resource Description Framework">RDF</abbr>/<abbr title="Web Ontology Language">OWL</abbr> representation of all the information presented here is available in <a href="#a_schemata">Schemata Appendix</a>.</p>
<p>The roles, their characteristics, the states and properties they support, and specification of how they may be used in markup, shall be considered normative. The RDF/OWL representation used to model the taxonomy shall be considered informative. The RDF/OWL taxonomy may be used as a vehicle to extend <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> in the future or by tool manufacturers to validate states and properties applicable to roles per this specification.</p>
<p>Roles are element types and authors MUST NOT change role values over time or with user actions. Authors wishing to change a role MUST do so by deleting the associated element and its children and replacing it with a new element with the appropriate role. Typically, platform accessibility APIs do not provide a vehicle to notify assistive technologies of a role value change, and consequently, assistive technologies may not update their cache with the new role attribute value. </p>
<p>In order to reflect the content in the DOM, user agents SHOULD map the role attribute to the appropriate value in the implemented accessibility API, and user agents SHOULD update the mapping when the role attribute changes.</p>
<section id="relationshipsconcepts">
<h2>Relationships Between Concepts</h2>
<p>The <a>role</a> <a>taxonomy</a> uses the following relationships to relate <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles to each other and to concepts from other specifications, such as HTML and XForms.</p>
<section id="superclassrole">
<h3>Superclass Role</h3>
<p>Inheritance is expressed in <abbr title="Resource Description Framework">RDF</abbr> using the <abbr title="Resource Description Framework">RDF</abbr> Schema 1.1 <cite><a href="http://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_subclassof">subClassOf</a></cite> ([[RDF-SCHEMA]]) property.</p>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>rdfs:subClassOf</dd>
</dl>
<p>The <a>role</a> that the current subclassed role extends in the <a>taxonomy</a>. This extension causes all the properties and constraints of the superclass role to propagate to the subclass role. Other than well known stable specifications, inheritance may be restricted to items defined inside this specification, so that external items cannot be changed and affect inherited <a>classes</a>.</p>
</section>
<section id="subclassroles">
<h3>Subclass Roles</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd><none></dd>
</dl>
<p>Informative list of <a>roles</a> for which this role is the superclass. This is provided to facilitate reading of the specification but adds no new information.</p>
</section>
<section id="relatedConcept">
<h3>Related Concepts</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>role:relatedConcept</dd>
</dl>
<p>Informative data about a similar or related idea from other specifications. Concepts that are related are not necessarily identical. Related concepts do not inherit properties from each other. Hence if the definition of one concept changes, the properties, behavior, and definition of its related concept is not affected.</p>
<p>For example, a progress bar is like a status indicator. Therefore, the <rref>progressbar</rref> <a>widget</a> has a <code>relatedConcept</code> value which includes <rref>status</rref>. However, if the definition of <rref>status</rref> is modified, the definition of a <rref>progressbar</rref> is not affected.</p>
</section>
<section id="baseConcept">
<h3>Base Concept</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>role:baseConcept</dd>
</dl>
<p>Informative data about <a>objects</a> that are considered prototypes for the <a>role</a>. Base concept is similar to type, but without inheritance of limitations and properties. Base concepts are designed as a substitute for inheritance for external concepts. A base concept is like a <a href="#relatedConcept">related concept</a> except that the base concept is almost identical to the role definition.</p>
<p>For example, the <rref>checkbox</rref> defined in this document has similar functionality and anticipated behavior to a <a href="http://www.w3.org/TR/html4/interact/forms.html#checkbox">checkbox defined in <abbr title="Hypertext Markup Language">HTML</abbr></a>. Therefore, a <rref>checkbox</rref> has an <abbr title="Hypertext Markup Language">HTML</abbr> <code>checkbox</code> as a <code>baseConcept</code>. However, if the original <abbr title="Hypertext Markup Language">HTML</abbr> checkbox baseConcept definition is modified, the definition of a <rref>checkbox</rref> in this document will not be affected, because there is no actual inheritance of the respective type.</p>
</section>
</section>
<section id="Properties">
<h2>Characteristics of Roles</h2>
<p>Roles are defined and described by their characteristics. Characteristics define the structural function of a role, such as what a role is, concepts behind it, and what instances the role can or must contain. In the case of <a>widgets</a> this also includes how it interacts with the <a>user agent</a> based on mapping to <abbr title="Hypertext Markup Language">HTML</abbr> forms and XForms. States and properties from <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> that are supported by the role are also indicated.</p>
<p>The roles <a>taxonomy</a> defines the following characteristics. These characteristics are implemented in <abbr title="Resource Description Framework">RDF</abbr> as properties of the OWL <a>classes</a> that describe the roles.</p>
<section id="isAbstract">
<h3>Abstract Roles</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>N/A</dd>
<dt>Values</dt>
<dd>Boolean</dd>
</dl>
<p>Abstract <a>roles</a> are the foundation upon which all other <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles are built. Content authors MUST NOT use abstract roles because they are not implemented in the <abbr title="application programing interface">API</abbr> binding. User agents MUST NOT map abstract roles to the standard role mechanism of the accessibility API. Abstract roles are provided to help with the following:</p>
<ol>
<li>Organize the role <a>taxonomy</a> and provide roles with a meaning in the context of known concepts.</li>
<li>Streamline the addition of roles that include necessary features.</li>
</ol>
</section>
<section id="requiredState">
<h3>Required States and Properties</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>role:requiredState</dd>
<dt>Values</dt>
<dd>Any valid <abbr title="Resource Description Framework">RDF</abbr> object reference, such as a <abbr title="Uniform Resource Identifier">URI</abbr>.</dd>
</dl>
<p><a>States</a> and <a>properties</a> specifically required for the <a>role</a> and subclass roles. Content authors MUST provide a non-empty <span>value</span> for required states and properties. Content authors MUST NOT use the value "undefined" for required states and properties.</p>
<p>When an <a>object</a> inherits from multiple ancestors and one ancestor indicates that property is supported while another ancestor indicates that it is required, the property is required in the inheriting object.</p>
<p class="note">A host language attribute with the appropriate <a href="#implicit_semantics">implicit WAI-ARIA semantic</a> fulfills this requirement.</p>
</section>
<section id="supportedState">
<h3>Supported States and Properties</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>role:supportedState</dd>
<dt>Values</dt>
<dd>Any valid <abbr title="Resource Description Framework">RDF</abbr> object reference, such as a <abbr title="Uniform Resource Identifier">URI</abbr>.</dd>
</dl>
<p><a>States</a> and <a>properties</a> specifically applicable to the <a>role</a> and child roles. <a>User agents</a> MUST map all supported states and properties for the role to an accessibility API. Content authors MAY provide <span>values</span> for supported states and properties, but need not in some cases where default values are sufficient.</p>
<p class="note">A host language attribute with the appropriate <a href="#implicit_semantics">implicit WAI-ARIA semantic</a> fulfills this requirement.</p>
</section>
<section id="inheritedattributes">
<h3>Inherited States and Properties</h3>
<p>Informative list of properties that are inherited onto a <a>role</a> from superclass roles. <a>States</a> and <a>properties</a> are inherited from superclass roles in the role <a>taxonomy</a>, not from ancestor <a>elements</a> in the <abbr title="Document Object Model">DOM</abbr> tree. These properties are not explicitly defined on the role, as the inheritance of properties is automatic. This information is provided to facilitate reading of the specification. The set of supported states and properties combined with inherited states and properties forms the full set of states and properties supported by the role.</p>
</section>
<section id="mustContain">
<h3>Required Owned Elements</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>role:mustContain</dd>
<dt>Values</dt>
<dd>Any valid <abbr title="Resource Description Framework">RDF</abbr> object reference, such as a <abbr title="Uniform Resource Identifier">URI</abbr>.</dd>
</dl>
<p>Any <a>element</a> that will be <a>owned</a> by the element with this <a>role</a>. For example, an element with the role <rref>list</rref> will own at least one element with the role <rref>group</rref> or <rref>listitem</rref>.</p>
<p>When multiple roles are specified as <em>required owned elements</em> for a role, at least one instance of one required owned element is expected. This specification does <em>not</em> require an instance of each of the listed owned roles. For example, a <code>menu</code> should have at least one instance of a <code>menuitem</code>, <code>menuitemcheckbox</code>, <em>or</em> <code>menuitemradio</code>. The <code>menu</code> role does not require one instance of each. </p>
<p>There may be times that required owned elements are missing, for example, while editing or while loading a data set. When a widget is missing <em>required owned elements</em> due to script execution or loading, authors MUST mark a containing element with <sref>aria-busy</sref> equal to <code>true</code>. For example, until a page is fully initialized and complete, an author could mark the document element as busy.</p>
<p class="note">A role that has 'required owned elements' does not imply the reverse relationship. While processing of a role may be incomplete without elements of given roles present as descendants, elements with roles in this list do not always have to be found within elements of the given role. See <a href="#scope">required context role</a> for requirements about the context where elements of a given role will be contained.</p>
<p class="note">An element with a <a href="#subclassroles">subclass role</a> of the 'required owned element' does not fulfill this requirement. For example, the <rref>list</rref> role requires ownership of an element using either the <rref>listitem</rref> or <rref>group</rref> role. Although the <rref>group</rref> role is the superclass of <rref>row</rref>, adding a owned element with a role of <rref>row</rref> will not fulfill the requirement that <rref>list</rref> must own a <rref>listitem</rref> or a <rref>group</rref>.</p>
<p class="note">An element with the appropriate <a href="#implicit_semantics">implicit WAI-ARIA semantic</a> fulfills this requirement.</p>
</section>
<section id="scope">
<h3>Required Context Role</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>role:scope</dd>
<dt>Values</dt>
<dd>Any valid <abbr title="Resource Description Framework">RDF</abbr> object reference, such as a <abbr title="Uniform Resource Identifier">URI</abbr>.</dd>
</dl>
<p>The required context role defines the owning container where this <a>role</a> is allowed. If a role has a required context, authors MUST ensure that an element with the role is contained inside (or <a>owned</a> by) an element with the required context role. For example, an element with role <code>listitem</code> is only meaningful when contained inside (or owned by) an element with role <code>list</code>.</p>
<p class="note">A role that has 'required context role' does not imply the reverse relationship. While an element with the given role needs to appear within an element of the listed role(s) in order to be meaningful, elements of the listed roles do not always need descendant elements of the given role in order to be meaningful. See <a href="#mustContain">required owned elements</a> for requirements about elements that require presence of a given descendant to be processed properly.</p>
<p class="note">An element with the appropriate <a href="#implicit_semantics">implicit WAI-ARIA semantic</a> fulfills this requirement.</p>
</section>
<section id="namecalculation">
<h3>Accessible Name Calculation</h3>
<section id="namecomputation">
<h4>Name Computation</h4>
<p><a href="http://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_name">Name Computation</a> is defined in the Accessible Name and Description specification [[ACCNAME-AAM]].</p>
</section>
<section id="descriptioncomputation">
<h4>Description Computation</h4>
<p><a href="http://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_description">Description Computation</a> is defined in the Accessible Name and Description specification [[ACCNAME-AAM]].</p>
</section>
<section id="textalternativecomputation">
<h4>Text Alternative Computation</h4>
<p><a href="http://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te">Text Alternative Computation</a> is defined in the Accessible Name and Description specification [[ACCNAME-AAM]].</p>
</section>
</section>
<section id="childrenArePresentational">
<h3>Presentational Children</h3>
<dl class="runin">
<dt><abbr title="Resource Description Framework">RDF</abbr> Property</dt>
<dd>role:childrenArePresentational</dd>
<dt>Values</dt>
<dd>
<p>Boolean (true | false)</p>
</dd>
</dl>
<p>The <abbr title="Document Object Model">DOM</abbr> descendants are presentational. <a>User agents</a> SHOULD NOT expose descendants of this <a>element</a> through the platform <a>accessibility <abbr title="Application Programing Interface">API</abbr></a>. If <a>user agents</a> do not hide the descendant nodes, some information may be read twice.</p>
</section>
<section id="implictValueForRole">
<h3>Implicit Value for Role</h3>
<p>Many states and properties have default values. Occasionally, the default value when used on a given role should be different from the usual default. Roles that require a state or property to have a non-standard default value indicate this in the "Implicit Value for Role". This is expressed in the form "<code>state or property name</code> is <code>new default value</code>". Roles that define this have the new default value for the state or property if the author does not provide an explicit value.</p>
</section>
</section>
<section id="roles_categorization">
<h2>Categorization of Roles</h2>
<p>To support the current user scenario, this specification categorizes <a>roles</a> that define user interface <a>widgets</a> (sliders, tree controls, etc.) and those that define page structure (sections, navigation, etc.). Note that some assistive technologies provide special modes of interaction for regions marked with role <code>application</code> or <code>document</code>.</p>
<div class="img" id="rdf_model"><a href="img/rdf_model"><img alt="Class diagram of the relationships described in the role data model" src="img/rdf_model_sm.png" longdesc="img/rdf_model.html" width="600" height="256" /></a>
<p>Class diagram of the relationships described in the role data model.</p>
<p><a href="img/rdf_model.svg"><abbr title="Scalable Vector Graphics">SVG</abbr> class diagram</a> | <a href="img/rdf_model.png"><abbr title="Portable Network Graphics">PNG</abbr> class diagram</a> | <a href="img/rdf_model.html">Class diagram description</a></p>
</div>
<p>Roles are categorized as follows:</p>
<ol>
<li><a href="#abstract_roles">Abstract Roles</a></li>
<li><a href="#widget_roles">Widget Roles</a></li>
<li><a href="#document_structure_roles">Document Structure Roles</a></li>
<li><a href="#landmark_roles">Landmark Roles</a></li>
<li><a href="#live_region_roles">Live Region Roles</a></li>
</ol>
<section id="abstract_roles">
<h3>Abstract Roles</h3>
<p>The following <a>roles</a> are used to support the WAI-ARIA role <a>taxonomy</a> for the purpose of defining general role concepts.</p>
<p>Abstract roles are used for the ontology. Authors MUST NOT use abstract roles in content.</p>
<ul>
<li><rref>command</rref></li>
<li><rref>composite</rref></li>
<li><rref>input</rref></li>
<li><rref>landmark</rref></li>
<li><rref>range</rref></li>
<li><rref>roletype</rref></li>
<li><rref>section</rref></li>
<li><rref>sectionhead</rref></li>
<li><rref>select</rref></li>
<li><rref>structure</rref></li>
<li><rref>widget</rref></li>
<li><rref>window</rref></li>
</ul>
</section>
<section id="widget_roles">
<h3>Widget Roles</h3>
<p>The following roles act as standalone user interface widgets or as part of larger, composite widgets.</p>
<ul>
<li><rref>alert</rref></li>
<li><rref>alertdialog</rref></li>
<li><rref>button</rref></li>
<li><rref>checkbox</rref></li>
<li><rref>dialog</rref></li>
<li><rref>gridcell</rref></li>
<li><rref>link</rref></li>
<li><rref>log</rref></li>
<li><rref>marquee</rref></li>
<li><rref>menuitem</rref></li>
<li><rref>menuitemcheckbox</rref></li>
<li><rref>menuitemradio</rref></li>
<li><rref>option</rref></li>
<li><rref>progressbar</rref></li>
<li><rref>radio</rref></li>
<li><rref>scrollbar</rref></li>
<li><rref>searchbox</rref></li>
<li><rref>slider</rref></li>
<li><rref>spinbutton</rref></li>
<li><rref>status</rref></li>
<li><rref>switch</rref></li>
<li><rref>tab</rref></li>
<li><rref>tabpanel</rref></li>
<li><rref>textbox</rref></li>
<li><rref>timer</rref></li>
<li><rref>tooltip</rref></li>
<li><rref>treeitem</rref></li>
</ul>
<p>The following roles act as composite user interface widgets. These roles typically act as containers that manage other, contained widgets.</p>
<ul>
<li><rref>combobox</rref></li>
<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>tablist</rref></li>
<li><rref>tree</rref></li>
<li><rref>treegrid</rref></li>
</ul>
</section>
<section id="document_structure_roles">
<h3>Document Structure</h3>
<p>The following <a>roles</a> describe structures that organize content in a page. Document structures are not usually interactive.</p>
<ul>
<li><rref>application</rref></li>
<li><rref>article</rref></li>
<li><rref>cell</rref></li>
<li><rref>columnheader</rref></li>
<li><rref>definition</rref></li>
<li><rref>directory</rref></li>
<li><rref>document</rref></li>
<li><rref>feed</rref></li>
<li><rref>figure</rref></li>
<li><rref>group</rref></li>
<li><rref>heading</rref></li>
<li><rref>img</rref></li>
<li><rref>list</rref></li>
<li><rref>listitem</rref></li>
<li><rref>math</rref></li>
<li><rref>none</rref></li>
<li><rref>note</rref></li>
<li><rref>presentation</rref></li>
<li><rref>region</rref></li>
<li><rref>row</rref></li>
<li><rref>rowgroup</rref></li>
<li><rref>rowheader</rref></li>
<li><rref>separator</rref></li>
<li><rref>table</rref></li>
<li><rref>term</rref></li>
<li><rref>text</rref></li>
<li><rref>toolbar</rref></li>
</ul>
</section>
<section id="landmark_roles">
<h3>Landmark Roles</h3>
<p>The following <a>roles</a> are regions of the page intended as navigational <a>landmarks</a>. All of these roles inherit from the <code>landmark</code> base type and all are imported from the <cite><a href="http://www.w3.org/TR/role-attribute/#s_role_module_attributes">Role Attribute</a></cite> [[ROLE-ATTRIBUTE]]. The roles are included here in order to make them clearly part of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Role <a>taxonomy</a>.</p>
<ul>
<li><rref>banner</rref></li>
<li><rref>complementary</rref></li>
<li><rref>contentinfo</rref></li>
<li><rref>form</rref></li>
<li><rref>main</rref></li>
<li><rref>navigation</rref></li>
<li><rref>region</rref></li>
<li><rref>search</rref></li>
</ul>
</section>
<section id="live_region_roles">
<h3>Live Region Roles</h3>
<p>The following widget <a>roles</a> are also <a>live regions</a> and may be modified by <a href="#attrs_liveregions">live region attributes</a>.</p>
<ul>
<li><rref>alert</rref></li>
<li><rref>log</rref></li>
<li><rref>marquee</rref></li>
<li><rref>status</rref></li>
<li><rref>timer</rref></li>
</ul>
</section>
</section>
<section id="role_definitions">
<h2>Definition of Roles</h2>
<p>Below is an alphabetical list of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a>roles</a> to be used by rich internet application authors.</p>
<p>Abstract roles are used for the ontology. Authors MUST NOT use abstract roles in content.</p>
<p id="index_role">Placeholder for compact list of roles</p>
<div class="role" id="alert">
<rdef>alert</rdef>
<div class="role-description">
<p>A type of <a>live region</a> with important, and usually time-sensitive, information. See related <rref>alertdialog</rref> and <rref>status</rref>.</p>
<p>Alerts are used to convey messages to alert the user. In the case of audio warnings this is an accessible alternative for a hearing-impaired user. The <code>alert</code> <a>role</a> goes on the node containing the alert message. Alerts are specialized forms of the <rref>status</rref> role, which will be processed as an atomic <a>live region</a>.</p>
<p>Alerts are assertive live regions and will be processed as such by assistive technologies. Neither authors nor user agents are required to set or manage focus to them in order for them to be processed. Since alerts are not required to receive focus, content authors SHOULD NOT require users to close an alert. If the operating system allows, the <a>user agent</a> SHOULD fire a system alert <a>event</a> through the accessibility API when the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> alert is created. If an alert requires focus to close the alert, then content authors SHOULD use <rref>alertdialog</rref> instead.</p>
<p>Elements with the role <code>alert</code> have an implicit <pref>aria-live</pref> value of <code>assertive</code>, and an implicit <pref>aria-atomic</pref> value of <code>true</code>.</p>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
<thead>
<tr>
<th scope="col">Characteristic</th>
<th scope="col">Value</th>
</tr>
</thead>
<tbody>
<tr>
<th class="role-abstract-head" scope="row">Is Abstract:</th>
<td class="role-abstract"> </td>
</tr>
<tr>
<th class="role-parent-head" scope="row">Superclass Role:</th>
<td class="role-parent"><rref>section</rref></td>
</tr>
<tr>
<th class="role-children-head" scope="row">Subclass Roles:</th>
<td class="role-children">Placeholder</td>
</tr>
<tr>
<th class="role-base-head" scope="row">Base Concept:</th>
<td class="role-base"> </td>
</tr>
<tr>
<th class="role-related-head" scope="row">Related Concepts:</th>
<td class="role-related"><a href="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-common-elements-alert">XForms alert</a></td>
</tr>
<tr>
<th class="role-scope-head" scope="row">Required Context Role:</th>
<td class="role-scope"> </td>
</tr>
<tr>
<th class="role-mustcontain-head" scope="row">Required Owned Elements:</th>
<td class="role-mustcontain"> </td>
</tr>
<tr>
<th class="role-required-properties-head">Required States and Properties:</th>
<td class="role-required-properties"> </td>
</tr>
<tr>
<th class="role-properties-head" scope="row">Supported States and Properties:</th>
<td class="role-properties"> </td>
</tr>
<tr>
<th class="role-inherited-head" scope="row">Inherited States and Properties:</th>
<td class="role-inherited">Placeholder</td>
</tr>
<tr>
<th class="role-namefrom-head" scope="row">Name From:</th>
<td class="role-namefrom">author</td>
</tr>
<tr>
<th class="role-namerequired-head" scope="row">Accessible Name Required:</th>
<td class="role-namerequired"> </td>
</tr>
<tr>
<th class="role-namerequired-inherited-head" scope="row">Inherits Name Required:</th>
<td class="role-namerequired-inherited"> </td>
</tr>
<tr>
<th class="role-childpresentational-head" scope="row">Children Presentational:</th>
<td class="role-childpresentational"> </td>
</tr>
<tr>
<th class="role-presentational-inherited-head" scope="row">Inherits Presentational:</th>
<td class="role-presentational-inherited"> </td>
</tr>
<tr>
<th class="implicit-values-head">Implicit Value for Role:</th>
<td class="implicit-values">
Default for <pref>aria-live</pref> is <code class="default">assertive</code>.<br/>
Default for <pref>aria-atomic</pref> is <code class="default">true</code>.
</td>
</tr>
</tbody>
</table>
</div>
<div class="role" id="alertdialog">
<rdef>alertdialog</rdef>
<div class="role-description">
<p>A type of dialog that contains an alert message, where initial focus goes to an <a>element</a> within the dialog. See related <rref>alert</rref> and <rref>dialog</rref>.</p>
<p>Alert dialogs are used to convey messages to alert the user. The <code>alertdialog</code> <a>role</a> goes on the node containing both the alert message and the rest of the dialog. Content authors SHOULD make alert dialogs modal by ensuring that, while the <code>alertdialog</code> is shown, keyboard and mouse interactions only operate within the dialog. See <pref>aria-modal</pref> [ARIA 1.1].</p>
<p>Unlike <rref>alert</rref>, <code>alertdialog</code> can receive a response from the user. For example, to confirm that the user understands the alert being generated. When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog, such as a form edit field or an OK button. The <a>user agent</a> SHOULD fire a system alert <a>event</a> through the accessibility API when the alert is created, provided one is specified by the intended <a>accessibility <abbr title="Application Programing Interfaces">API</abbr></a>.</p>
<p>Authors SHOULD use <pref>aria-describedby</pref> on an <code>alertdialog</code> to reference the alert message element in the dialog. If they do not, an <a>assistive technology</a> can resort to its internal recovery mechanism to determine the contents of the alert message.</p>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
<thead>
<tr>
<th scope="col">Characteristic</th>
<th scope="col">Value</th>
</tr>
</thead>
<tbody>
<tr>
<th class="role-abstract-head" scope="row">Is Abstract:</th>
<td class="role-abstract"> </td>
</tr>
<tr>
<th class="role-parent-head" scope="row">Superclass Role:</th>
<td class="role-parent">
<ul>
<li><rref>alert</rref></li>
<li><rref>dialog</rref></li>
</ul>
</td>
</tr>
<tr>
<th class="role-children-head" scope="row">Subclass Roles:</th>
<td class="role-children">Placeholder</td>
</tr>
<tr>
<th class="role-base-head" scope="row">Base Concept:</th>
<td class="role-base"> </td>
</tr>
<tr>
<th class="role-related-head" scope="row">Related Concepts:</th>
<td class="role-related"><a href="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-common-elements-alert">XForms alert</a></td>
</tr>
<tr>
<th class="role-scope-head" scope="row">Required Context Role:</th>
<td class="role-scope"> </td>
</tr>
<tr>
<th class="role-mustcontain-head" scope="row">Required Owned Elements:</th>
<td class="role-mustcontain"> </td>
</tr>
<tr>
<th class="role-required-properties-head">Required States and Properties:</th>
<td class="role-required-properties"> </td>
</tr>
<tr>
<th class="role-properties-head" scope="row">Supported States and Properties:</th>
<td class="role-properties"> </td>
</tr>
<tr>
<th class="role-inherited-head" scope="row">Inherited States and Properties:</th>
<td class="role-inherited">Placeholder</td>
</tr>
<tr>
<th class="role-namefrom-head" scope="row">Name From:</th>
<td class="role-namefrom">author</td>
</tr>
<tr>
<th class="role-namerequired-head" scope="row">Accessible Name Required:</th>
<td class="role-namerequired">True</td>
</tr>
<tr>
<th class="role-namerequired-inherited-head" scope="row">Inherits Name Required:</th>
<td class="role-namerequired-inherited"> </td>
</tr>
<tr>
<th class="role-childpresentational-head" scope="row">Children Presentational:</th>
<td class="role-childpresentational"> </td>
</tr>
<tr>
<th class="role-presentational-inherited-head" scope="row">Inherits Presentational:</th>
<td class="role-presentational-inherited"> </td>
</tr>
</tbody>
</table>
</div>
<div class="role" id="application">
<rdef>application</rdef>
<div class="role-description">
<p>A <rref>structure</rref> containing one or more focusable elements requiring user input, such as keyboard or gesture events, that do not follow a standard interaction pattern supported by a <rref>widget</rref> role.</p>
<p>Some <a>user agents</a> and <a>assistive technologies</a> have a browse mode where standard input events, such as up and down arrow key events, are intercepted and used to control a reading cursor. This browse mode behavior prevents elements that do not have a <rref>widget</rref> role from receiving and using such keyboard and gesture events to provide interactive functionality.</p>
<p>When there is a need to create an element with an interaction model that is not supported by any of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <rref>widget</rref> roles, authors MAY give that element role <code>application</code>. And, when a user navigates into an element with role <code>application</code>, <a>assistive technologies</a> that intercept standard input events SHOULD switch to a mode that passes most or all standard input events through to the web application.</p>
<p>For example, a presentation slide editor uses arrow keys to change the positions of textbox and image elements on the slide. There are not any WAI-ARIA <rref>widget</rref> roles that correspond to such an interaction model so an author could give the slide container role <code>application</code>, an <pref>aria-roledescription</pref> of "Slide Editor", and use <pref>aria-describedby</pref> to provide instructions.</p>
<p> Because only the focusable elements contained in an <code>application</code> element are accessible to users of some assistive technologies, authors MUST use one of the following techniques to ensure all non-decorative static text or image content inside an application is accessible:</p>
<ol>
<li>Associate the content with a focusable element using <pref>aria-labelledby</pref> or <pref>aria-describedby</pref>.</li>
<li>Place the content in a focusable element that has role <rref>document</rref> or <code>article</code>.</li>
</ol>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
<thead>
<tr>
<th scope="col">Characteristic</th>
<th scope="col">Value</th>
</tr>
</thead>
<tbody>
<tr>
<th class="role-abstract-head" scope="row">Is Abstract:</th>
<td class="role-abstract"> </td>
</tr>
<tr>
<th class="role-parent-head" scope="row">Superclass Role:</th>
<td class="role-parent"><rref>structure</rref></td>
</tr>
<tr>
<th class="role-children-head" scope="row">Subclass Roles:</th>
<td class="role-children">Placeholder</td>
</tr>
<tr>
<th class="role-base-head" scope="row">Base Concept:</th>
<td class="role-base"> </td>
</tr>
<tr>
<th class="role-related-head" scope="row">Related Concepts:</th>
<td class="role-related"><a href="http://www.w3.org/TR/di-gloss/#def-delivery-unit">Device Independence Delivery Unit</a></td>
</tr>
<tr>
<th class="role-scope-head" scope="row">Required Context Role:</th>
<td class="role-scope"> </td>
</tr>
<tr>
<th class="role-mustcontain-head" scope="row">Required Owned Elements:</th>
<td class="role-mustcontain"> </td>
</tr>
<tr>
<th class="role-required-properties-head">Required States and Properties:</th>
<td class="role-required-properties"> </td>
</tr>
<tr>
<th class="role-properties-head" scope="row">Supported States and Properties:</th>
<td class="role-properties"> </td>
</tr>
<tr>
<th class="role-inherited-head" scope="row">Inherited States and Properties:</th>
<td class="role-inherited">Placeholder</td>
</tr>
<tr>
<th class="role-namefrom-head" scope="row">Name From:</th>
<td class="role-namefrom">author</td>
</tr>
<tr>
<th class="role-namerequired-head" scope="row">Accessible Name Required:</th>
<td class="role-namerequired">True</td>
</tr>
<tr>
<th class="role-namerequired-inherited-head" scope="row">Inherits Name Required:</th>
<td class="role-namerequired-inherited"> </td>
</tr>
<tr>
<th class="role-childpresentational-head" scope="row">Children Presentational:</th>
<td class="role-childpresentational"> </td>
</tr>
<tr>
<th class="role-presentational-inherited-head" scope="row">Inherits Presentational:</th>
<td class="role-presentational-inherited"> </td>
</tr>
</tbody>
</table>
</div>
<div class="role" id="article">
<rdef>article</rdef>
<div class="role-description">
<p>A section of a page that consists of a composition that forms an independent part of a document, page, or site.</p>
<p>An article is not a navigational <a>landmark</a>, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content. It is <em>independent</em> in that its contents could stand alone, for example in syndication. However, the <a>element</a> is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well. When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.</p>
<p>When the user navigates an element assigned the role of <code>article</code>, <a>assistive technologies</a> that typically intercept standard keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. Assistive technologies MAY provide a feature allowing the user to navigate the hierarchy of any nested <code>article</code> elements.</p>
<p>When an <code>article</code> is in the context of a <rref>feed</rref>, the author MAY specify values for <pref>aria-posinset</pref> and <pref>aria-setsize</pref>.</p>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
<thead>
<tr>
<th scope="col">Characteristic</th>
<th scope="col">Value</th>
</tr>
</thead>
<tbody>
<tr>
<th class="role-abstract-head" scope="row">Is Abstract:</th>
<td class="role-abstract"> </td>
</tr>
<tr>
<th class="role-parent-head" scope="row">Superclass Role:</th>
<td class="role-parent"><rref>document</rref></td>
</tr>
<tr>
<th class="role-children-head" scope="row">Subclass Roles:</th>
<td class="role-children">Placeholder</td>
</tr>
<tr>
<th class="role-base-head" scope="row">Base Concept:</th>
<td class="role-base"> </td>
</tr>
<tr>
<th class="role-related-head" scope="row">Related Concepts:</th>
<td class="role-related"><abbr title="Hypertext Markup Language">HTML</abbr> 5 <a href="http://www.w3.org/TR/html5/sections.html#the-article-element">article</a></td>
</tr>
<tr>
<th class="role-scope-head" scope="row">Required Context Role:</th>
<td class="role-scope"> </td>
</tr>
<tr>
<th class="role-mustcontain-head" scope="row">Required Owned Elements:</th>
<td class="role-mustcontain"> </td>
</tr>
<tr>
<th class="role-required-properties-head">Required States and Properties:</th>
<td class="role-required-properties"> </td>
</tr>
<tr>
<th class="role-properties-head" scope="row">Supported States and Properties:</th>
<td class="role-properties">
<ul>
<li><pref>aria-posinset</pref></li>
<li><pref>aria-setsize</pref></li>
</ul>
</td>
</tr>
<tr>
<th class="role-inherited-head" scope="row">Inherited States and Properties:</th>
<td class="role-inherited">Placeholder</td>
</tr>
<tr>
<th class="role-namefrom-head" scope="row">Name From:</th>
<td class="role-namefrom">author</td>
</tr>
<tr>
<th class="role-namerequired-head" scope="row">Accessible Name Required:</th>
<td class="role-namerequired"> </td>
</tr>
<tr>
<th class="role-namerequired-inherited-head" scope="row">Inherits Name Required:</th>
<td class="role-namerequired-inherited"> </td>
</tr>
<tr>
<th class="role-childpresentational-head" scope="row">Children Presentational:</th>
<td class="role-childpresentational"> </td>
</tr>
<tr>
<th class="role-presentational-inherited-head" scope="row">Inherits Presentational:</th>
<td class="role-presentational-inherited"> </td>
</tr>
</tbody>
</table>
</div>
<div class="role" id="banner">
<rdef>banner</rdef>
<div class="role-description">
<p>A region that contains mostly site-oriented content, rather than page-specific content.</p>
<p>Site-oriented content typically includes things such as the logo or identity of the site sponsor, and site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.</p>
<p>User agents SHOULD treat elements with the role of <code>banner</code> as navigational <a>landmarks</a>.</p>
<!-- keep the following paragraphs synced with the similar paragraphs in #main and #contentinfo-->
<p>Within any <rref>document</rref> or <rref>application</rref>, the author SHOULD mark no more than one <a>element</a> with the <code>banner</code> <a>role</a>.</p>
<p class="note">Because <code>document</code> and <code>application</code> elements can be nested in the <abbr title="Document Object Model">DOM</abbr>, they may have multiple <code>banner</code> elements as <abbr title="Document Object Model">DOM</abbr> descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., <rref>document</rref> within <rref>document</rref>) or by use of the <pref>aria-owns</pref> <a>attribute</a>.</p>
</div>
<table class="role-features">
<caption>Characteristics:</caption>
<thead>
<tr>
<th scope="col">Characteristic</th>
<th scope="col">Value</th>
</tr>
</thead>
<tbody>
<tr>
<th class="role-abstract-head" scope="row">Is Abstract:</th>
<td class="role-abstract"> </td>
</tr>
<tr>
<th class="role-parent-head" scope="row">Superclass Role:</th>
<td class="role-parent"><rref>landmark</rref></td>
</tr>
<tr>
<th class="role-children-head" scope="row">Subclass Roles:</th>
<td class="role-children">Placeholder</td>
</tr>
<tr>
<th class="role-base-head" scope="row">Base Concept:</th>
<td class="role-base"> </td>
</tr>
<tr>
<th class="role-related-head" scope="row">Related Concepts:</th>
<td class="role-related"> </td>
</tr>
<tr>
<th class="role-scope-head" scope="row">Required Context Role:</th>
<td class="role-scope"> </td>
</tr>
<tr>