index.html
119 KB
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><title>WAI-ARIA 1.0 Primer</title><meta content="text/html; charset=utf-8" http-equiv="Content-Type"/><style type="text/css" xml:space="preserve">
/* Styles from old version */
div.body img {
padding: 1em;
}
div.body p.figure {
text-align: center;
font-weight: bold;
}
ol.tocline {
margin: 0;
padding: 0;
list-style: none;
padding-left: 1.25em;
}
code {
FONT-FAMILY: monospace
}
div.constraint {
MARGIN-LEFT: 2em
}
div.issue {
MARGIN-LEFT: 2em
}
div.note {
MARGIN-LEFT: 2em
}
div.notice {
MARGIN-LEFT: 2em
}
dt {
margin-bottom: 0;
padding-bottom: 0;
margin-top: .5em;
}
dd {
margin-top: 0;
padding-top: 0;
}
li p {
MARGIN-TOP: 0.3em; MARGIN-BOTTOM: 0.3em
}
td, th {
vertical-align: top;
}
div.exampleInner pre {
MARGIN-TOP: 0em; MARGIN-BOTTOM: 0em; MARGIN-LEFT: 1em
}
div.exampleOuter {
BORDER-RIGHT: gray 4px double; PADDING-RIGHT: 0em; BORDER-TOP: gray 4px double; PADDING-LEFT: 0em; PADDING-BOTTOM: 0em; MARGIN: 0em; BORDER-LEFT: gray 4px double; PADDING-TOP: 0em; BORDER-BOTTOM: gray 4px double
}
div.exampleInner {
PADDING-RIGHT: 4px; BORDER-TOP: #d3d3d3 4px double; PADDING-LEFT: 4px; PADDING-BOTTOM: 4px; MARGIN: 0em; PADDING-TOP: 4px; BORDER-BOTTOM: #d3d3d3 4px double; BACKGROUND-COLOR: #d5dee3
}
div.exampleWrapper {
MARGIN: 4px
}
div.exampleHeader {
FONT-WEIGHT: bold; MARGIN: 4px
}
.xmlverb-default {
COLOR: #333333; FONT-FAMILY: monospace; BACKGROUND-COLOR: #ffffff
}
.xmlverb-element-name {
COLOR: #990000
}
.xmlverb-element-nsprefix {
COLOR: #666600
}
.xmlverb-attr-name {
COLOR: #660000
}
.xmlverb-attr-content {
FONT-WEIGHT: bold; COLOR: #000099
}
.xmlverb-ns-name {
COLOR: #666600
}
.xmlverb-ns-uri {
COLOR: #330099
}
.xmlverb-text {
FONT-WEIGHT: bold; COLOR: #000000
}
.xmlverb-comment {
COLOR: #006600; FONT-STYLE: italic
}
.xmlverb-pi-name {
COLOR: #006600; FONT-STYLE: italic
}
.xmlverb-pi-content {
COLOR: #006666; FONT-STYLE: italic
}
div.exampleInner1 { PADDING-RIGHT: 4px; BORDER-TOP: #d3d3d3 4px double; PADDING-LEFT: 4px; PADDING-BOTTOM: 4px; MARGIN: 0em; PADDING-TOP: 4px; BORDER-BOTTOM: #d3d3d3 4px double; BACKGROUND-COLOR: #d5dee3
}
</style><link href="spec.css" rel="stylesheet" type="text/css"/><link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css"/></head><body>
<p align="center">[<a href="#toc">contents</a>]</p>
<div class="head"> <a href="http://www.w3.org/"><img alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home" width="72"/></a>
<h1><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.0 Primer</h1>
<h2 id="subhead">An introduction to rich Internet application accessibility challenges and solutions</h2>
<h2 class="maturity">W3C Working Draft 16 September 2010</h2>
<dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916/">http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916/</a></dd><dt>Latest version:</dt><dd> <a href="http://www.w3.org/TR/wai-aria-primer/">http://www.w3.org/TR/wai-aria-primer/</a> </dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2008/WD-wai-aria-primer-20080204/">http://www.w3.org/TR/2008/WD-wai-aria-primer-20080204/</a></dd><dt>Editors: </dt><dd>Lisa Pappas, SAS and STC <br clear="none"/>
Richard Schwerdtfeger, IBM<br clear="none"/>
Michael Cooper, W3C </dd></dl>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2008 - 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
<hr title="Separator from Header"/>
</div>
<div><a id="abstract" name="abstract"></a>
<h2> Abstract</h2>
<p>The <acronym title="Web Accessibility Initiative">WAI</acronym>-<acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Primer introduces developers to the use of <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">WAI-ARIA</a></cite> [<cite><a href="#ref_ARIA">ARIA</a></cite>] for addressing the
accessibility of dynamic Web content for people with disabilities.
This primer explains the accessibility problems posed by hybrid technologies
such as Dynamic Hypertext Markup Language (DHTML) and Asynchronous Java and XML (Ajax). It introduces the technologies to map controls, Ajax live regions, and
events to accessibility application programming interfaces (APIs), including custom controls used for Rich Internet Applications. The
primer also describes new navigation techniques to mark common Web
elements with roles such as menus, primary content, secondary content, banner
information and other types of Web structures. These new
technologies can be used to improve the accessibility and usability
of Web resources by people with disabilities, without extensive
modification to existing libraries of Web resources. This document is part of the WAI-ARIA suite described in the <a href="http://www.w3.org/WAI/intro/aria.php">WAI-ARIA Overview</a>.</p>
</div>
<div><a id="sotd" name="sotd"></a>
<h2>Status of This Document</h2>
<p><em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em> </p>
<p>This is a Public Working Draft by the <a href="http://www.w3.org/WAI/PF/">Protocols & Formats
Working Group</a> of the <a href="http://www.w3.org/WAI/">Web Accessibility
Initiative</a>. It supports the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">Accessible
Rich Internet Applications (WAI-ARIA)</a></cite> [<cite><a href="#ref_ARIA">ARIA</a></cite>]
specification, providing introductory information about the accessibility
problem that WAI-ARIA is intended to solve and explaining the technical
approach. This version contains information that was previously in
the WAI-ARIA specification itself but was deemed introductory and distracting
from the main goal of defining Accessible Rich Internet Application
features. That information is, however, important for many people to
understand WAI-ARIA fully so is provided in this resource. A <a href="http://www.w3.org/WAI/PF/aria-primer/change-history">history
of changes to WAI-ARIA 1.0 Primer</a> is available. The <a href="http://www.w3.org/WAI/PF/comments/actions?document_version_id%5B%5D=1&document_version_id%5B%5D=6">summary
of actions made in response to comments on the previous two WAI-ARIA
1.0 drafts</a> includes
changes that affected this document. </p>
<p>The PFWG seeks feedback on the information explained in this document.
The PFWG asks in particular:</p>
<ul><li>Is the relationship of WAI-ARIA to accessibility clear?</li><li>Are there issues with the implementation of WAI-ARIA in the various
technologies affected? </li></ul>
<p>Start with the <a href="http://www.w3.org/WAI/PF/comments/instructions">instructions
for commenting</a> page to submit comments (preferred), or send email to <a href="mailto:public-pfwg-comments@w3.org">public-pfwg-comments@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-pfwg-comments/">comment archive</a>). Comments should be made by <strong>29 October 2010</strong>. In-progress updates to the document may be viewed
in the <a href="/WAI/PF/aria-primer/">publicly visible editors' draft</a>.</p>
<p>Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>
<p> This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. The group does not expect this document to become a W3C Recommendation. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/32212/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>
<p>The disclosure obligations of the Participants of this group are described in the <a href="http://www.w3.org/WAI/PF/charter201006#patentpolicy">charter</a>.</p>
</div>
<div><a id="toc" name="toc"></a>
<h2>Table of Contents</h2>
<ol class="toc"><li>1. <a href="#intro">Introduction</a><ol class="toc"><li>1.1. <a href="#problemstatement">The Problem</a></li><li>1.2. <a href="#requirements">Requirements</a></li><li>1.3. <a href="#solution">Solution</a></li><li>1.4. <a href="#html_support">HTML Accessibility API Support Analysis</a></li></ol></li><li>2. <a href="#Fill">Filling the Gaps for Content Delivered to Desktop Browsers</a><ol class="toc"><li>2.1. <a href="#new_provisions">Use of New Provisions for Keyboard Focus and Semantics to Support Platform Accessibility APIs</a><ol class="toc"><li>2.1.1. <a href="#role">Provision of the Role Attribute: "What is the Object?"</a></li><li>2.1.2. <a href="#properties">Provision of the Accessibility State Information: "What meaningful properties does this object have at this time?"</a></li><li>2.1.3. <a href="#focus">Provision of the Keyboard or Input Focus: "What object am I working on?"</a></li><li>2.1.4. <a href="#ariahtml">Supporting WAI-ARIA in XHTML and HTML 4.01</a></li></ol></li><li>2.2. <a href="#landmarks">Use of XHTML Role Landmarks to Improve Document Navigation</a></li><li>2.3. <a href="#extsemantics">WAI-ARIA Role Taxonomy - Extensible Semantic Role Model, using RDF/OWL</a><ol class="toc"><li>2.3.1. <a href="#temp">Interoperability Example: Grid Role</a></li></ol></li><li>2.4. <a href="#Events">Accessibility Events and Event Handling</a></li><li>2.5. <a href="#alookahead">HTML 5 - A Look Ahead</a></li></ol></li><li>3. <a href="#buildingaccessibleapplications">Building Accessible Applications with WAI-ARIA</a><ol class="toc"><li>3.1. <a href="#exampletree">Example: Building a Tree Widget</a></li></ol></li><li>4. <a href="#reasons">Reasons for Adopting WAI-ARIA</a><ol class="toc"><li>4.1. <a href="#tech_reasons">Technical Benefits</a></li><li>4.2. <a href="#biz_reasons">Business Benefits</a></li></ol></li><li>5. <a href="#conclusions">Conclusions</a></li><li>6. <a href="#appendix">Appendices</a><ol class="toc"><li>6.1. <a href="#gaphtml">Gap Analysis - Filling the Gaps for (X)HTML in Support of Accessibility API</a></li><li>6.2. <a href="#longdesc">Long Descriptions of Figures</a><ol class="toc"><li>6.2.1. <a href="#ld_fig1">Long Description of Figure 1.0 Accessibility Interoperability at a DOM Node without JavaScript</a></li><li>6.2.2. <a href="#ld_fig2">Long Description of Figure 2.0 Accessibility Interoperability at a DOM Node with JavaScript</a></li></ol></li><li>6.3. <a href="#references">References</a></li><li>6.4. <a href="#acknowledgements">Acknowledgments</a><ol class="toc"><li>6.4.1. <a href="#ack_group">Participants in the PFWG at the time of publication</a></li><li>6.4.2. <a href="#ack_others">Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification</a></li><li>6.4.3. <a href="#ack_funders">Enabling funders</a></li></ol></li></ol></li></ol>
</div>
<div class="section" id="intro">
<h2><span class="tocnum">1. </span> Introduction</h2>
<p>According to the <a href="http://www.securityspace.com/s_survey/data/man.200607/techpen.html">SecuritySpace Technology Penetration Report</a>, more than 55% of all Web sites today contain JavaScript, dramatically affecting the ability for persons with disabilities to access Web content. New Rich Internet Applications (RIAs) render custom widgets, modeling rich desktop components to perform UI updates without having to reload the entire page - much like a graphical user interface (GUI). Legacy GUI accessibility frameworks address these issues through a comprehensive accessibility application programming interface (API) and infrastructure to foster interoperability with assistive technologies. These APIs constitute a contract between applications and assistive technologies, such as screen readers, to enable them to access rich dynamic content with the appropriate semantics needed to produce a usable alternative. No such contract exists between modern RIAs and assistive technologies, creating an accessibility gap for persons with disabilities.</p>
<p>Unfortunately, HTML and other markup languages do not provide adequate
support for accessible dynamic content. Until now, the <acronym title="World Wide Web Consortium">W3C</acronym> <acronym title="Web Accessibility Initiative">WAI</acronym> has discouraged the use of JavaScript per <cite><a href="http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-scripts">Web
Content Accessibility Guidelines (WCAG) 1.0</a></cite> ([<cite><a href="#ref_WCAG1">WCAG1</a></cite>], Checkpoint 6.1).
A
number of W3C initiatives underway address this problem using
a declarative markup approach. This primer describes a means to
bridge the interoperability problem with assistive
technologies now by incorporating the appropriate metadata into
current HTML and XHTML markup to support today's accessibility <acronym title="Application Programming Interfaces">API</acronym>s. Moreover, the primer provides web developers with a conceptual understanding of WAI-ARIA as a prelude to using the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">WAI-ARIA specification</a></cite> [<cite><a href="#ref_ARIA">ARIA</a></cite>]. WAI-ARIA brings advanced accessibility features of the desktop to the web through the creation of cross-cutting technologies that
(X)HTML authors can incorporate in their markup. WAI-ARIA defines roles, states, and properties, where those roles reflect standard GUI elements that are recognized by accessility Application Programming Interfaces (APIs). These metadata that describes these
GUI widgets and document structures aides assistive technology
vendors in providing accessible, usable solutions. The <acronym title="World Wide Web Consortium">W3C</acronym> <acronym title="Web Accessibility Initiative">WAI</acronym> <acronym title="Process and Formats">PF</acronym> working group is working with User Agent manufacturers, assistive
technology vendors, and accessibility tool providers, to ensure an end-to-end working solution.</p>
<p>For an introduction to WAI-ARIA, see the <a href="http://www.w3.org/WAI/intro/aria.php">Accessible Rich Internet Applications Suite (WAI-ARIA) Overview</a>. The WAI-ARIA Primer is part of a set of resources that support the WAI-ARIA specification. The Primer provides a basic introduction to the concepts behind and reason for WAI-ARIA, and the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/">WAI-ARIA Authoring Practices</a></cite> [<cite><a href="#ref_ARIA-PRACTICES">ARIA-PRACTICES</a></cite>] describe recommended usage patterns for Web content developers. The WAI-ARIA Suite fills gaps identified by the <cite><a href="http://www.w3.org/TR/wai-aria-roadmap/">Roadmap
for Accessible Rich Internet Applications (<acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Roadmap)</a></cite> [<cite><a href="#ref_ARIA-ROADMAP">ARIA-ROADMAP</a></cite>]. These documents serve as important places of clarification where topics appear to be unclear.</p>
<div class="section" id="problemstatement">
<h3><span class="tocnum">1.1. </span> The Problem</h3>
<p>Aspects of traditional Hypertext Markup Language (HTML) make accessible support of dynamic content difficult:</p>
<ol><li>Accessibility of dynamic content relies on abstracting semantics from both content and presentational information. Extracting semantic cues from current HTML content is typically unreliable as the cues are limited to tag elements names. </li><li>While HTML allows content to be repurposed for presentational formatting, it lacks the ability to attach meaningful metadata about document structure and to convey semantic information. A common example of this is content formatted with tables rather than style sheets. </li><li>When combined with script and cascading style sheets (CSS), HTML can be repurposed to create dynamic custom components without providing a means to convey semantic information to native accessibility architectures designed to support dynamic graphical user interface (GUI) content. </li><li>Custom components built from common HTML elements often are not keyboard accessible. </li></ol>
<p>Authors of JavaScript-generated content do not want to limit themselves to using standard tag elements that define the actual user interface element such as tables, ordered lists, etc. Rather, they make extensive use of elements such as <code>DIV</code> tags in which they dynamically apply a <acronym title="user interface">user interface (UI)</acronym> through the use of style sheets and dynamic content changes. HTML <code>DIV</code> tags provide no semantic information. For example, authors may define a <code>DIV</code> as the start of a pop-up menu or even an ordered list. However, no HTML mechanism exists to: </p>
<ul><li>Identify the role of the <code>DIV</code> as a pop-up menu </li><li>Alert assistive technology when these elements have focus </li><li>Convey accessibility property information, such as whether the pop-up menu is collapsed or expanded </li><li>Define what actions can be formed on the element other than through a device-dependent means through the event handler type (onmouseover, onclick, etc.)</li></ul>
<p>In short, JavaScript needs an accessibility architecture to write to such that a solution can be mapped to the accessibility
frameworks on the native platform by the user agent.</p>
<p>The following diagram illustrates a typical <acronym title="Document Object Model"><acronym title="Document Object Model">document object model (DOM)</acronym></acronym> node in
a Model-View-Controller architecture. Accessibility information surfaced to assitive technologies is provided only by the HTML element's tag name, with only the accessibility attributes that tag can provide.</p>
<p><a href="#fig1">Figure 1.0</a> shows that on the node, data, or the
"Model", which should include semantic information, is separated
from the user interface presentation, the "View." Here, the
document element is managed by the user agent based on the default
behavior of the element. The user agent's default behavior at the
document element forms the controller. </p>
<p class="figure"><a id="fig1" name="fig1"></a> <img alt="Accessibility infomation mapped to a DOM element in the Document Object Model" height="512" longdesc="#ld_fig1" src="accessibleelement.png" width="640"/> <br clear="none"/>
Figure 1.0 Accessibility
Interoperability at a <acronym title="document object model">DOM</acronym> Node without JavaScript</p>
<p id="desc_fig1">The box between the DOM node
and the assistive technology contains the contract
provided by the user agent to the assistive technology. This data
includes typical accessibility information found in the
accessibility API for many accessible platforms for GUIs
(role, state, caret, selection, text, hypertext, name
description, parent/child information, parent/child
information, and relations). For HTML and other W3C markup, the
accessibility information provided solely depends upon what the element's tag name and any accessibility attributes that map to that tag provides. For example, the accessible role of a table is <code>table</code>. The author provides an accessible description by assigning a <code>title</code> attribute.</p>
<p>In contrast, with JavaScript, user actions can trigger updates in the data and presentation, but the default accessibility information available in the element tags is no longer valid.</p>
<p class="figure"><a id="fig2" name="fig2"></a> <img alt="DOM Element with JavaScript controller" border="0" height="502" longdesc="#ld_fig2" src="accessibleJSelement.png" width="476"/> <br clear="none"/>
Figure 2.0 Accessibility
Interoperability at a DOM Node with JavaScript</p>
<p id="desc_fig2"> <a href="#fig2">Figure 2.0</a> shows the same DOM node provided
in Figure 1.0 but with JavaScript acting as the new controller.
JavaScript overrides the default user agent behavior at the DOM
node. It manipulates the data, content, and style in response to
events caused by user interaction to produce custom widgets. In
this situation, the default accessibility information is no longer
valid and, therefore, the contract is now invalid. Figure 2.0 shows
the contract with asterisks in front of role, state, actions,
value, event changes, and relations. These asterisks represent
potential accessibility errors and gaps in the base markup. These
gaps result from the author's inability to provide the new semantic
data needed to support the contract.</p>
</div>
<div class="section" id="requirements">
<h3><span class="tocnum">1.2. </span> Requirements</h3>
<p>Any solution to facilitate the creation of accessible rich Internet applications (RIAs) must:</p>
<dl><dt class="label">Allow for discovery of custom UI components
through the use of Semantic Web technologies</dt><dd>Web ontologies allow for storage of semantic information about
objects and how they relate to others in the ontology.</dd><dt class="label">Support today's accessibility
architectures</dt><dd>Accessibility architecture today is centered around object
technology. Each object in an application or document exposes
its accessible properties to an assistive
technology.</dd><dt class="label">Allow for separation of content and
presentation</dt><dd>Dynamic content authors must be able to store the accessible
meta data in the document independent of how it is rendered.</dd><dt class="label">Allow for passive monitoring of the application
by an assistive technology</dt><dd>Assistive technology vendors should not be required to poll an
application for changes in accessibility information.</dd><dt class="label">Leverage new W3C efforts to solve the
problem</dt><dd>This problem needs to be solved quickly. A number of
efforts are underway, such that minimal changes may be required to
bring them to the level needed.</dd><dt class="label">Be light weight</dt><dd>The solution needs to be light-weight in order to promote adoption by Web authors.</dd><dt class="label">Scaleable</dt><dd>The solution needs to be scalable; it must make simple things
easy while making complex things possible.</dd><dt class="label">Internationalizable</dt><dd>Like other Web solutions, our solutions must be
internationalizable.</dd><dt class="label">Guarantee user agent support up front</dt><dd>User agent manufacturers must be involved up front to ensure support for the solution when the specification is complete.</dd><dt class="label">Involve assistive technology vendors up
front</dt><dd>To ensure interoperability, assistive technology vendors need to be involved from day one.
The effort must leverage support by AT vendors to ensure that a
total solution is available when the specification is complete.</dd><dt class="label">Produce Developer Guidelines during the
process</dt><dd>This is a critical mistake made by people creating a new
accessibility model. Developers must be engaged early on so that
they can contribute feedback and start producing workable solutions
early.</dd></dl>
</div>
<div class="section" id="solution">
<h3><span class="tocnum">1.3. </span> Solution</h3>
<p>What is clear from the problem statement is that developers of dynamic web content cannot provide the appropriate accessibility information in the markup to support the accessibility APIs on the target platform. This problem is not limited to HTML. It extends to other markup, including <a href="http://www.w3.org/Graphics/SVG/">Scaleable Vector Graphics</a> [SVG]. This primer addresses the problem for web content delivered to desktop browsers and introduces you to common extensions to both HTML and XHTML called <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">Accessible Rich Internet Applications (WAI-ARIA) Version 1.0</a></cite> [<cite><a href="#ref_ARIA">ARIA</a></cite>]. The goal is to make these standard features in HTML 5. </p>
</div>
<div class="section" id="html_support">
<h3><span class="tocnum">1.4. </span> HTML Accessibility API Support Analysis</h3>
<p>Using <a href="#fig1">Figure 1.0</a> as a template for addressing the
problem and <a href="http://www.section508.gov/">U.S. Section 508</a> accessibility standards, <a href="#t1">Table 1.0</a> illustrates gaps
in the infrastructure and identifies W3C standards that should be used to
address the problem. In the right column, table cells that are empty
or that indicate a limitation represent accessibility gaps in HTML
and XHTML.</p>
<table border="1"><caption>
<a id="t1" name="t1"></a>Table 1.0 Platform Gap Analysis
for Accessible Dynamic Web Content for HTML and XHTML
</caption><tbody><tr><th rowspan="1" colspan="1">Required Components</th><th rowspan="1" colspan="1">Who does what today? (HTML)</th></tr><tr><th align="left" rowspan="1" colspan="1">Events:</th><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">FocusChange</td><td rowspan="1" colspan="1">DOM 2, 3 events</td></tr><tr><td rowspan="1" colspan="1">Activation</td><td rowspan="1" colspan="1">User Agent API</td></tr><tr><td rowspan="1" colspan="1">Caret Change</td><td rowspan="1" colspan="1">User Agent API</td></tr><tr><td rowspan="1" colspan="1">Value Change</td><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">State Change</td><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">Selection Change</td><td rowspan="1" colspan="1">User Agent API</td></tr><tr><td rowspan="1" colspan="1">Mutation</td><td rowspan="1" colspan="1">DOM Events</td></tr><tr><th align="left" rowspan="1" colspan="1">Accessible
Actions:</th><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">Event Handler functional information to label the actions</td><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">Access to the available event
handlers for enumerating the actions</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">State Information:</th><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Role Information:</th><td rowspan="1" colspan="1">Limited to standard HTML tag names. (Mix
Content/presentation)</td></tr><tr><th align="left" rowspan="1" colspan="1">Relationships: Parent/child</th><td rowspan="1" colspan="1">Limited DOM (affected by style) (Mix Content/presentation)</td></tr><tr><th align="left" rowspan="1" colspan="1">Relationships: (Label, MemberOf - Group,
ControllerFor)</th><td rowspan="1" colspan="1">Limited to HTML (Title, alt, label)</td></tr><tr><th align="left" rowspan="1" colspan="1">Text</th><td rowspan="1" colspan="1">Core DOM from parsed HTML</td></tr><tr><th align="left" rowspan="1" colspan="1">Content selection:</th><td rowspan="1" colspan="1">Browser-dependent (incomplete)</td></tr><tr><th align="left" rowspan="1" colspan="1">Font/Font Style Information:</th><td rowspan="1" colspan="1">Can set but can't get final format</td></tr><tr><th align="left" rowspan="1" colspan="1">Description/Help:</th><td rowspan="1" colspan="1">Limited to HTML 4.0 - Alt Text, title text</td></tr><tr><th align="left" rowspan="1" colspan="1">Accessible value:</th><td rowspan="1" colspan="1">Limited to form elements</td></tr><tr><th align="left" rowspan="1" colspan="1">Coordinates (Bounding rectangle, etc.):</th><td rowspan="1" colspan="1">User Agents. platform accessibility API</td></tr><tr><th align="left" rowspan="1" colspan="1">Accessible Name:</th><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Respond Desktop Font/Color
Changes:</th><td rowspan="1" colspan="1">Partial (conflicts with CSS and JavaScript)</td></tr><tr><th align="left" rowspan="1" colspan="1">Device independent navigation:</th><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Accessibility API Mapping:</th><td rowspan="1" colspan="1">Partial - User Agents</td></tr><tr><th align="left" rowspan="1" colspan="1">Provide focus to all active elements (important for
equivalent keyboard access on desktops)</th><td rowspan="1" colspan="1">Limited to forms and anchors</td></tr></tbody></table>
</div>
</div>
<div class="section" id="Fill">
<h2><span class="tocnum">2. </span> Filling the Gaps for Content Delivered to Desktop Browsers</h2>
<p>At this time,W3C WAI Protocols and
Formats working group's primary focus is on extensions to HTML 4.01 and XHTML 1.X by extending the host language to include WAI-ARIA with a migration path to HTML 5. This will require the creation of new hybrid document type definitions (DTDs) that incorporate the extensions. This work will be in the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">Accessible Rich Internet Applications</a></cite> [<cite><a href="#ref_ARIA">ARIA</a></cite>] specification. WAI-ARIA will constitute
extensions to fill most of the gaps needed to support
accessibility API infrastructures and dynamic (X)HTML content. The comprehensive gap analysis of (X)HTML, used to form WAI-ARIA is found in <a href="#gapanalysishtml">Table 1.0</a> and how WAI-ARIA fills those gaps. In the future we hope to incorporate WAI-ARIA into many host languages to improve their accessibility. The critical extensions needed to make accessible dynamic Web content accessible, through rich interoperability with assistive technologies,
are summarized here: </p>
<blockquote>
<p> States, and Property attributes - This is the set of attribute modifications to (X)HTML necessary to provide full keyboard focus and states and properties that may be mapped directly or indirectly to platform accessibility APIs to ensure full interoperability with assistive technologies for WAI-ARIA. </p>
<p>Role attribute - The role attribute, borrowed from the, <cite><a href="http://www.w3.org/TR/2010/WD-role-attribute-20100916/">Role Attribute</a></cite> [<cite><a href="#ref_ROLE">ROLE</a></cite>], allows the author to annotate host languages with machine-extractable semantic information about the purpose of an element. It is targeted for accessibility, device adaptation, server-side processing, and complex data description. WAI-ARIA uses the role attribute to provides the role information, in <a href="#fig2">Figure 2 - Accessibility Interoperability at a DOM node with JavaScript</a> to an assistive technology.</p>
<p>Role document landmark values - These values, borrowed from the <cite><a href="http://www.w3.org/TR/2010/WD-role-attribute-20100916/">Role Attribute</a></cite> [<cite><a href="#ref_ROLE">ROLE</a></cite>] provides a standard set of role attribute values designed to define pertinent parts of a document (landmarks) for the purpose of accessibility. User agents may incorporate device equivalents, such as key mappings in the case of a desktop user agent, to navigate to these sections of a document.</p>
<p>Taxonomy of WAI-ARIA role values - The necessary core roles found in Accessibility API sets
for Windows and Linux as well as roles representative of document structure, such as <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#banner"><code>banner</code></a> or <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treegrid"><code>treegrid</code></a>. Use of document
structure is necessary for assistive technologies to navigate
complex documents and to know when they have entered active areas
of a Web page such as in the case of a dynamic scripted Web
application. The taxonomy is designed to help user agents or
authoring tools determine what properties a given role supports and to assist with accessibility API mapping of these
properties. The taxonomy will is like a class hierarchy used to
convey semantics and structure and includes knowledge about each
role. At this time, that taxonomy is modeled using <cite><a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/">Resource Description Framework</a> </cite>[<cite><a href="#ref_RDF">RDF</a></cite>] and <cite><a href="http://www.w3.org/TR/2004/REC-owl-features-20040210/">Web Ontology Language</a></cite> [<cite><a href="#ref_OWL">OWL</a></cite>]. </p>
</blockquote>
<p>In short, WAI-ARIA will be used to fix the dynamic accessibility of scripted Web content,
in particular the use of JavaScript with (X)HTML markup. They are meant to be
cross-cutting and should apply to other markup like SVG. Less
critical for (X)HTML but helpful for accessibility
will be the descriptive extensions to XML events and the new <cite><a href="http://www.w3.org/TR/xhtml-access/">Access
element</a></cite> [XHTML Access]. <a href="http://www.w3.org/TR/WCAG20/">Web Content Accessibility Guidelines 2.0</a> calls for the WAI-ARIA properties in guideline 4.1 <a href="http://www.w3.org/TR/WCAG20/#ensure-compat">Maximize compatibility with current and future agents, including assistive technologies</a> (roles, states, properties, and values) and section guideline 1.3 <a href="http://www.w3.org/TR/WCAG20/#content-structure-separation">Create content that can be presented in different ways (for example spoken aloud, simpler layout, etc.) without losing information or structure</a> (relationships).</p>
<p> The
next section describes how the specifications are used together as well as how they will be implemented in HTML 4.</p>
<div class="section" id="new_provisions">
<h3><span class="tocnum">2.1. </span> Use of New Provisions for Keyboard Focus and Semantics to Support Platform Accessibility APIs</h3>
<p>Adaptive technologies, which need to provide alternative access to
complex user interfaces authored via HTML, are often left guessing
at the semantics behind specific portions of HTML document. As an
example, an XHTML document might use a certain HTML construct, such
as a collection of <code>DIV</code> tags, to create navigation bars, a
site-navigation menu, and other GUI-like user interface widgets. To
fix the problem, we incorporate the role
attribute, assign the accessible state properties, and give the object
focus using the new <code>TABINDEX</code> feature. Addition of this information
helps authors to provide the necessary information to
enable the user agent to support the accessibility API accessed by
the adaptive technology.</p>
<div class="section" id="role">
<h4><span class="tocnum">2.1.1. </span> Provision of the Role Attribute: "What is the Object?"</h4>
<p>Each platform accessibility API has the notion of a "role" for a
GUI object. This is the case for <cite><a href="http://java.sun.com/javase/technologies/accessibility/index.jsp">Java Accessibility API</a></cite> [<cite><a href="#ref_JAPI">JAPI</a></cite>], <cite><a href="http://msdn.microsoft.com/en-us/library/ms697707.aspx">Microsoft Active
Accessibility</a></cite> [<cite><a href="#ref_MSAA">MSAA</a></cite>], <cite><a href="http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html">The Mac OS X Accessibility Protocol</a></cite> [<cite><a href="#ref_AXAPI">AXAPI</a></cite>], and the <cite><a href="http://library.gnome.org/devel/atk/unstable/">Gnome Accessibility Toolkit (ATK)</a></cite> [<cite><a href="#ref_ATK">ATK</a></cite>], or <cite><a href="http://msdn.microsoft.com/en-ca/windows/bb735024.aspx"> UI Automation for
Longhorn</a></cite> [<cite><a href="#ref_UIAUTOMATION">UIAUTOMATION</a></cite>] (called content type in UI Automation). The WAI-ARIA specifications are based on XHTML 1.X and include the role attribute. The "role" attribute takes a qname, enabling authors to reference the role attribute from the <abbr>WAI-ARIA</abbr> Roles. In
the following example, we use qname to reference the menu role in the WAI-ARIA specification. </p>
<div class="exampleOuter">
<div class="exampleHead">
<p>Example: Use of WAI-ARIA to incorporate
role information information into XHTML 1.x</p>
</div>
<div class="exampleInner">
<pre xml:space="preserve">
<span class="pi"><?xml version="1.1" encoding="us-ascii"?></span>
<span class="doctype"><!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"></span>
<html xmlns="http://www.w3.org/1999/xhtml"
>
<body>
<div role="menu">
File
</div>
</body>
</html>
</pre>
</div>
</div>
<p>WAI used RDF/OWL to model our taxonomy for WAI-ARIA. In fact, if a host language sought to use namespaces or qnames, they could do so to reference the WAI-ARIA role taxonomy. The WAI-ARIA role taxonomy could be used by authoring tool developers to ensure that states and properties assigned to a given role are accurate.</p>
</div>
<div class="section" id="properties">
<h4><span class="tocnum">2.1.2. </span> Provision of the Accessibility State Information: "What meaningful properties does this object have at this time?"</h4>
<p>Since this is dynamic content, the state of these new repurposed
objects will change. The WAI-ARIA specification shall provide the common
accessible properties needed to support the accessible state or
property information provided by the platform accessibility API
defined previously. This specification was created based on an
analysis of the accessibility properties defined in <acronym title="Microsoft Active Accessibility">MSAA</acronym> and <acronym title="Accessibility Toolkit">ATK</acronym>.
The following example extends the previous approach by adding the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-haspopup"><code>aria-haspopup</code></a> accessibility property.</p>
<div class="exampleOuter">
<div class="exampleHead">
<p>Example: Use of WAI-ARIA to incorporate accessible state information information into XHTML 1.x</p>
</div>
<div class="exampleInner">
<pre xml:space="preserve">
<span class="pi"><?xml version="1.1" encoding="us-ascii"?></span>
<span class="doctype"><!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN"
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"></span>
>
<body>
<div role="menu" aria-haspopup="true">
File
</div>
</body>
</html>
</pre>
</div>
</div>
<p>A Windows user agent may now map this property to the Microsoft
Active Accessibility state of <code>STATE_SYSTEM_HASPOPUP</code>. Adding or
removing this state would result in the Windows user agent sending
an <code>EVENT_OBJECT_STATECHANGE</code> event to the assistive technology. The
task of the JavaScript page author would be to maintain this state
attribute, which can easily be done through the use of Document
Object Model calls.</p>
</div>
<div class="section" id="focus">
<h4><span class="tocnum">2.1.3. </span> Provision of the Keyboard or Input Focus: "What object am I working on?"</h4>
<p>Virtually all adaptive technology solutions, such as screen
readers and onscreen keyboards, must know which object currently
has focus. For example, an author might want to insert text into the
current object with focus or to announce information
about the object that has focus. With today's HTML 4.01 and XHTML 1.x, script authors can only provide focus to form
and anchor elements yet the Document Object Model Specification
allows all elements to receive events including keyboard events.
This means that HTML, by design prohibits script authors from
making all HTML elements keyboard accessible. This single problem
effects usability of Web pages where one gains access to
elements by using the Tab key on desktop browsers. This slow,
unproductive, approach makes portal navigation difficult because all active elements must be tabbed through to put focus on an
active element in the last portlet in a document. To solve this
problem in XHTML 1.x, we are incorporating a feature in Firefox and
Internet Explorer to define the tabindex for -1. This allows a script author to
give an element focus without placing it in the tab order: The
following table describes these changes that will be incorporated
into the new Accessible Adaptive Application specification.</p>
<table border="1" cellspacing="0"><caption>
Accessible Adaptive Application Changes to Support Use of <code>tabindex</code> to give Element Focus
</caption><tbody><tr><th rowspan="1" colspan="1">tabindex attribute</th><th rowspan="1" colspan="1">Focusable with mouse or JavaScript via element.focus()</th><th rowspan="1" colspan="1">Tab navigable</th></tr><tr><td rowspan="1" colspan="1">not present</td><td rowspan="1" colspan="1">Follows default behavior of element (yes for form controls,
links, etc.)</td><td rowspan="1" colspan="1">Follows default behavior of element</td></tr><tr><td rowspan="1" colspan="1">Negative, e.g. <code>tabindex="-1"</code> </td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">No, author must focus it with <code>element.focus()</code> as a
result of arrow or other key press</td></tr><tr><td rowspan="1" colspan="1">Zero, e.g. <code>tabindex="0"</code> </td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">In tab order relative to element's position in document</td></tr><tr><td rowspan="1" colspan="1">Positive, e.g. <code>tabindex="33"</code> </td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Tabindex value directly specifies where this element is
positioned in the tab order. These elements will be positioned in
the tab order before elements that have tabindex="0" or that are
naturally included in the tab order (form elements and links)</td></tr></tbody></table>
<p>The following example shows the introduction of <code>TABINDEX</code> to
provide focus to a <code>DIV</code> having the new accessibility meta data:</p>
<div class="exampleOuter">
<div class="exampleHead">
<p>Example: Use of tabindex to give non-form
and anchor elements focus in XHTML 1.x</p>
</div>
<div class="exampleInner">
<pre xml:space="preserve">
<span class="pi"><?xml version="1.1" encoding="us-ascii"?></span>
<span class="doctype"> <!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN"
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"></span>
>
<body>
<div role="menu" aria-haspopup="true" tabindex=-1>
File
</div>
</body>
</html>
</pre>
</div>
</div>
</div>
<div class="section" id="ariahtml">
<h4><span class="tocnum">2.1.4. </span> Supporting WAI-ARIA in XHTML and HTML 4.01</h4>
<p>Unlike XHTML, HTML 4.01 is non-extensible in that it is not possible to extend HTML 4 through the use of namespaces. That said, members of the working group have worked with the HTML working group to agree on a vehicle that does not use namespaces, which at this time is supported by XHTML and HTML which will be supported in HTML 5 when it becomes recommendation. Firefox 3 is leading the way to implement this, and other browser manufacturers are working to support it as well. The technique allows all role values specified in WAI-ARIA (including those specified by the XHTML Role attribute module) to be specified without a namespace prefix. Additionally, WAI-ARIA states and properties shall be represented as aria- followed by the concatenated WAI-ARIA state or property. </p>
<div class="exampleOuter">
<div class="exampleHead">
<p>Example: Browser supported HTML technique for the tabindex example in section 5.1.3</p>
</div>
<div class="exampleInner1">
<pre xml:space="preserve">
<html lang="en">
<head><br clear="none"/> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><br clear="none"/> </head>
<body>
<div role="menu" aria-haspopup="true" tabindex=-1>
File
</div>
</body>
</html>
</pre>
</div>
</div>
<p>In order to validate these extended attributes for HTML and XHTML the WAI-PF working group will investigate the creation of an enhanced schema or DTD for each host language. <br clear="none"/>
</p>
</div>
</div>
<div class="section" id="landmarks">
<h3><span class="tocnum">2.2. </span> Use of XHTML Role Landmarks to Improve Document Navigation</h3>
<p>In addition to the common roles which will reside in <abbr>WAI-ARIA</abbr> Roles, both XHTML 2.0, and the <a href="http://www.w3.org/TR/2010/WD-role-attribute-20100916/#s_role_module_attributes">XHTML Role attribute module</a> ([<a href="#ref_ROLE">ROLE</a>], Section 4) defines a collection of common role, regional, landmarks that define pertinent parts of a
document for the purpose of accessibility. User agents may
incorporate device equivalents, such as key mappings in the case of
a desktop user agent, to navigate to these sections of a document
independent of the Web site. The addition of these semantics allows
the user agent to provide standardized navigation to common
document sections. This is especially important for portals to
improve the usability. These may be used as attributes in XHTML 1.x
by applying them to sections of the document as shown in this
example. Note: since these roles are a part of XHTML they do not need to be namespace qualified.</p>
<div class="exampleOuter">
<div class="exampleHead">
<p>Example: Use of XHTML navigation role to define a landmark for the
navigation section in an XHTML 1.X document</p>
</div>
<div class="exampleInner">
<pre xml:space="preserve"><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>application/xhtml+xml: Navigation Roles Example 1</title>
<link rel="stylesheet" href="css/nav1_xhtml.css" type="text/css" ></link>
<script type="text/javascript" src="../js/globals.js"></script>
<script type="text/javascript" src="../js/widgets_xhtml.js"></script> <link rel="icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon" />
<link rel="shortcut icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon" />
</head>
<body onload="widgets.init()">
.
.
.
<div id="leftnav">
<h2 class="nav" id="leftnav_label">Career Center Services</h2>
<ul title="Career Center Services" role="navigation" aria-labelledby="leftnav_label">
<li><a href="http://www.uiuc.edu/">Career Home</a></li>
<li><a href="http://www.uiuc.edu/">Career Counseling</a></li>
<li><a href="http://www.uiuc.edu/">Pre-Health Advising</a></li>
<li><a href="http://www.uiuc.edu/">Services</a></li>
<li><a href="http://www.uiuc.edu/">Workshops</a></li>
<li><a href="http://www.uiuc.edu/">Resource Center</a></li>
<li><a href="http://www.uiuc.edu/">Question Board/FAQ</a></li>
</ul>
...
</body></pre>
</div>
</div>
<p>The example above was taken from the header from the <a href="http://test.cita.uiuc.edu/aria/nav/nav1.php">Career Center Web page at the University of Illinois at
Urbana-Champaign</a>. Students from this university, under Jon
Gunderson's guidance created <a href="http://firefox.cita.uiuc.edu/">Accessibility
extensions for Mozilla/Firefox</a>, in part, to allow a page author or
user to view a list of navigation landmarks.
This tool, shown in <a href="#fig3" target="_top">Figure 3.0</a>, lists the navigation sections on the page. Keyboard navigation of the list of navigation bars causes the
corresponding document section to be highlighted. The title for each navigation region displays in the list.</p>
<p class="figure"><a id="fig3" name="fig3"></a> <img alt="Table of Contents from Landmarks" height="813" longdesc="#desc_fig3" src="navlandmark.jpg" title="Table of Contents from Landmarks" width="877"/> <br clear="none"/>
Figure 3.0 Table of Contents
generated from navigation landmarks in the header</p>
<p id="desc_fig3"> <a href="#fig3">Figure 3.0</a> shows the <a href="http://firefox.cita.uiuc.edu/">accessibility
extensions for Mozilla/Firefox</a> from the University of Illinois at
Urbana-Champaign to render the document landmarks. This picture
shows the Firefox browser rendering the University of Illinois
Career Career Center home page. In this example. The "List of Navigation Bars" viewer is shown, launched from the extension on the
toolbar. The viewer shows that the secondary "Career Center Services" is selected resulting
in that section of the document being highlighted in yellow. The
Navigation Bar Lists Viewer lists the following list of titles corresponding to the navigation sections:</p>
<ul><li>Career Counseling Resources</li><li>Resources by Audience</li><li>Career Center Services</li><li>Quick Links</li></ul>
</div>
<div class="section" id="extsemantics">
<h3><span class="tocnum">2.3. </span> WAI-ARIA Role Taxonomy - Extensible Semantic Role Model, using RDF/OWL</h3>
<p>The WAI-ARIA role taxonomy was modeled using semantic web technology, in the form of <cite><a href="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/">Resource Description Framework (RDF)</a></cite> [<cite><a href="#ref_RDF">RDF</a></cite>] and the <cite><a href="http://www.w3.org/TR/2004/REC-owl-ref-20040210/">Web Ontology Language (OWL)</a></cite> [<cite><a href="#ref_OWL">OWL</a></cite>], as a vehicle to define a knowledge-based class hierarchy for roles. This model shows what states and properties are supported, by each role in the taxonomy. The role in the class hierarchy inherits properties from its ancestors and defines its own properties. Where applicable, semantic web technology is used to define related concepts within other namespaces. This information is critical in determining how to choose a role and how to interact with it. The role taxonomy uses RDF as a way for using data to describe data and provides a
W3C standards-based approach to represent this information.</p>
<p class="figure"> <a id="fig4" name="fig4"></a>
<img alt="Sample Semantic Map for Taxonomy" height="564" longdesc="#desc_fig4" src="taxonomy.png" title="Sample Semantic Map for Taxonomy" width="500"/> <br clear="none"/>
Figure 4.0 Example, Partial RDF Map for a possible ButtonUndo role as an extended role to WAI-ARIA</p>
<p id="desc_fig4"> <a href="#fig4">Figure 4.0</a> shows a basic RDF mapping that
defines a set of terms and relationships defining an object. At the
center is a Widget object that defines common states and properties
for all GUI widgets. The Button object extends Widget and inherits
defined accessibility properties from the superclass Widget. It
also defines a <em>relatedConcept</em> property to a Link object.
The ButtonUndo role extends Button. It has a relatedConcept of an HTML input object.
ButtonUndo will introduce Dublin Core meta data such as the
description of the object. The terms relatedConcept and
requiredState are terms that will be defined as part of the
corresponding RDF schema. Each role instance will represent
standard Roles found in the platform accessibility APIs of platforms like
Windows and Gnome as well as content structure. These roles will
form the taxonomy. Although host language browser implementations may reference WAI-ARIA roles without namespaces, the RDF representation for a given role may be referenced using a
qname from a Host XML markup language. This examples shows an XHTML reference to a grid role in the RDF representation of the WAI-ARIA taxonomy:</p>
<p><code><div
role="grid"></code> whereby <code>grid</code> expands to:
http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#grid in the
button markup.</p>
<p>The power of this design is that it enables a web authoring tool to go back
into the corresponding RDF/OWL markup and determine what properties it
supports for Accessibility API mapping. Additional, middleware solutions can now make intelligent
transformations of Web Content by processing the semantics behind
rich browser and rich structured frameworks to adapt accessible
solutions for a broader user base. Our immediate goal is to fix the
accessibility problem with scripted Web content. Assistive
technologies will use the standard roles to determine how to render
most content. </p>
<div class="section" id="temp">
<h4><span class="tocnum">2.3.1. </span> Interoperability Example: Grid Role </h4>
<p>To understand the power of this approach, consider the case of a Grid Role, analogous to a table. <a href="#fig5">Figure 5.0</a> shows a DHTML example using
XHTML, JavaScript, and CSS to produce a GUI-like application. This
example developed in IBM shows a notebook
tab with a data grid that behaves like a traditional desktop GUI.
The user uses arrow keys to navigates the data grid and among the page tabs.
Using the Tab key, a user navigates between the notebook tab, the edit fields, buttons, and
the data grid.</p>
<p class="figure"> <a id="fig5" name="fig5"></a> <img alt="DHTML example of GUI-like notebook tab with a data drid" height="633" longdesc="#desc_fig5" src="DHTMLexample.png" title="DHTML Example" width="844"/> <br clear="none"/>
Figure 5.0 DHTML Example</p>
<p id="desc_fig5"> Accessible role and state
meta data from the WAI-<abbr>WAI-ARIA</abbr> Roles, States, and Properties specification, are added as attributes to
each of the XHTML elements repurposed as GUI widgets dynamically.
The user agent, in this case Firefox, maps this information to the
platform accessibility API. <a href="#fig6">Figure 6.0</a> shows
the Microsoft Active Accessibility rendering of the new
accessibility markup provided on the DataGrid page tab which has
focus.</p>
<p class="figure"> <a id="fig6" name="fig6"></a> <img alt="MSAA Inspect Tool diagnostics for Notebook page tab" height="647" longdesc="#desc_fig6" src="inspectofpagetab.png" title="MSAA Inspect Tool diagnostics for Notebook page tab" width="490"/> <br clear="none"/>
Figure 6.0 Microsoft Inspect Tool rendering of the page tab
DataGrid</p>
<p id="desc_fig6"> <a href="#fig6">Figure 6.0</a> show a Microsoft Inspect 32
rendering of the DataGrid Page page tab in Figure 5.0. Inspect32
provides Microsoft Active Accessibility information; here it shows the
accessible role of "page tab" and accessible state information of
focused, focusable, and linked. There are no page tab elements in
XHTML. Here, an XHTML DIV element is repurposed by a
JavaScript controller to look like a notebook tab. It is now able
to receive focus, unlike in standard XHTML 1.X, and it does so without
requiring tabbing. With these specifications, the script
author can now add the accessibility properties to support platform
accessibility API. Accessible state properties for the DataGrid
page tab are shown as focused, focusable, and linked. Unlike a GUI
application, authors need only enable their applications once for
multiple operating system platforms.</p>
<p>Beyond scripted Web content, the working group intends to extend
the use of roles to enable other user cases. These may include:</p>
<ul><li> <strong>Structured Textual Markup</strong> - enhancing
structure of the markup of a document, including Data Tables , or
translating the structure of an XML document to a markup structure
that user agents are used to dealing with (e.g. myXML to XHTML)
Binding sections of a document to a common role. This allows for
different navigation techniques though a document</li><li> <strong>Knowledge representation of Web content</strong> - As a
secondary benefit, roles improve compatibility with Knowledge-Based
Services and the Semantic Web. By integrating accessibility and the
semantic Web, accessibility can be moved forward, paving the way
for customized accessible searches and intelligent user agents with
additional applications.</li><li> <strong>Adding concepts in the type of content for adaptation
to the user scenario</strong> - The more that is understood about
content, the better it can be adapted for the end user. For example:
<ol><li>If it is known that a page hyperlink has the role of taking the
user to the site's home page, then that knowledge can be used to
create enhanced accessibility in different ways in many different
scenarios, such as icons or access keys.</li><li>If it is known that a text box is for the user email address,
then the user agent can support users filling in the form by
labeling it with an icon or symbol, automatically validating it, or
even form filling.</li><li>If it is known that a paragraph is complex, then a simple equivalent
can be shown in its place</li><li>If a word is ambiguous, then a role of a concept can be given,
providing clarity An example of this may be : <code><span
role="role:nonliteral" aria:hasAlternate="no"></code></li></ol>
</li></ul>
</div>
</div>
<div class="section" id="Events">
<h3><span class="tocnum">2.4. </span> Accessibility Events and Event Handling</h3>
<p>Interoperability between applications and assistive technologies
requires event notification for accessibility. The events defined
in <a href="#gapanalysishtml">Table 2.0</a> will be fired via the user
agent. The accessible value and state property changes will be
generated in response to changes in the DOM attributes as defined
by the WCAG 1.0 <a href="http://www.w3.org/WAI/WCAG1AAA-Conformance"><cite>AAA</cite></a> specification. User agents supporting the platform
accessibility API, will support event notification such as the <a href="#StateChange">state change</a> or <a href="#valuechange">value change</a> events.</p>
</div>
<div class="section" id="alookahead">
<h3><span class="tocnum">2.5. </span> HTML 5 - A Look Ahead</h3>
HTML 5 and the "serialized" XHTML version of HTML 5 are years away from standardization. We have preliminary consensus to add the WAI-ARIA states and properties, role, and tabindex changes needed for WAI-ARIA in HTML 5 as demonstrated in section <a href="#ariahtml">5.1.4</a>. This is subject to change between now and when the specification goes to recommendation. In HTML 5, we will see many more standard controls that developers may choose to use and that should be used in preference to WAI-ARIA features. We shall continue to promote WAI-ARIA's use and adoption in industry to ensure that there continues to be the ability to provide support accessibility of new types of controls. A number of gaps remain, such as named event handlers and enhancements for access key, that we need to address. This work is in progress. </div>
</div>
<div class="section" id="buildingaccessibleapplications">
<h2><span class="tocnum">3. </span> Building Accessible Applications with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></h2>
<p>This section provides a brief introduction to the process of making applications accessible using <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. The choice and usage of <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_role">roles</a> can be complex and context dependent. It is beyond the scope of this document to explain implementations for all the possible <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> use cases. <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/">WAI-ARIA Authoring Practices</a></cite> [<cite><a href="#ref_ARIA-PRACTICES">ARIA-PRACTICES</a></cite>] provides detailed guidance on <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> implementation methodology as well as references to sample code.</p>
<p>First steps to making an application accessible:</p>
<ol><li>Each <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_element">element</a> or <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_widget">widget</a> has correct and complete <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_semantics">semantics</a> that fully describe its behavior (using element names or roles);</li><li>The <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_relationship">relationships</a> between elements and groups are defined;</li><li><a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_state">States</a>, <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_property">properties</a>, and container relationships are valid for each element's behavior and are accessible via the <cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/">Document Object Model</a></cite> [<cite><a href="#ref_DOM">DOM</a></cite>] and the platform <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_accessibility_api">accessibility API</a>; and</li><li>Keyboard focus should be maintained for the duration of the user's interaction with the application.</li><li>All interactive components should be <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_keyboard_accessible">keyboard operable</a>.</li></ol>
<p><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> provides authors with the means to make the different elements in a web application semantically rich. <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_useragent">User agents</a> use the role semantics to understand how to handle each element. Roles convey additional information that the <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_at">assistive technologies</a> need to anticipate the behavior of the elements inside the application such as how to present the corresponding <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> states and properties to the user. The user agent will use the accessibility semantics from the host language and WAI-ARIA accessibility semantics (which may augment or override those of the host language) and present them to assistive technologies through the Document Object Model or the platform accessibility <abbr title="Application Programming Interfaces">API</abbr>. The user agent will create an accessible representation of each element in the web page, and will use the appropriate accessibility <abbr title="Application Programming Interfaces">API</abbr> to notify assistive technologies of changes to the semantics of those elements.</p>
<p>The following steps are recommended when <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> is applied to content:</p>
<ol><li>
<p><strong>Use native markup when possible.</strong></p>
<p>Use the semantic elements that are defined in the host markup language. For example, with <abbr title="Hypertext Markup Language">HTML</abbr> or <abbr title="Extensible Hypertext Markup Language">XHTML</abbr>, it is better to use the native checkbox than to use a div element with role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#checkbox"><code>checkbox</code></a> as these should already be accessible through your browser. There may also be cases where <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> can augment an existing element in the host language. For example, a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#grid"><code>grid</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#gridcell"><code>gridcell</code></a> elements can reuse the functionality of a table when overlaying it. <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles, states, and properties are best used when the markup language does not support all the semantics required. When a role <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_attribute">attribute</a> is added to an element, the semantics and behavior of the element are augmented or overridden by the role behavior.</p>
</li><li>
<p><strong>Apply the appropriate roles.</strong></p>
<p>Set roles to make sure elements behave predictably and correctly describe the behavior of each element within the application, unless element behaviors are fully described by the native markup language. Roles for interactive elements should support all the attributes that the element could use. Once a role attribute is set it should not be changed as this may confuse the end user. This does not preclude an element being removed which has the role attribute set, but only states and properties (aria-* attributes) should be changed for a given element.</p>
</li><li>
<p><strong>Preserve semantic structure.</strong></p>
<p>Structural information is critical to providing context to persons with disabilities. Preserve DOM hierarchy within structural elements and widgets: </p>
<ul><li> Form logical groups within user interface widgets, such as treeitem elements in a group. </li><li> Identify large perceivable regions and apply a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#landmark"><code>landmark</code></a> role to those areas. This will facilitate keyboard navigation. It will also facilitate content management by assistive technologies by providing semantics to manage how much information is rendered at a given time. The use of WAI-ARIA landmarks helps everyone, including vision-impaired users, dexterity-impaired users, and even users with cognitive or learning impairments.</li><li> For areas of the page that contain a group of elements that are likely to change through an Ajax application it may be specified as a live region, through the use of the aria-live attribute or it may be marked with pre-defined roles, such as <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#log"><code>log</code></a>, which has assumed behavior of a live region. </li></ul>
</li><li>
<p><strong>Build relationships.</strong></p>
<p>Look for <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_relationship">relationships</a> between elements, and mark them using the most appropriate <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_property">property</a> or attribute. For example, if a page contains both a search form and search results region, mark each container as a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#region"><code>region</code></a> and set the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> attribute of the search form to reference the search results. See <a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#attrs_relationships">relationships in <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></a>.</p>
<p>Some relationships are determined automatically from the host language, like <code>label</code> elements associated with <code>input</code> elements in <abbr title="Hypertext Markup Language">HTML</abbr>.</p>
</li><li>
<p><strong>Set states and properties in response to events.</strong></p>
<p>Once the role for an element has been set, change states and properties as appropriate during the element's life cycle, usually in response to user input <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_event">events</a>. Only use attributes supported for the chosen role or element.</p>
<p>User agents should notify assistive technologies of state changes. Conversely, assistive technologies' notification of property changes depends on the method by which assistive technologies communicate with the user agent. For example, the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-multiline"><code>aria-multiline</code></a> attribute (a property) is not something that changes frequently, whereas the <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-checked"><code>aria-checked</code> (state)</a> attribute (a state) changes frequently in response to user input.</p>
</li><li>
<p><strong>Support full, usable keyboard navigation.</strong></p>
<p>Usable keyboard navigation in a rich internet application is different from the tabbing paradigm in a static document. Rich internet applications behave more like desktop applications where the user tabs to significant widgets and uses the arrow keys to navigate within a complex widget, such as a menu or spreadsheet. The changes that <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> introduces in keyboard navigation make this enhanced accessibility possible. Tabbing in the document should follow a logical navigation structure. Authors implementing arrow key navigation should, where possible, follow the design patterns in the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices Guide</a></cite> [<cite><a href="#ref_ARIA-PRACTICES">ARIA-PRACTICES</a></cite>]. When using these features, it is important as always to ensure keyboard navigation is logical.</p>
</li><li>
<p><strong>Synchronize the visual interface with the accessible interface.</strong></p>
<p>This will allow the state of your <abbr title="User Interface">UI</abbr> to be <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_perceivable">perceivable</a> to the user as well as assistive technologies. For example, the author should use the appropriate WAI-ARIA attribute on a form element that is visually styled to appear required (<a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-required"><code>aria-required</code></a>) or a gridcell that is visually styled to appear selected (<a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-selected"><code>aria-selected</code> (state)</a>). Authors may choose to achieve visual synchronization of these interface elements by using a script or by using <a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/selector.html#attribute-selectors"><abbr title="Cascading Style Sheets">CSS</abbr> attribute selectors.</a> Refer to the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices</a></cite> [<cite><a href="#ref_ARIA-PRACTICES">ARIA-PRACTICES</a></cite>] for techniques on proper <abbr title="User Interface">UI</abbr> synchronization with the accessible state of the document.</p>
</li></ol>
<div class="section" id="exampletree">
<h3><span class="tocnum">3.1. </span> Example: Building a Tree Widget</h3>
<img alt="Graphic of an example tree view." class="role-screenshot" src="exampletree.png" width="188" height="327"/>
<p>A basic tree view allows the user to select different list items and expand and collapse embedded lists. Arrow keys are used to navigate through a tree, including left/right to collapse/expand sub trees. Clicking the visible expander button with the mouse also toggles expansion. Further keyboard implementation details for tree widgets may found in the [<cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#aria_ex">WAI-ARIA Authoring Practices Guide Design Patterns</a></cite> [<cite><a href="#ref_ARIA-PRACTICES">ARIA-PRACTICES</a></cite>, section 9].</p>
<p>To make this feature accessible we need to:</p>
<ul><li>Inform <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_at">assistive technologies</a> about the <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_role">role</a> of each <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_element">element</a>;</li><li>Inform assistive technologies about the <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_relationship">relationships</a> between tree items;</li><li>Give a clear keyboard focus that will not confuse users with disabilities; and</li><li>Expose the changing <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_state">states</a> (expanded and collapsed) of the tree items.</li></ul>
<p>Following the steps below:</p>
<ol><li>
<p><strong>Look at the native markup language</strong></p>
<p>Although standard list behavior is supported by the native <code>ul</code> and <code>li</code> elements in <abbr title="Hypertext Markup Language">HTML</abbr>, there is no element that natively supports list expansion and selection. Since there is not, we will need to use <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_role">roles</a>.</p>
</li><li>
<p><strong>Finding the right roles</strong></p>
<p>Since there is no native tree element in <abbr title="Hypertext Markup Language">HTML</abbr>, we need to add roles from the <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_taxonomy">taxonomy</a> that support the additional states and properties needed. The roles that support tree behavior are:</p>
<ul><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tree"><code>tree</code></a>: A tree is the main container element for our tree. It is a form of a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#select"><code>select</code></a> where sub-level groups of treeitems may be collapsed and expanded.</li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treeitem"><code>treeitem</code></a>: A treeitem is an option item of a tree. This is an element within a tree; sub-level groups of treeitems may be expanded or collapsed.</li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a>: A group encloses a set of sub-level treeitems.</li></ul>
</li><li>
<p><strong>Look for groups and build relationships</strong></p>
<p>Tree relationships can be made simply via the <abbr title="Document Object Model">DOM</abbr> and logical structure of the page. A tree element will be the main container encompassing all other elements in the tree. Each selectable item in the tree will be a treeitem.</p>
<p>When a treeitem contains an embedded list of treeitems they will be all be embedded in a group. A group should be contained inside the tree item that is the parent item.</p>
<pre class="example" xml:space="preserve"><span class="tag"><h1 id=<span class="str">"treelabel"</span>></span>WAI-ARIA Tree Example<span class="tag"></h1></span>
<span class="tag"><ul role=<span class="str">"tree"</span> aria-labelledby=<span class="str">"treelabel"</span> aria-activedescendant=<span class="str">"example_id"</span> tabindex=<span class="str">"0"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"true"</span>></span>Animals
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Birds<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"false"</span>></span>Cats
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Siamese<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Tabby<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"true"</span>></span>Dogs
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"true"</span>></span>Small Breeds
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Chihuahua<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> id=<span class="str">"example_id"</span>></span>Italian Greyhound<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Japanese Chin<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"false"</span>></span>Medium Breeds
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Beagle<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Cocker Spaniel<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Pit Bull<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"false"</span>></span>Large Breeds
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Afghan<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Great Dane<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Mastiff<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"true"</span>></span>Minerals
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Zinc<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"false"</span>></span>Gold
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Yellow Gold<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>White Gold<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Silver<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"true"</span>></span>Vegetables
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Carrot<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Tomato<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Lettuce<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"></li></span>
<span class="tag"></ul></span></pre>
<p>The use of <code>aria-expanded</code> should mirror that which is visibly expanded on screen, so authors may wish to use <abbr title="Cascading Style Sheets">CSS</abbr> attribute selectors to toggle visibility or style of an item based on the <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_value">value</a> of an <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_state">state</a> or <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_property">property</a>. The following example would hide the sub-level groups of a collapsed tree node.</p>
<pre class="example" xml:space="preserve">[aria-expanded="false"] [role="group"] { display: none; }</pre>
<p class="note">
Note: At the time of this writing, this <abbr title="Cascading Style Sheets">CSS</abbr> example, while technically correct, will not redraw styles properly in some browsers if the attribute's value is changed dynamically. It may be necessary to toggle a class name, or otherwise force the browser to redraw the styles properly.</p>
<p>Sometimes a tree structure is not explicit via the <abbr title="Document Object Model">DOM</abbr> and logical structure of a page. In such cases the relationships must still be made explicit using the states and properties. In the following example, the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> attribute indicates that the <code>div</code> with id "external_treeitem" should be considered a child of the <code>ul</code> element with the attribute, even though it is not a child in the <abbr title="Document Object Model">DOM</abbr>.</p>
<pre class="example" xml:space="preserve">...
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-expanded=<span class="str">"true"</span> aria-owns=<span class="str">"external_group"</span>></span>Vegetables<span class="tag"></li></span>
...
<span class="tag"><ul role=<span class="str">"group"</span> id=<span class="str">"external_group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Carrot<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Tomato<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span>></span>Lettuce<span class="tag"></li></span>
<span class="tag"></ul></span>
...</pre>
<p>Sometimes trees (and other lists or grids) cannot be completed represented in the <abbr title="Document Object Model">DOM</abbr> due to performance limitations of the browser. For example, an application interface may only need to display 100 items out of a set of 100,000. Including all 100,000 items in the DOM could cause performance problems on both the client and server machines.</p>
<p>If items in a managed widget are loaded, for example, via the XMLHttpRequest object, and not present in the <abbr title="Document Object Model">DOM</abbr> at all times, authors should use <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-level"><code>aria-level</code></a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-posinset"><code>aria-posinset</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-setsize"><code>aria-setsize</code></a>, and ensure that <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> is not required to convey membership with the widget.</p>
<pre class="example" xml:space="preserve">...
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-level=<span class="str">"1"</span> aria-posinset=<span class="str">"3"</span> aria-expanded=<span class="str">"true"</span> aria-setsize=<span class="str">"3"</span>></span>
Vegetables
<span class="tag"><ul role=<span class="str">"group"</span>></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-level=<span class="str">"2"</span> aria-posinset=<span class="str">"6"</span> aria-setsize=<span class="str">"8"</span>></span>Carrot<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-level=<span class="str">"2"</span> aria-posinset=<span class="str">"7"</span> aria-setsize=<span class="str">"8"</span>></span>Tomato<span class="tag"></li></span>
<span class="tag"><li role=<span class="str">"treeitem"</span> aria-level=<span class="str">"2"</span> aria-posinset=<span class="str">"8"</span> aria-setsize=<span class="str">"8"</span>></span>Lettuce<span class="tag"></li></span>
<span class="tag"></ul></span>
<span class="tag"><li></span>
...</pre>
</li><li>
<p><a id="exampletree_states" name="exampletree_states"></a><strong>Use states and properties in response to events</strong></p>
<p>Control the behavior of the element in response to user input <a class="termref" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_event">events</a> such as from the keyboard and the mouse, which includes maintaining the current states and properties for that element. For example, a tree control will need to respond to click events on the expand/collapse triggers, and key events on the currently active descendant. Use device-independent events with supporting JavaScript to handle user interaction. For detailed examples of this please refer to the <a href="http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#aria_ex">Design Patterns section of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices</a> [<a href="#ref_ARIA-PRACTICES">ARIA-PRACTICES</a>].</p>
</li></ol>
</div>
</div>
<div class="section" id="reasons">
<h2><span class="tocnum">4. </span> Reasons for Adopting WAI-ARIA </h2>
<p>By adopting WAI-ARIA, both developers of static web sites and of dynamic Internet applications can improve the usability, accessibility, and scalability of their products. Developers of static web content can continue to follow the 1999 WCAG 1.0 standards, while improving usability and accessibility through the use of WAI-ARIA <a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#landmark_roles">landmark roles</a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> relationships, and properties like <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-invalid"><code>aria-invalid</code> (state)</a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-required"><code>aria-required</code></a> that can apply to HTML form controls. In richer, dynamic content, developers create custom widgets like calendars and spreadsheets based on technologies such as Ajax and CSS; to achieve accessibility, they need to use WCAG 2.0. Previously, when delivering rich Internet applications to users, to comply with WCAG 1.0, developers resorted to providing alternative, static content. While such measures met the WCAG 1.0 requirements, people using assistive technologies were not provided the richer user experience. When tables are used for layout, rather than CSS absolute positioning, historically, they have been problematic for assistive technologies to interpret. When the WAI-ARIA role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#presentation"><code>presentation</code></a> is used on such tables, the assistive technology ignores the table structure, providing a more accessible experience without requiring major recoding. </p>
<div class="section" id="tech_reasons">
<h3><span class="tocnum">4.1. </span> Technical Benefits </h3>
<p>Consider a rich Internet application where developers attempt to achieve keyboard accessibility using markup language. Without WAI-ARIA, results may be keyboard accessible but not highly usable; consider a user having to press Tab thirty times to put focus on a checkbox. To achieve keyboard accessibility in HTML without WAI-ARIA, developers must code active elements either as a link or as a form element. Accordingly, this means that no additional semantics are required or provided, other than that provided by the host language. In addition, WCAG 1.0 requires that content be renderable with Cascading Style Sheets turned off in the browser. This approach creates the following general usability problems:</p>
<ul><li>All keyboard-accessible controls must be either forms or anchors, forcing the user to tab through all focusable elements on the web page to navigate. If you need to navigate from the first link on the page to the last link on the page, that could be a very long trip and takes usability a step back.</li><li>Without WAI-ARIA semantics, you cannot provide contextual information to the user. </li><li> If you repurpose HTML elements you cannot provide the appropriate role and context information for the new widget. Lack of context is a serious usability problem. WAI-ARIA semantics results in providing contextual information to the user.</li><li>CSS is used for absolute positioning. If you remove that capability, usability features of widgets like pop-up menus disappear. Imagine activating the file menu and the menu showing up at the bottom of the page. </li></ul>
<p>WAI-ARIA and WCAG 2.0 coding techniques are useful for developing content and applications that can scale across a variety of user agents, including those on mobile devices. </p>
<p>For all these reasons, adopting WAI-ARIA makes good technical as well as business sense. For a further illustration, compare how accessibility is achieved with WCAG techniques without and with WAI-ARIA, as shown in <a href="#fig7">Figure 7.0</a>. </p>
<p id="fig7" class="ednote">Editor's Note: Figure 7, described as WAI-ARIA tree widget usability comparision, refers to a resource that has not yet been found.</p>
<p>Figure 7.0 Usability of Tree Widget Using WAI-ARIA Semantics to Implement WCAG 2.0 Guidelines Compared to WCAG 1.0 Without WAI-ARIA</p>
<p id="ariausability">
<a href="#fig7">Figure 7.0</a> shows an "accessible" widget for a tree item, within a tree widget, using WCAG 1.0 without WAI-ARIA, which ,when supplied to a screen reader, may say "link folder Year." There is no information to indicate that the folder is closed (<code><a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-expanded"><code>aria-expanded</code> (state)</a> = "false"</code>). There is no information to indicate its depth (<code><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-level"><code>aria-level</code></a>="2"</code>), position in the set and the set size at the level, all of which provides the user with context something sighted users may take for granted. The role is used to indicate that it is a treeitem which indicates that the item should behave and navigate with the keyboard like a tree item. A screen reader using the WAI-ARIA version might say "Closed Folder Year, Closed Folder one of two, Depth two, unchecked." Furthermore, the WAI-ARIA version can allow the tree items to be navigated with arrow keys and without requiring they be navigated as part of a global web page tabbing scheme. This is not what any user would expect of a tree widget. Finally, if you were told all widgets were links on the web page, consider how usable -- or not -- that would be.</p>
</div>
<div class="section" id="biz_reasons">
<h3><span class="tocnum">4.2. </span> Business Benefits </h3>
<p>If, as described above, coding techniques to achieve accessibility compliance do not promote overall usability, then business strategists must ask <em>"Why invest in accessibility?"</em> With WAI-ARIA, businesses can invest in accessible development and reap benefits for all users, not just those with disabilities or using assistive technologies. Some benefits include: </p>
<ul><li>Because WAI-ARIA is being developed through the PFWG with cooperation from browser and assistive technology vendors, accessibility and interoperability with those technologies will be easier to achieve, reducing or eliminating the need for per-browser and per-screenreader coding to achieve accessibility. </li><li>In addition to people with disabilities, all users benefit from WAI-ARIA because it establishes a Web-standard for keyboard interaction, easing the learning curve for users moving among applications, sites, and browsers. </li><li>Implementing WAI-ARIA can facilitate test automation. Test engines require semantic information about user interface elements, unique names, exposure of state, specific properties in order to run automated test scripts. WAI-ARIA provides that semantic information needed for efficient test automation.</li></ul>
</div>
</div>
<div class="section" id="conclusions">
<h2><span class="tocnum">5. </span> Conclusions</h2>
<p>This primer is designed to address the accessibility of
dynamic, scripted, Web content that may be rendered in today's
browsers while bridging to future declarative standards, such as
XHTML2, in the W3C. The extensions being created for XHTML 1.X are
intended to be cross-cutting. This primer clearly indicates that
the <cite><a href="http://www.w3.org/TR/WCAG20/">Web Content Accessibility Guidelines (WCAG)</a></cite> [<cite><a href="#ref_WCAG20">WCAG20</a></cite>], the <cite><a href="http://www.w3.org/TR/ATAG20/">Authoring Tool Accessibility Guidelines (ATAG)</a></cite> [<cite><a href="#ref_ATAG2">ATAG2</a></cite>], and the <cite><a href="http://www.w3.org/TR/UAAG20/">User Agent Accessibility Guidelines (UAAG)</a></cite> [<cite><a href="#ref_UAAG">UAAG</a></cite>] should be in lock step for a common strategy.
The web, tool, and user agent groups are effected and are interdependent. Additionally, close
work with mainstream working groups, like HTML, CSS, and Device
Independence will not only produce a working solution but it will
produce a working solution that will have a broader impact than
just XHTML. Moreover, this convergence stands to benefit users and businesses in significant measure. </p>
</div>
<div class="section" id="appendix">
<h2><span class="tocnum">6. </span> Appendices</h2>
<div class="section" id="gaphtml">
<h3><span class="tocnum">6.1. </span> Gap Analysis - Filling the Gaps for (X)HTML in Support of Accessibility API</h3>
<table border="1"><caption>
<a id="gapanalysishtml" name="gapanalysishtml"></a>Table 2.0 GAP
Analysis - Progressive Filling of the Gaps for (X)HTML in support of
Accessibility API
</caption><tbody><tr><th width="242" rowspan="1" colspan="1">Required Components</th><th width="521" rowspan="1" colspan="1">Who does what today? (X)HTML</th><th width="749" rowspan="1" colspan="1"> Technique to fill the gaps for HTML 4.01, and XHTML 1.X</th></tr><tr><th align="left" rowspan="1" colspan="1">Events:</th><td rowspan="1" colspan="1"> </td><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">FocusChange</td><td rowspan="1" colspan="1"><cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-uievents">DOM 2 UI
Events</a></cite> ([<cite><a href="#ref_DOM-EVENTS">EVENTS</a></cite>], Section 1.6.1) </td><td rowspan="1" colspan="1"><cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-uievents">DOM 2 UI
Events</a></cite> ([<cite><a href="#ref_DOM-EVENTS">EVENTS</a></cite>], Section 1.6.1) </td></tr><tr><td rowspan="1" colspan="1">Activation</td><td rowspan="1" colspan="1"><cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-UIEvent">DOM Level 2 Device Independent
UI Events</a></cite> ([<cite><a href="#ref_DOM-EVENTS">EVENTS</a></cite>], Section 1.6.1, UIEvent) </td><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">Caret Change</td><td rowspan="1" colspan="1">User Agent API </td><td rowspan="1" colspan="1">User Agent API</td></tr><tr><td rowspan="1" colspan="1"><a id="valuechange" name="valuechange"></a>* Value Change</td><td rowspan="1" colspan="1"> </td><td rowspan="1" colspan="1">User Agent to monitor valuenow, valuemax, and valuemin states in the WAI-ARIA Roles, States, and Properties for (X)HTML. For properties representing
platform accessibility API values as specified by a given role, it
will generate an accessible value change event. (See <a href="#StateChange">State Change Event</a> below). </td></tr><tr><td rowspan="1" colspan="1"><a id="StateChange" name="StateChange"></a>* State Change</td><td rowspan="1" colspan="1"> </td><td rowspan="1" colspan="1"><p>User Agent to monitor specific
accessibility states and properties in the WAI-ARIA Roles, States, and Properties for (X)HTML. For states and properties representing
platform accessibility API states or properties specified by a given role, it
will generate an accessible state or property change event. (See <a href="#StateChange">State Change Event</a> below). </p></td></tr><tr><td rowspan="1" colspan="1">Selection Change</td><td rowspan="1" colspan="1">User Agent API</td><td rowspan="1" colspan="1">User Agent API</td></tr><tr><td rowspan="1" colspan="1">Mutation</td><td rowspan="1" colspan="1">DOM Events</td><td rowspan="1" colspan="1">DOM Events mapping</td></tr><tr><th align="left" rowspan="1" colspan="1">Accessible
Actions:</th><td rowspan="1" colspan="1"> </td><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">* Event Handler functional information and descriptive
shortcuts</td><td rowspan="1" colspan="1"> </td><td rowspan="1" colspan="1"> </td></tr><tr><td rowspan="1" colspan="1">* Access to the available event
handlers for enumerating the actions</td><td rowspan="1" colspan="1">DOM 3 Events</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">* State Information:</th><td rowspan="1" colspan="1"> </td><td rowspan="1" colspan="1">States and properties form WAI-ARIA Roles, States, and Properties specification</td></tr><tr><th align="left" rowspan="1" colspan="1">* Role Information:</th><td rowspan="1" colspan="1">Limited to standard HTML tag names. (Mix
Content/presentation)</td><td rowspan="1" colspan="1"><p>Roles and their corresponding values as defined by the WAI-ARIA Roles, States and properties specification</p></td></tr><tr><th align="left" rowspan="1" colspan="1">Relationships: Parent/child</th><td rowspan="1" colspan="1">Limited DOM (affected by style) (Mix Content/presentation)</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Relationships: (Label, MemberOf - Group,
ControllerFor)</th><td rowspan="1" colspan="1">Limited to HTML (Title, alt, label)</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Text:</th><td rowspan="1" colspan="1">Core DOM 1 from parsed HTML</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Content selection:</th><td rowspan="1" colspan="1">User Agent</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Font/Font Style Information:</th><td rowspan="1" colspan="1">Can set but can't get final format</td><td rowspan="1" colspan="1">User Agents final format styling
using CSS2 APIs or platform accessibility APIs</td></tr><tr><th align="left" rowspan="1" colspan="1">* Description/Help:</th><td rowspan="1" colspan="1">limited to HTML 4.0 - Alt Text, title text</td><td rowspan="1" colspan="1">The describedby property as defined in the WAI-ARIA Roles, States, and Properties specification WAI-ARIA] </td></tr><tr><th align="left" rowspan="1" colspan="1">* Accessible value:</th><td rowspan="1" colspan="1">limited to form elements</td><td rowspan="1" colspan="1">The valuenow, valuemax, and valuemin properties as defined in the WAI-ARIA Roles, States, and Properties specification WAI-ARIA] </td></tr><tr><th align="left" rowspan="1" colspan="1">Coordinates (Bounding rectangle, etc.):</th><td rowspan="1" colspan="1">User Agents. platform accessibility API</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Accessible Name:</th><td rowspan="1" colspan="1">User Agent determines from HTML tag</td><td rowspan="1" colspan="1"> </td></tr><tr><th rowspan="1" colspan="1">* Respond Desktop Font/Color Changes</th><td rowspan="1" colspan="1">partial (conflicts with CSS and JavaScript)</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">* Device independent navigation:</th><td rowspan="1" colspan="1">Use of XHTML landmarks through the <link rel""></td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">*Accessibility API Mapping:</th><td rowspan="1" colspan="1">partial - User Agents</td><td rowspan="1" colspan="1"> </td></tr><tr><th align="left" rowspan="1" colspan="1">Provide focus to all active elements</th><td rowspan="1" colspan="1">TABINDEX=-1 best practice</td><td rowspan="1" colspan="1"> </td></tr></tbody></table>
<p><a href="#gapanalysishtml">Table 2.0</a> shows the roadmap for filling the gaps in Table 1.0 for (X)HTML. The effort is
designed to fill the gaps for HTML content using the <a href="http://www.w3.org/WAI/PF/adaptable/HTML4/">W3C
technique to embed role and state attributes into HTML
documents</a>. Required components
marked with an asterisk indicate gaps to fill in the roadmap. </p>
</div>
<div class="section" id="longdesc">
<h3><span class="tocnum">6.2. </span> Long Descriptions of Figures</h3>
<p>For graphics that need longer descriptions, see the following items.</p>
<ul><li><a href="#ld_fig1">Long Description of Figure 1.0</a></li><li><a href="#ld_fig2">Long Description of Figure 2.0</a></li></ul>
<div class="section" id="ld_fig1">
<h4><span class="tocnum">6.2.1. </span> Long Description of Figure 1.0 Accessibility Interoperability at a DOM Node without JavaScript</h4>
<p><a href="#fig1">Figure 1.0</a> shows how a document element is extended by an accessibility contract that filters communication between Assistive Technology (AT) and the Document Element (Controller). In a Model-View-Controller scenario, the:</p>
<ul><li>Model provides the Data for the DOM Node.</li><li>View is the user interface for a standard user agent. </li><li>Controller is the Document Element semantics</li></ul>
<p>Through the Contract with the AT:</p>
<ul><li>Input is received form the Document Element controller and passed to the AT through the contract filter. </li><li>Input is received from the user and passed to the Document Element controller through the contract filter. </li></ul>
<p>Attributes of the contract include: </p>
<ul><li>Role </li><li>States</li><li>Actions </li><li>Caret </li><li>Selection </li><li>Text </li><li>Hyper Text </li><li>Value </li><li>Name </li><li>Description </li><li>Children </li><li>Changes </li><li>Relations </li></ul>
</div>
<div class="section" id="ld_fig2">
<h4><span class="tocnum">6.2.2. </span> Long Description of Figure 2.0 Accessibility Interoperability at a DOM Node with JavaScript</h4>
<p><a href="#fig2">Figure 2.0</a> shows that with JavaScript, the AT Contract described in <a href="#fig1">Figure 1.0</a> is discarded. When JavaScript is used, JavaScript widgets replace the normal document element controller with a substitute controller defined by the JavaScript.
With JavaScript the AT Contract is discarded. The Java script manipulates the document data (DOM), the document elements (content), the user interface (style). It is driven by external events and produces custom widgets. Key elements of the contract including role, states, action, value, changes and relations are not communicated with assistive technology (AT). </p>
</div>
</div>
<div class="section" id="references">
<h3><span class="tocnum">6.3. </span> References</h3>
<p>This section is <em>informative</em>.</p>
<p>Resources referenced informatively provide useful information relevant to this document, but do not comprise a part of its requirements.</p>
<dl><dt><a id="ref_ARIA" name="ref_ARIA"></a>[ARIA]</dt><dd><cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">Accessible
Rich Internet Applications (<acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym>) 1.0</a></cite>. J. Craig,
M. Cooper, L. Pappas, R. Schwerdtfeger, L. Seeman, Editors,
W3C Working Draft (work in progress), 16 September 2010. This version
of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> is
available at http://www.w3.org/TR/2010/WD-wai-aria-20100916/. <a href="http://www.w3.org/TR/wai-aria/">Latest
version of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym></a> available
at http://www.w3.org/TR/wai-aria/.</dd>
<dt><a id="ref_ARIA-PRACTICES" name="ref_ARIA-PRACTICES"></a>[ARIA-PRACTICES]</dt><dd><cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/"><acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym>
Authoring Practices</a></cite>. J. Scheuhammer, M. Cooper, L. Pappas,
R. Schwerdtfeger, Editors,
W3C Working Draft (work in progress), 16 September 2010. This version
of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> 1.0 Authoring Practices is available at http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/. <a href="http://www.w3.org/TR/wai-aria-practices/">Latest
version of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Authoring Practices</a> available at http://www.w3.org/TR/wai-aria-practices/. </dd><dt><a id="ref_ARIA-ROADMAP" name="ref_ARIA-ROADMAP"></a>[ARIA-ROADMAP]</dt><dd><cite><a href="http://www.w3.org/TR/2008/WD-wai-aria-roadmap-20080204/">Roadmap for Accessible Rich Internet Applications (<acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Roadmap)</a></cite>, R. Schwerdtfeger, Editor, W3C Working Draft (work in progress), 4 February 2008. This version of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Roadmap is available at http://www.w3.org/TR/2008/WD-wai-aria-roadmap-20080204/. <a href="http://www.w3.org/TR/wai-aria-roadmap/">Latest version of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Roadmap</a> available at http://www.w3.org/TR/wai-aria-roadmap/.</dd><dt><a name="ref_ATAG2" id="ref_ATAG2"></a>[ATAG2]</dt><dd> <cite><a href="http://www.w3.org/TR/2010/WD-ATAG20-20100708/">Authoring
Tool Accessibility Guidelines 2.0</a></cite>,
J. Richards, J. Spellman, J. Treviranus, M. May, Editors, W3C Working
Draft (work in progress), 8 July 2010, http://www.w3.org/TR/2010/WD-ATAG20-20100708/. <a href="http://www.w3.org/TR/ATAG20/" title="Latest version of Authoring Tool Accessibility Guidelines 2.0">Latest
version of ATAG 2.0</a> available at http://www.w3.org/TR/ATAG20/.</dd><dt><a name="ref_ATK" id="ref_ATK"></a>[ATK]</dt><dd><cite><a href="http://library.gnome.org/devel/atk/unstable/">Gnome Accessibility Toolkit</a></cite>. Available at http://library.gnome.org/devel/atk/unstable/.</dd><dt><a id="ref_AXAPI" name="ref_AXAPI"></a>[AXAPI]</dt><dd><cite><a href="http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html">The Mac OS X Accessibility Protocol</a></cite>. Available at: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html.</dd><dt><a class="normref" id="ref_DOM" name="ref_DOM"></a>[DOM]</dt><dd><cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/">Document Object Model (DOM) Level 2 Core Specification</a></cite>, L. Wood, G. Nicol, A. Le Hors, J. Robie, S. Byrne, P. Le Hégaret, M. Champion, Editors, W3C Recommendation, 13 November 2000, http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/. <a href="http://www.w3.org/TR/DOM-Level-2-Core/" title="Latest version of Document Object Model (DOM) Level 2 Core Specification">Latest version of DOM Core</a> available at http://www.w3.org/TR/DOM-Level-2-Core/.</dd><dt><a id="ref_DOM-EVENTS" name="ref_DOM-EVENTS"></a>[DOM-EVENTS]</dt><dd> <cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/">Document Object Model (DOM) Level 2 Events Specification</a></cite>, T. Pixley, Editor, W3C Recommendation, 13 November 2000, http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/. <a href="http://www.w3.org/TR/DOM-Level-2-Events/" title="Latest version of Document Object Model (DOM) Level 2 Events Specification">Latest version of DOM Events</a> available at http://www.w3.org/TR/DOM-Level-2-Events/.</dd><dt><a id="ref_JAPI" name="ref_JAPI"></a>[JAPI]</dt><dd><cite><a href="http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140174.html">Java Accessibility API (JAPI)</a></cite>.
Available at http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140174.html.</dd><dt><a id="ref_MSAA" name="ref_MSAA"></a>[MSAA]</dt><dd><cite><a href="http://msdn.microsoft.com/en-us/library/ms697707.aspx">Microsoft Active Accessibility (MSAA)</a></cite>. Available at http://msdn.microsoft.com/en-us/library/ms697707.aspx.</dd><dt><a id="ref_OWL" name="ref_OWL"></a>[OWL]</dt><dd><cite><a href="http://www.w3.org/TR/2004/REC-owl-features-20040210/">OWL Web Ontology Language Overview</a></cite>, D. L. McGuinness, F. van Harmelen, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/. <a href="http://www.w3.org/TR/owl-features/" title="Latest version of OWL Web Ontology Language Overview">Latest version of OWL Overview</a> available at http://www.w3.org/TR/owl-features/.</dd><dt><a class="normref" id="ref_RDF" name="ref_RDF"></a>[RDF]</dt><dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/">Resource Description Framework (RDF): Concepts and Abstract Syntax</a></cite>, G. Klyne, J. J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. <a href="http://www.w3.org/TR/rdf-concepts/" title="Latest version of Resource Description Framework (RDF): Concepts and Abstract Syntax">Latest version of RDF Concepts</a> available at http://www.w3.org/TR/rdf-concepts/.</dd><dt><a name="ref_ROLE" id="ref_ROLE"></a>[ROLE]</dt><dd><a href="http://www.w3.org/TR/2010/WD-role-attribute-20100916/">Role Attribute</a>,
S. McCarron, Editor, W3C Working Draft (work in progress), 5 August
2010, http://www.w3.org/TR/2010/WD-role-attribute-20100916/. <a href="http://www.w3.org/TR/role-attribute/">Latest
version of Role Attribute</a> available at http://www.w3.org/TR/role-attribute/.</dd><dt><a id="ref_UAAG" name="ref_UAAG"></a>[UAAG]</dt><dd><cite><a href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/">User Agent Accessibility Guidelines 1.0</a></cite>, I. Jacobs, J. Gunderson, E. Hansen, Editors, W3C Recommendation, 17 December 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/. <a href="http://www.w3.org/TR/UAAG10/" title="Latest version of User Agent Accessibility Guidelines 1.0">Latest version</a> available at http://www.w3.org/TR/UAAG10/.</dd><dt><a id="ref_UIAUTOMATION" name="ref_UIAUTOMATION"></a>[UIAUTOMATION]</dt><dd><cite><a href="http://msdn.microsoft.com/en-ca/windows/bb735024.aspx">Microsoft Accessibility Model (UI Automation)</a></cite>. Available at http://msdn.microsoft.com/en-ca/windows/bb735024.aspx.</dd><dt><a id="ref_WCAG1" name="ref_WCAG1"></a>[WCAG1]</dt><dd> <cite><a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">Web Content Accessibility Guidelines 1.0</a></cite>, W. Chisholm, G. Vanderheiden, I. Jacobs, Editors, W3C Recommendation, 5 May 1999, http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/. <a href="http://www.w3.org/TR/WAI-WEBCONTENT/" title="Latest version of Web Content Accessibility Guidelines 1.0">Latest version of WCAG 1.0</a> available at http://www.w3.org/TR/WAI-WEBCONTENT/.</dd><dt><a id="ref_WCAG20" name="ref_WCAG20"></a>[WCAG20]</dt><dd> <cite> <a href="http://www.w3.org/TR/2007/WD-WCAG20-20071211/">Web Content Accessibility Guidelines 2.0</a></cite>, B. Caldwell, G. Vanderheiden, L. Guarino Reid, M. Cooper, Editors, W3C Working Draft (work in progress), 11 December 2007, http://www.w3.org/TR/2007/WD-WCAG20-20071211/. <a href="http://www.w3.org/TR/WCAG20/" title="Latest version of Web Content Accessibility Guidelines 2.0">Latest version of WCAG 2.0 </a> available at http://www.w3.org/TR/WCAG20/.</dd></dl>
</div>
<div class="section" id="acknowledgements">
<h3><span class="tocnum">6.4. </span> Acknowledgments</h3>
<p>The following people contributed to the development of this document.</p>
<div class="section" id="ack_group">
<h4><span class="tocnum">6.4.1. </span> Participants in the PFWG at the time of publication</h4>
<ol><li>David Bolter (Invited Expert, University of Toronto Adaptive Technology Resource Centre) </li><li>Sally Cain (Royal National Institute of Blind People)</li><li>Ben Caldwell (Invited Expert, Trace)</li><li>Charles Chen (Google, Inc.) </li><li>Michael Cooper (W3C/MIT)</li><li>James Craig (Apple, Inc.) </li><li>Dimitar Denev (Frauenhofer Gesellschaft)</li><li>Steve Faulkner (Invited Expert, The Paciello Group) </li><li>Kentarou Fukuda (IBM Corporation)</li><li>Andres Gonzalez (Adobe Systems Inc.)</li><li>Georgios Grigoriadis (SAP AG) </li><li>Jon Gunderson (Invited Expert, UIUC)</li><li>Markus Gylling (DAISY Consortium)</li><li>Sean Hayes (Microsoft Corporation)</li><li>John Hrvatin (Microsoft Corporation) </li><li>Kenny Johar (Vision Australia) </li><li>Masahiko Kaneko (Microsoft Corporation) </li><li>Matthew King (IBM Corporation)</li><li>Diego La Monica (International Webmasters Association / HTML Writers Guild (IWA-HWG)) </li><li>Gez Lemon (International Webmasters Association / HTML Writers Guild (IWA-HWG))</li><li>Thomas Logan (HiSoftware Inc.)</li><li>William Loughborough (Invited Expert)</li><li>Anders Markussen (Opera Software) </li><li>Matthew May (Adobe Systems Inc.) </li><li>Shane McCarron (Invited Expert, Aptest)</li><li>Charles McCathieNevile (Opera Software)</li><li>James Nurthen (Oracle Corporation) </li><li>Joshue O'Connor (Invited Expert) </li><li>Artur Ortega (Yahoo!, Inc.)</li><li>Simon Pieters (Opera Software) </li><li>T.V. Raman (Google, Inc.) </li><li>Gregory Rosmaita (Invited Expert)</li><li>Tony Ross (Microsoft Corporation)</li><li>Janina Sajka (Invited Expert, The Linux Foundation)</li><li>Martin Schaus (SAP AG) </li><li>Joseph Scheuhammer (Invited Expert, Inclusive Design Research Centre, OCAD University) </li><li>Stefan Schnabel (SAP AG) </li><li>Richard Schwerdtfeger (IBM Corporation)</li><li>Lisa Seeman (Invited Expert, Aqueous) </li><li>Cynthia Shelly (Microsoft Corporation) </li><li>Andi Snow-Weaver (IBM Corporation)</li><li>Henny Swan (Opera Software)</li><li>Gregg Vanderheiden (Invited Expert, Trace)</li><li>Léonie Watson (Invited Expert, Nomensa)</li><li>Gottfried Zimmermann (Invited Expert, Access Technologies Group)</li></ol>
</div>
<div class="section" id="ack_others">
<h4><span class="tocnum">6.4.2. </span> Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification</h4>
<p>Special thanks to Aaron Leventhal for effort and insight as he implemented a working prototype of accessibility <abbr title="Application Programming Interface">API</abbr> bindings. Special thanks to Al Gilman for his work while chair of the PFWG in bringing the ARIA technology to fruition.</p>
<p> Jim Allan (TSB), Simon Bates, Chris Blouch (AOL), Judy Brewer (W3C/MIT),
Christian Cohrs, Donald Evans (AOL), Geoff Freed (WGBH/NCAM), Becky
Gibson (IBM), Alfred S. Gilman, Andres Gonzalez (Adobe), Jeff Grimes
(Oracle), Barbara Hartel, Earl Johnson (Sun), Jael Kurz, Aaron Leventhal
(IBM Corporation), Alex Li (SAP), Linda Mao (Microsoft), Shane McCarron
(ApTest), Lisa Pappas (Society for Technical Communication (STC)),
Dave Pawson (RNIB), David Poehlman, Marc Silbey (Microsoft Corporation),
Henri Sivonen (Mozilla), Vitaly Sourikov, Mike Squillace (IBM), Ryan Williams
(Oracle), Tom Wlodkowski.</p>
</div>
<div class="section" id="ack_funders">
<h4><span class="tocnum">6.4.3. </span> Enabling funders</h4>
<p>This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.</p>
</div>
</div>
</div>
</body></html>