-
Notifications
You must be signed in to change notification settings - Fork 126
/
Copy pathindex.html
3174 lines (3123 loc) · 177 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>SVG Accessibility API Mappings</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove" defer="defer"></script>
<script src="../common/script/resolveReferences.js" class="remove"></script>
<script src="../common/biblio.js" class="remove" defer="defer"></script>
<script src="../common/script/participants.js" class="remove"></script>
<link href="../common/css/mapping-tables.css" rel="stylesheet" type="text/css" />
<link href="../common/css/common.css" rel="stylesheet" type="text/css" />
<!--<link href="css/svg-aam.css" rel="stylesheet" type="text/css"/>-->
<script class="remove">
var respecConfig = {
doJsonLd: true,
// specification status (e.g., WD, LC, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
//crEnd: "2012-04-30",
//perEnd: "2013-07-23",
//publishDate: "2016-08-18",
// the specifications short name, as in http://www.w3.org/TR/short-name/
shortName: "svg-aam-1.0",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
copyrightStart: "2015",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
previousPublishDate: "2016-09-08",
previousMaturity: "WD",
//prevRecURI: "http://www.w3.org/TR/2014/REC-wai-aria-implementation-20140320/",
//previousDiffURI: "http://www.w3.org/TR/2014/REC-wai-aria-implementation-20140320/",
// if there a publicly available Editors Draft, this is the link
github: "w3c/svg-aam",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2012-02-21",
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Amelia Bellamy-Royds", company: "Invited Expert", mailto: "[email protected]", w3cid: 75809 },
{ name: "Ian Pouncey", company: "The Paciello Group, LLC", companyURI: "https://www.paciellogroup.com/", mailto: "[email protected]", w3cid: 44477 },
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
authors: [
{
name: "Amelia Bellamy-Royds",
company: "Invited Expert",
mailto: "[email protected]",
w3cid: 75809,
},
{ name: "Ian Pouncey", company: "The Paciello Group, LLC", companyURI: "https://www.paciellogroup.com/", mailto: "[email protected]", w3cid: 44477 },
{
name: "Richard Schwerdtfeger",
mailto: "[email protected]",
company: "Knowbility",
companyURI: "https://www.knowbility.org/",
w3cid: 2460,
note: "until August 2017",
},
{
name: "Doug Schepers",
mailto: "[email protected]",
company: "W3C",
companyURI: "https://www.w3.org/",
w3cid: 38635,
note: "until December 2016",
},
],
/*
alternateFormats: [
{ uri: 'svg-aam-diff.html',
label: "Diff from Previous Recommendation" } ,
{ uri: 'svg-aam.ps',
label: "PostScript version" },
{ uri: 'svg-aam.pdf',
label: "PDF version" }
],
*/
// Working group info
wg: ["SVG Working Group"],
wgURI: ["https://www.w3.org/Graphics/SVG/WG/wiki/Main_Page"],
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: ["https://www.w3.org/2004/01/pp-impl/19480/status"],
tocIntroductory: true,
//maxTocLevel: 4,
// spec URLs
ariaSpecURLs: {
ED: "https://w3c.github.io/aria/",
FPWD: "https://www.w3.org/TR/wai-aria-1.3/",
WD: "https://www.w3.org/TR/wai-aria-1.3/",
CR: "https://www.w3.org/TR/wai-aria-1.3/",
REC: "https://www.w3.org/TR/wai-aria-1.3/",
},
accNameURLs: {
ED: "https://w3c.github.io/accname/",
WD: "https://www.w3.org/TR/accname-1.2/",
FPWD: "https://www.w3.org/TR/accname-1.2/",
CR: "https://www.w3.org/TR/accname-1.2/",
REC: "https://www.w3.org/TR/accname-1.2/",
},
coreMappingURLs: {
ED: "https://w3c.github.io/core-aam/",
WD: "https://www.w3.org/TR/core-aam-1.2/",
FPWD: "https://www.w3.org/TR/core-aam-1.2/",
CR: "https://www.w3.org/TR/core-aam-1.2/",
REC: "https://www.w3.org/TR/core-aam-1.2/",
},
dpubModURLs: {
ED: "https://w3c.github.io/dpub-aria/",
FPWD: "https://www.w3.org/TR/dpub-aria-1.1/",
WD: "https://www.w3.org/TR/dpub-aria-1.1/",
REC: "https://www.w3.org/TR/dpub-aria-1.1/",
},
graphicsMappingModURLs: {
ED: "https://w3c.github.io/graphics-aam/",
FPWD: "https://www.w3.org/TR/graphics-aam-1.0/",
WD: "https://www.w3.org/TR/graphics-aam-1.0/",
CR: "https://www.w3.org/TR/graphics-aam-1.0/",
PR: "https://www.w3.org/TR/graphics-aam-1.0/",
REC: "https://www.w3.org/TR/graphics-aam-1.0/",
},
graphicsModURLs: {
ED: "https://w3c.github.io/graphics-aria/",
FPWD: "https://www.w3.org/TR/graphics-aria/",
WD: "https://www.w3.org/TR/graphics-aria/",
REC: "https://www.w3.org/TR/graphics-aria/",
},
htmlMappingURLs: {
ED: "https://w3c.github.io/html-aam/",
FPWD: "https://www.w3.org/TR/html-aam-1.0/",
WD: "https://www.w3.org/TR/html-aam/",
REC: "https://www.w3.org/TR/html-aam/",
},
practicesURLs: {
ED: "https://www.w3.org/WAI/ARIA/apg/",
WD: "https://www.w3.org/WAI/ARIA/apg/",
FPWD: "https://www.w3.org/WAI/ARIA/apg/",
CR: "https://www.w3.org/WAI/ARIA/apg/",
REC: "https://www.w3.org/WAI/ARIA/apg/",
},
preProcess: [linkCrossReferences, getParticipants],
};
</script>
</head>
<body>
<section id="abstract">
<p>
SVG Accessibility API Mappings (SVG-AAM) defines how
<a class="termref" data-lt="User Agent">user agents</a> map Scalable Vector Graphics (SVG) [[!SVG2]] markup to platform
<a class="termref" data-lt="accessibility api">accessibility application programming interfaces (<abbr title="Application Programming Interfaces">APIs</abbr>)</a>. It is intended for SVG user
agent developers responsible for SVG accessibility in their user agent.
</p>
<p>
This specification allows SVG authors to create accessible rich internet applications, including charts, graphs, and other drawings. It does this by extending the
<cite><a href="http://www.w3.org/TR/core-aam-1.1/">Core Accessibility API Mappings 1.1</a></cite> (CORE-AAM) [[!CORE-AAM]] and the
<cite><a href="http://www.w3.org/TR/accname-1.1/">Accessible Name and Description: Computation and API Mappings 1.1</a></cite> (ACCNAME-AAM) [[!ACCNAME-AAM]] specifications for user agents. It
leverages those core mappings and provides SVG-specific guidance to define how the SVG user agent must respond to keyboard focus and <a class="termref" data-lt="role">role</a>,
<a class="termref" data-lt="State">state</a>, and <a class="termref" data-lt="Property">property</a> attributes provided in Web content via
<cite
><a href="http://www.w3.org/TR/wai-aria-1.1/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr></a></cite
>
[[!WAI-ARIA]]. The SVG-AAM also adapts the ACCNAME-AAM to make use of standard SVG features used to compute accessible names and description information exposed by platform accessibility
<abbr title="Application Programming Interfaces">APIs</abbr>.
</p>
<p>
The SVG-AAM is part of the
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> suite described in the
<a href="http://www.w3.org/WAI/intro/aria.php"><abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Overview</a>.
</p>
</section>
<section id="sotd">
<p>This document is a work in progress.</p>
<p>
To provide feedback, please <a href="https://github.com/w3c/svg-aam/issues/">create or comment on an issue</a> in the <abbr title="World Wide Web Consortium">W3C</abbr> SVG Accessibility API
Mappings GitHub repository. If this is not feasible, send email to <a href="mailto:[email protected]?subject=SVG%20AAM%20public%20comment">[email protected]</a> (<a
href="https://lists.w3.org/Archives/Public/www-svg/"
>email archive</a
>). In-progress updates to the document may be viewed in the <a href="https://w3c.github.io/svg-aam/">publicly visible editors' draft</a>.
</p>
<p>Particularly problematic open issues are highlighted in this document, with links to the GitHub discussion. Comments on these issues would be particularly appreciated.</p>
<p>Relative to the last published working draft (8 September 2016), the following major changes have been made:</p>
<ul>
<li>The handling of <code>use</code> element shadow DOM content has changed.</li>
<li>The roles for determining whether an element is hidden have been simplified, and coordinated with changes to other WAI-ARIA specifications.</li>
</ul>
<p>In addition, there have been numerous clarifying edits.</p>
<p>
This document was initially developed jointly by the <a href="https://www.w3.org/WAI/ARIA/">Accessible Rich Internet Applications Working Group</a> and the
<a href="https://www.w3.org/Graphics/SVG/WG/wiki/Main_Page"><abbr title="Scalable Vector Graphics">SVG</abbr> Working Group</a>, through the
<a href="http://www.w3.org/WAI/PF/svg-a11y-tf/"><abbr title="Scalable Vector Graphics">SVG</abbr> Accessibility Task Force</a>. It continues to be produced in coordination with other
specifications developed by the ARIA Working Group.
</p>
</section>
<section id="intro" class="informative">
<h2>Introduction</h2>
<p>
This specification defines how SVG host language elements and content — with or without <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles, states, and properties
applied — map to accessibility <abbr title="Application Programming Interfaces">APIs</abbr>. Sections give guidance on calculating text alternatives, mapping actions to
<a class="termref" data-lt="event">events</a>, event processing, special document handling procedures, and error handling.
</p>
<p>
This introduction provides some background on why this specification exists, and how it relates to other WAI-ARIA specifications. It includes a general overview of accessibility
<abbr title="Application Programming Interfaces">APIs</abbr> and the hierarchy of <a class="termref" data-lt="accessible object">accessible objects</a> known as the
<a class="termref">accessibility tree</a>.
</p>
<section id="intro_history">
<h3>History and Purpose</h3>
<p>
In traditional Graphical User Interface (GUI) applications, components of the User Interface (UI) are displayed when needed and hidden when not needed based on user interactions.
<a class="termref" data-lt="Accessibility API">Accessibility APIs</a> are used to communicate
<a class="termref" data-lt="Semantics">semantics</a>
about the user interface to
<a class="termref" data-lt="Assistive Technologies">assistive technologies</a>
used by people with disabilities.
</p>
<p>
These <abbr title="application programming interfaces">APIs</abbr> constitute a contract between applications and assistive technologies, such as screen readers, magnifiers, alternate input
devices, and speech command and control, to enable them to access the appropriate semantics needed to produce a usable alternative to interactive applications or complex documents. For
example, screen-reading software for blind users can determine whether a particular <abbr title="user interface">UI</abbr> component is a menu, button, text field, list box, etc. It can also
present the information in tables or lists in a way that provides context for each piece of text.
</p>
<p>
For web documents and applications, the essential semantic information is encapsulated within the Document Object Model (<abbr title="Document Object Model">DOM</abbr>). Assistive
technologies obtain this information from the <a>user agent</a> (web browser), which maps elements and attributes to the platform Accessibility
<abbr title="Application Programming Interface">API</abbr>.
</p>
<p>
In Scalable Vector Graphics (SVG) documents, most SVG <a class="termref" data-lt="Element">elements</a>
do not provide semantic information of value to assistive technologies. Instead, they represent low-level vector graphics drawing directives. That element only has meaning to assistive
technologies if the author provides alternative text, descriptions, or WAI-ARIA semantics.
</p>
<p>
Both version 1 [[SVG1]] and version 1.1 [[SVG11]] of the SVG specifications included elements for defining <a>accessible names</a> and
<a data-lt="accessible description">descriptions</a> (<code><title></code> and <code><desc></code>). However, prior to this specification, there was no normative guidance as to
how user agents should expose this information to assistive technologies, or how to integrate it with host languages and validators that support WAI-ARIA. There was similarly no guidance on
how user agents should make interactive SVG <a>keyboard accessible</a>.
</p>
<p>
SVG 2 now incorporates keyboard navigation based on the established model from HTML 5. The <a class="termref" data-lt="user agent">user agent</a> provides sequential focus navigation to
<abbr title="Scalable Vector Graphics">SVG</abbr> elements that are interactive by default (links and audio/video elements with controls), or that the author has indicated may receive focus
(through the use of <code>tabindex</code> attribute). Focus may also be set or removed programmatically by scripts, so that authors may implement more complex keyboard focus patterns.
</p>
<p>
SVG closely aligns with the core DOM Standard [[DOM]], supporting JavaScript manipulation of the graphic in interactive environments. Through the use of JavaScript,
<abbr title="cascading style sheets">CSS</abbr>, and related APIs, authors can make SVG look and behave as an interactive application, to produce rich interactive charts and drawings.
</p>
<p>
To allow the author to express and dynamically update their intended semantics in both static and interactive graphics, SVG 2 supports the use of
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles, states, and properties. Authors may include
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> attributes in their markup and user agents will translate it to the platform accessibility
<abbr title="application programming interfaces">APIs</abbr>.
</p>
<p>
WAI-ARIA enables rich SVG-drawn Internet applications to have the same accessibility features as
<abbr title="graphical user interface">GUI</abbr> applications installed on their operating system. In complex static graphics, WAI-ARIA provides the missing document structure that is
provided in HTML by semantic elements.
</p>
</section>
<section id="intro_wai-aria_suite">
<h3>Relationship to Other Specifications</h3>
<p>
For an introduction to <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>, see the
<a href="http://www.w3.org/WAI/intro/aria.php"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Overview</a>.
</p>
<p>
The SVG Accessibility API Mappings specification (this document) defines how <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> features interact with the native semantics
of the SVG language. It is part of a set of resources that define and support the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> specification, including the following
documents:
</p>
<ul>
<li>
<cite><a href="http://www.w3.org/TR/wai-aria-1.1/">Accessible Rich Internet Applications (WAI-ARIA) 1.1</a></cite> [[WAI-ARIA]], a planned
<abbr title="World Wide Web Consortium">W3C</abbr> recommendation that extends the exising ARIA standard [[WAI-ARIA-10]]. It defines the core roles, states, and properties.
</li>
<li>
<cite><a href="http://www.w3.org/TR/graphics-aria-1.0/">WAI-ARIA Graphics Module</a></cite> [[GRAPHICS-ARIA]], a planned <abbr title="World Wide Web Consortium">W3C</abbr> recommendation
that defines graphics roles, states, and properties not included in
<cite><a href="http://www.w3.org/TR/wai-aria-1.1/">Accessible Rich Internet Applications (WAI-ARIA) 1.1</a></cite> [[WAI-ARIA]].
</li>
<li>
<cite><a href="http://www.w3.org/TR/core-aam-1.1/">Core Accessibility API Mappings</a></cite> specification [[CORE-AAM]], which expresses how
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a href="#dfn-role" class="termref">roles</a>, <a href="#dfn-state" class="termref">states</a>, and
<a href="#dfn-property" class="termref">properties</a> should be supported in user agents using platform accessibility <abbr title="Application Programming Interfaces">APIs</abbr>.
</li>
<li>
<cite><a href="http://www.w3.org/TR/graphics-aam-1.0/">Graphics Accessibility API Mappings</a></cite
>[[GRAPHICS-AAM]], a planned <abbr title="World Wide Web Consortium">W3C</abbr> recommendation, which expresses how
<cite><a href="http://www.w3.org/TR/graphics-aria-1.0/">WAI-ARIA Graphics Module</a></cite> [[GRAPHICS-ARIA]] <a href="#dfn-role" class="termref">roles</a>,
<a href="#dfn-state" class="termref">states</a>, and <a href="#dfn-property" class="termref">properties</a> should be supported in user agents using platform accessibility
<abbr title="Application Programming Interfaces">APIs</abbr>.
</li>
<li>
<cite><a href="http://www.w3.org/TR/accname-1.1/">Accessible Name and Description: Computation and API Mappings 1.1</a></cite> [[ACCNAME-AAM]], which outlines the specific steps user
agents should follow in order to identify accessible names (labels) and descriptions (alternative text) for elements that are exposed to assistive technologies.
</li>
<li>
<cite
><a href="https://www.w3.org/TR/wai-aria-practices-1.1/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Authoring Practices Guide</a></cite
>
[[ARIA-PRACTICES]], a W3C Working Group Note, which describes how web content developers can develop accessible rich internet applications using
<abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>. It provides detailed advice and examples directed primarily to web application developers, yet also useful to
developers of user agents and assistive technologies.
</li>
</ul>
<p>
This guide relies heavily on the accessibility <abbr title="Application Programming Interface">API</abbr> mappings defined in the
<a href="" class="core-mapping">Core Accessibility API Mappings</a>
and
<a href="" class="accname">Accessible Name and Description</a>
specifications ([[CORE-AAM]] and [[ACCNAME-AAM]]) but defines changes in mappings due to features in the SVG host language [[SVG2]]. Key areas of difference stem from the intrinsic host
language semantics of SVG:
</p>
<ul>
<li>The procedure for mapping the DOM tree to the accessibility tree is designed to simplify that tree to only include elements with semantic importance.</li>
<li>SVG elements are assigned default roles and properties, which in many cases are conditional on whether they meet the criteria for inclusion in the accessibility tree.</li>
<li>Text computation of names and descriptions use the SVG metadata elements.</li>
<li>Implicit ARIA states (such as whether an element is hidden) must be updated in response to SVG animations.</li>
</ul>
</section>
<section id="intro_aapi">
<h3>Accessibility <abbr title="Application Programming Interfaces">APIs</abbr></h3>
<p>
To provide access to <abbr title="graphical user interface">GUI</abbr> applications, software applications expose the necessary information needed by
<a class="termref" data-lt="assistive-technology">assistive technologies</a> to interoperate with it through
<a class="termref">accessibility <abbr title="Application Programming Interfaces">API</abbr>s</a>. The accessibility information exposed through the
<a class="termref">accessibility <abbr title="Application Programming Interfaces">API</abbr>s</a> must be maintained throughout the applications lifecycle.
</p>
<p>
In Web pages the Document Object Model (DOM) is used to represent the structure and <a href="#dfn-state" class="termref">state</a> of the <a class="termref" data-lt="element">elements</a> in
the document being rendered by a <a class="termref" data-lt="user agent">user agent</a>. The elements of the document are organized into a hierarchy of nodes known as the
<abbr title="document object model">DOM</abbr> tree. User agents map <abbr title="Document Object Model">DOM</abbr> to accessibility
<abbr title="Application Programming Interfaces">APIs</abbr>, in the same way desktop applications map UI components. The information provided to the accessibility API is used to support
assistive technologies, with the expectation that the information passed from the DOM matches the semantic intent of the author. The author may communicate this semantic intent by using
native features of the document language or by using WAI-ARIA, if native features are not available.
</p>
<p>
Authors use <abbr title="Scalable Vector Graphics">SVG</abbr> to create a broad range of applications and drawings. The information needed to support accessibility APIs in
<abbr title="Scalable Vector Graphics">SVG</abbr> comes from a combination of semantics from the elements themselves but also the additional semantics provided by
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> and the modular extensions to <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> supported by this
specification.
</p>
<p>
A screen reader or other assistive technology uses the semantic information exposed via the accessibility <abbr title="Application Programming Interface">API</abbr>
to provide an alternative rendering of an application that is meaningful to a user.
</p>
<p>
Accessibility <abbr title="Application Programming Interfaces">APIs</abbr>
supported by this document (and the other specifications it extends) are:
</p>
<ul>
<li>
<cite><a href="https://msdn.microsoft.com/en-us/library/ms697707.aspx">Microsoft Active Accessibility 2.0</a></cite> [[MSAA]] with
<cite><a href="https://wiki.linuxfoundation.org/accessibility/iaccessible2/start">IAccessible2 1.3</a></cite> [[IAccessible2]]
</li>
<li>
<cite><a href="https://msdn.microsoft.com/en-us/library/ee684013%28VS.85%29.aspx">User Interface Automation</a></cite> [[UI-AUTOMATION]]
</li>
<li>
<cite><a href="https://developer.gnome.org/atk/2.10/">Linux Accessibility Toolkit 2.10.0</a></cite> [[ATK]] and
<cite><a href="https://developer.gnome.org/libatspi/2.10/">Assistive Technology - Service Provider Interface 2.1</a></cite> [[AT-SPI]]
</li>
<li>
<cite><a href="https://developer.apple.com/documentation/appkit/accessibility/nsaccessibility">Mac OS X Accessibility Protocol Mac OS 10.10</a></cite> [[AXAPI]]
</li>
</ul>
<p>
If user agent developers need to expose information using other accessibility <abbr title="Application Programming Interfaces">APIs</abbr>, it is recommended that they work closely with the
developer of the platform where the <abbr title="application programming interface">API</abbr> runs, and assistive technology developers on that platform.
</p>
</section>
<section id="intro_treetypes">
<h3>The Accessibility Tree and the <abbr title="Document Object Model">DOM</abbr> Tree</h3>
<p>
The <a class="termref" data-lt="Accessibility Tree">accessibility tree</a> and the <abbr title="Document Object Model">DOM</abbr> tree are parallel structures. Roughly speaking, the
accessibility tree is a subset of the flattened <abbr title="Document Object Model">DOM</abbr> tree, which is then augmented to include the user interface
<a class="termref" data-lt="object">objects</a> of the <a class="termref" data-lt="user agent">user agent</a>
as well as the objects of the document.
</p>
<p>
<a class="termref" data-lt="accessible object">Accessible objects</a> are created in the accessibility tree for every <abbr title="Document Object Model">DOM</abbr>
<a class="termref" data-lt="element">element</a>
that should be exposed to an
<a class="termref" data-lt="assistive technology">assistive technology</a>. An element could be exposed because it may fire an accessibility <a class="termref" data-lt="event">event</a> or
because it has a <a class="termref" data-lt="property">property</a>, relationship or feature which needs to be exposed.
</p>
<p>
Generally, if a DOM element can be omitted from the accessibility tree without affecting meaning, it will be, for reasons of performance and simplicity. For example, a
<code><span></code> with just a style change and no <a class="termref" data-lt="semantics">semantics</a>
may not get its own accessible object, but the style change will be exposed by other means.
</p>
</section>
</section>
<section id="normative">
<h2>Normative User Agent Implementation Requirements for <abbr title="Scalable Vector Graphics">SVG</abbr></h2>
<p>
This specification marks certain sections as non-normative, also called <a class="termref" data-lt="informative">informative</a>. The classification applies to the entire section. All other
sections provide <a class="termref" data-lt="normative">normative</a> requirements. A statement "This section is non-normative" applies to all its sub-sections, unless otherwise indicated. In
addition, all text boxes labelled "Note" are informative.
</p>
<p>
Normative sections provide requirements that
<a class="termref" data-lt="user agent">user agents</a> must follow for an implementation to conform to this specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in
<cite><a href="http://www.rfc-editor.org/rfc/rfc2119.txt">Keywords for use in RFCs to indicate requirement levels</a></cite> [[rfc2119]]. RFC-2119 keywords are formatted in uppercase and
contained in an element with <code>class="rfc2119"</code>. When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense,
and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.
</p>
<p>
Informative sections and notes provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such
recommendations in order to conform to this specification.
</p>
</section>
<section id="glossary">
<h2>Important Terms</h2>
<div data-include="../common/terms.html" data-oninclude="restrictReferences" data-include-replace="true">Placeholder for glossary</div>
</section>
<section class="section" id="keyboard-focus">
<h2>Supporting Keyboard Navigation</h2>
<p>
Enabling keyboard navigation in web applications is a necessary step toward making accessible web applications possible. Not only is the keyboard the primary input device for many users, but
other accessibile input devices use keyboard events to communicate with the user agent.
</p>
<p>
The Scalable Vector Graphics (SVG) 1 [[SVG1]] and 1.1 [[SVG11]] specifications included only very limited keyboard support (access keys for animations). Many user agents implemented tabbed
focus for links, but there was no declarative or scripted means for authors to control this behavior. Scalable Vector Graphics (SVG) 2 [[SVG2]] introduces keyboard navigation and focus control
based on the HTML <code>tabindex</code> model.
</p>
<p>
Conforming user agents <span class="rfc2119">MUST</span> conform to
<a class="core-mapping" href="#keyboard-focus">Supporting Keyboard Navigation</a>
requirements in the Core Accessibility API Mappings [[!CORE-AAM]].
</p>
<p class="note">The SVG Accessibility Task Force intends to develop more detailed guidelines for authors and user agents regarding navigation in graphical documents.</p>
</section>
<section id="mapping">
<h2>Mapping <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> to Accessibility <abbr title="Application Programming Interfaces">APIs</abbr></h2>
<p>
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> support was formally introduced to SVG in Scalable Vector Graphics (SVG) 2 [[SVG2]], which allows ARIA attributes to be used
in the default namespace. This section defines how WAI-ARIA semantics are exposed to assistive technologies through platform Accessibility
<abbr title="Application Programming Interfaces">APIs</abbr> and how SVG elements are mapped to Accessibility <abbr title="Application Programming Interfaces">APIs</abbr> based on WAI-ARIA.
</p>
<section id="mapping_general">
<h3>General rules for exposing <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> semantics</h3>
<p>
SVG user agents <strong class="rfc2119">MUST</strong> conform to <a class="core-mapping" href="#mapping_general">General rules for exposing WAI-ARIA semantics</a> in the Core Accessibility
API Mappings [[!CORE-AAM]], with the additions described in the following sub-sections.
</p>
<section id="exclude_elements">
<h4>Excluding Elements from the Accessibility Tree</h4>
<p>
Certain elements in the <abbr title="Document Object Model">DOM</abbr> are not exposed via the
<a class="termref" href="#dfn-accessibility-api">accessibility <abbr title="Application Programming Interface">API</abbr></a
>. The section <a class="core-mapping" href="#exclude_elements2">Excluding Elements from the Accessibility Tree</a>
of the Core Accessibility API Mappings [[CORE-AAM]] outlines the general rules for excluding elements. One factor is whether host language semantics specify that the element should not be
displayed.
</p>
<p>
The SVG language defines numerous elements that fit this criteria. Many SVG elements are never directly rendered to the screen, while others may or may not be rendered or displayed,
depending on context or CSS styling. Elements which are neither perceivable nor interactive should not be included in the accessibility tree exposed to accessibility
<abbr title="Application Programming Interfaces">APIs</abbr>. This section details the expected interpretation of SVG host language semantics.
</p>
<div class="note">
<p>The other factors for excluding elements, as described in the Core Accessibility API Mappings, can be summarized as follows:</p>
<ul>
<li>
If the first mappable role provided by the author is <a class="role-reference" href="#none"><code>none</code></a> or
<a class="role-reference" href="#presentation"><code>presentation</code></a
>, the element must not be exposed.
</li>
<li>
If the element or an ancestor has an <a class="property-reference" href="#aria-hidden"><code>aria-hidden</code></a> value of <code>true</code>, it should not be exposed.
</li>
<li>
If an ancestor of the element has a used role which has the characteristic "<a class="specref" href="#childrenArePresentational">Children Presentational: True</a>" in the
WAI-ARIA specifications [[WAI-ARIA]], the child element should not be exposed. For example, the roles <a class="role-reference" href="#button"><code>button</code></a> and
<a class="role-reference" href="#img"><code>img</code></a>
exclude all child content from being directly included in the accessibility tree.
</li>
</ul>
<p>
However, note that a number of features of an element, such as interactivity, can cause
<a class="specref" href="#conflict_resolution_presentation_none">an author-supplied or inherited role of <code>none</code> or <code>presentation</code> to be ignored as an error.</a>
An element will not be excluded if it can currently receive focus based on user interaction.
</p>
<p>Consult the <a class="core-mapping" href="#exclude_elements2">original document</a> ([[CORE-AAM]]) for the normative text.</p>
</div>
<p>
Elements which are never directly rendered to screen, nor represented by an interactive region in a graphic, do not need a corresponding accessible object. User agents
<strong class="rfc2119">MUST NOT</strong> include any elements, or their descendant content, as an <a class="termref" data-lt="accessible object">accessible object</a> in the
<a class="termref" data-lt="accessibility tree">accessibility tree</a> that are indicated as <code>no accessible object created</code> in the
<a href="#mapping_role_table">SVG Element Mapping Tables</a>. User agents <strong class="rfc2119">SHOULD</strong> also exclude any other element defined by past or future SVG
specifications or modules that specifically indicate the element is <a href="https://www.w3.org/TR/SVG2/render.html#TermNeverRenderedElement">never directly rendered</a>.
</p>
<p>
For example, elements that represent filters, gradients, or gradient stops will never create an accessible object. Shape elements or image elements that are included in an SVG definitions
section or as part of a pattern will also not have accessible objects, because the semantics of the ancestor
<code>defs</code> or <code>pattern</code> element preclude that entire DOM subtree from being represented in the accessibility tree.
</p>
<p>
Elements that are excluded from the <a class="termref" data-lt="accessibility tree">accessibility tree</a> might still be used in the name and description computation of another element,
as defined in the <a href="#mapping_additional_nd">Name and Description</a> section. Non-rendered elements may also be used as the templates for rendered element instances created by a
<code>use</code> element, as described in the section on <a href="#mapping_use_shadow_tree">Use-Element Shadow Trees</a>.
</p>
<p class="note">
Although they are not directly included in the accessibility tree, animation and view elements can affect the accessible objects representing their target elements, as described under
<a href="#mapping_additional">Special Processing Requiring Additional Computation</a>.
</p>
<p>
In addition, SVG 1.1 [[SVG11]] defines the conditional processing attributes
<code>systemLanguage</code>, <code>requiredExtensions</code>, and <code>requiredFeatures</code>. These may be used individually or in combination with the <code>switch</code> element to
prevent content from being rendered under certain conditions, or to select between alternate versions of content.
</p>
<p>
SVG user agents <strong class="rfc2119">MUST NOT</strong> expose to accessibility APIs any elements that are not rendered because of conditional processing attributes on that element or
because of the position of that element within a switch construct. The <code>switch</code> element itself <strong class="rfc2119">SHOULD</strong> be omitted as if it had a role of
<code>none</code> or <code>presentation</code>.
</p>
<p>
The rendering of SVG elements is also affected by CSS styling properties, which may be specified using stylesheet rules, inline styles, presentation attributes, or animations. Regardless
of how the style property is specified, the effect depends on the final computed value determined by the CSS cascade [[CSS-CASCADE-3]]. User agents
<strong class="rfc2119">MUST NOT</strong> expose to accessibility APIs any element that is not rendered because its computed style includes a value of <code>none</code> for the
<a href="https://svgwg.org/svg2-draft/render.html#VisibilityControl"><code>display</code></a> property.
</p>
<p>
Other style properties can prevent an element, which is otherwise part of the rendering tree, from creating any visible representation in the rendered graphic. Such elements may still be
interactive; they may receive keyboard focus or they may be associated with a region of the graphic that is responsive to pointer input events.
</p>
<p>
For the purpose of SVG, an element is considered <a class="termref">hidden</a> if it is <em>neither</em> visible, according to the computed value of the
<a href="https://svgwg.org/svg2-draft/render.html#VisibilityControl"><code>visibility</code></a> property, nor interactive to pointer users. according to the
<a href="https://svgwg.org/svg2-draft/interact.html#PointerEventsProperty"><code>pointer-events</code></a> property. User agents <strong class="rfc2119">SHOULD NOT</strong>
expose to accessibility APIs any element that is hidden in this sense,
<em>unless</em> the author explicitly overrides the hiding by setting the <a class="property-reference" href="#aria-hidden"><code>aria-hidden</code></a> attribute to <code>false</code>.
</p>
<p>
In the case of container elements (such as <code>g</code> or <code>svg</code>), the element is not considered hidden if <em>any</em> of its descendent content is visible <em>or</em> can
receive user events, regardless of the computed value of <code>visibility</code> on the element itself. Similarly, a <code>use</code> element may include visible or interactive component
graphics, despite having style properties that would cause an individual shape element to be hidden. The <code>use</code> element MUST be considered visible or interactive if any elements
within its shadow tree are visible or interactive. (The container or the <code>use</code> element may, however, still be considered presentational if it does not have any other reason to
include it in the accessibility tree.) A shape element with markers is visible or interactive if any of its markers are visible or interactive.
</p>
<div class="note">
<p>
In HTML and in other CSS-styled documents, elements made invisible with <code>visibility: hidden</code> are always hidden elements for accessibility purposes, equivalent to un-rendered
elements (such as those with <code>display: none</code>).
</p>
<p>For SVG, this is not always appropriate, because of the interaction with the <code>pointer-events</code> property.</p>
<p>
In many cases, the invisible elements are of semantic importance (because they are interactive) while visible elements are presentational only. For example, large invisible elements are
often used to provide easy-to-hit targets for points in a map or datachart. Because these elements react to pointer events, they are effectively perceivable to pointer users, and should
be perceivable and interactive to users of assistive technologies as well.
</p>
<p>
An SVG element with a computed value of <code>visibility: hidden</code>
can be interactive to pointer users for the following values of the
<a href="https://svgwg.org/svg2-draft/interact.html#PointerEventsProperty"><code>pointer-events</code></a> property:
</p>
<ul>
<li>
<code>painted</code>, for any rendered element <em>except</em> shape or a text where both the <code>fill</code> and <code>stroke</code> properties have a computed value of
<code>none</code>
</li>
<li><code>fill</code></li>
<li><code>stroke</code></li>
<li><code>all</code></li>
<li><code>bounding-box</code></li>
</ul>
</div>
<p>
An element that is currently positioned off-screen, or that is obscured by other elements, is not considered hidden. User agents should expose this state through other means, as described
in the <a class="core-mapping" href="#statePropertyMappingGeneralRules">State and Property Mapping</a>
section of the Core Accessibility API Mappings [[CORE-AAM]].
</p>
<div class="note">
<p>
Various other style properties and geometric attributes (of an element itself or an ancestor element) can make an element invisible. For simplicity, flexibility, and performance reasons,
these are not considered a hiding method that excludes elements from the accessibility tree.
</p>
<p>
When using properties other than <code>display</code> or <code>visibility</code> to hide inactive content, authors can use the
<a class="property-reference" href="#aria-hidden"><code>aria-hidden</code></a> attribute to indicate that assistive technologies should ignore the element and its descendents.
</p>
</div>
<div class="ednote">
<p>
Previous drafts of this specification also considered the
<code>fill</code> and <code>stroke</code> properties, when both set to a value of <code>none</code>, as a valid way to hide an element. This has been removed as it introduced excessive
complexity. Some SVG elements (e.g., embedded images) are not affected by stroke and fill; even those that are can be visible without it, because of markers or filter effects.
Furthermore, it could result in identical-looking graphics (for example: one that used <code>fill: transparent</code> instead of <code>fill: none</code>) having markedly different
accessibility trees.
</p>
<p>
Note, however, that the <code>fill</code> and <code>stroke</code> properties may still have an indirect effect on the inclusion of an element, depending on the value of the
<code>pointer-events</code> property.
</p>
</div>
<div class="issue" title="Should structured descriptions be exposed in the accessibility tree?" data-number="6">
<p>
The strict exclusion of non-rendered metadata elements, including <code>desc</code>, from the accessibility tree means that their content will only be available as plain text, not as
structured alternative representations that a user can navigate in browsing mode.
</p>
<p>
This contradicts the original intent of the SVG specifications, which allows these elements to include structured content, including HTML-namespaced content. The SVG 1 specifications had
suggested that this could be alternatively presented as CSS-formated XML text, but this is not supported by the user agent/assistive technology combinations currently in use.
</p>
<p>
The editors welcome feedback and suggestions (in <a href="https://github.com/w3c/svg-aam/issues/6">GitHub Issue #6</a>) on alternative ways to represent this hidden alternative content
in a way consistent with user agent and accessibility API implementations.
</p>
</div>
</section>
<section id="include_elements">
<h4>Including Elements in the Accessibility Tree</h4>
<p>
Many SVG elements—although rendered to the screen—do not have an intrinsic semantic meaning. Instead, they represent components of the visual presentation of the document. To
simplify the accessible representation of the document, these purely presentational elements should normally be omitted from the accessibility tree, unless the author explicitly provides
semantic content.
</p>
<p>
However, any rendered SVG element may have semantic meaning. Authors indicate the significance of the element by including alternative text content or
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> attributes. This section defines the rules for including normally-omitted elements in the accessibility tree.
</p>
<p>
The following graphical and container elements in the SVG namespace
<strong class="rfc2119">SHOULD NOT</strong> be included in the accessibility tree, <em>except</em> as described in this section:
</p>
<ul>
<li>
shape elements (<code>circle</code>,
<code>ellipse</code>, <code>line</code>, <code>path</code>, <code>polygon</code>, <code>polyline</code>, <code>rect</code>)
</li>
<li>the <code>use</code> element</li>
<li>the grouping (<code>g</code>) element</li>
<li>the <code>image</code> element</li>
<li>the <code>mesh</code> element</li>
<li>
text formatting elements (<code>textPath</code>,
<code>tspan</code>)
</li>
<li>the <code>foreignObject</code> element</li>
<!--
<li>
the <code>canvas</code> element
</li>
<li>
the <code>iframe</code> element
</li>
-->
</ul>
<p>
Although these elements are omitted from the accessibility tree, their child content
<!-- (or the embedded document, for an <code>iframe</code>) -->
is still processed, as if it was a direct child of the nearest ancestor node in the DOM tree that is included in the accessibility tree. In other words, the markup elements are treated as
if they had a role of <code>none</code> or <code>presentation</code>.
</p>
<p>
For <code>use</code> elements, the elements and text in their associated shadow tree MUST be processed as if it was child content of the <code>use</code> element, following the conditions
specified in <a href="#mapping_use_shadow_tree">processing requiring additional computation</a>. This means that elements from the shadow tree can be included in the accessibility tree
even if the <code>use</code> element itself has a (default or author-supplied) role of <code>presentation</code>.
</p>
<p>
SVG user agents <strong class="rfc2119">MUST</strong> provide an accessible object in the accessibility tree for rendered SVG elements that meet any of the following criteria,
<em>unless</em> they are excluded from the accessibility tree per the rules in <a href="#exclude_elements">Excluding Elements from the Accessibility Tree</a>:
</p>
<ul>
<li>
It has at least one direct child
<span class="element-name"
>‘<a href="http://www.w3.org/TR/SVG2/struct.html#TitleElement"><span>title</span></a
>’</span
>
element or
<span class="element-name"
>‘<a href="http://www.w3.org/TR/SVG2/struct.html#DescElement"><span>desc</span></a
>'</span
>
element that is not empty after trimming whitespace. User agents MAY include elements with these child elements without checking for valid text content.
</li>
<li>
It has a non-empty (after trimming whitespace)
<span class="attr-name"
>‘<a class="property-reference" href="#aria-label"><span>aria-label</span></a
>’</span
>
attribute or
<span class="attr-name"
>‘<a class="property-reference" href="#aria-roledescription"><span>aria-roledescription</span></a
>’</span
>
attribute.
</li>
<li>
It has an
<span class="attr-name"
>‘<a class="property-reference" href="#aria-labelledby"><span>aria-labelledby</span></a
>’</span
>
attribute or
<span class="attr-name"
>‘<a class="property-reference" href="#aria-describedby"><span>aria-describedby</span></a
>’</span
>
attribute containing valid IDREF tokens. User agents MAY include elements with these attributes without checking for validity.
</li>
<li>
It has a valid integer
<span class="attribute-name"
>'<a href="http://www.w3.org/TR/SVG2/struct.html#SVGElementTabindexAttribute"><span>tabindex</span></a
>'</span
>
attribute.
</li>
<li>
The author has provided an allowed, non-abstract
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> role other than <code title="attr-aria-role-none">none</code> or
<code title="attr-aria-role-presentation">presentation</code>.
</li>
<li>
It meets any of the criteria listed in the section
<a href="#include_elements" class="core-mapping">Including Elements in the Accessibility Tree</a>
of the Core Accessibility API Mappings specification [[!CORE-AAM]].
</li>
</ul>
<div class="note">
<p>
At the time of drafting this document, those criteria are as follows:
<!-- Please confirm whether update is required
when re-publishing! -->
</p>
<ul>
<li>Text elements</li>
<li>Elements that may fire an accessibility <abbr title="Application Program Interface">API</abbr> <a class="termref">event</a></li>
<li>
Elements that are focusable, or have an ID <a class="termref">attribute</a> and an ancestor with the
<a class="property-reference" href="#aria-activedescendant"><code>aria-activedescendant</code></a> attribute that matches the implicit or explicit <a class="termref">semantics</a> of
the required context role. In either case, the element may receive focus and need to fire a<code> FOCUS </code>event.
</li>
<li>Elements that have a mappable role in the role attribute string (see <a class="core-mapping" href="#mapping_role">Role Mapping</a>).</li>
<li>
Elements that have a global <abbr title="Accessible Rich Internet Application">WAI-ARIA attribute </abbr> but do not have
<a class="property-reference" href="#aria-hidden"><code>aria-hidden</code></a
><code>="true"</code>. (See <a class="core-mapping" href="#exclude_elements2">Excluding Elements in the Accessibility Tree</a> for additional guidance on
<code>aria-hidden</code>.)
</li>
<li>
Elements that have an ID which is referenced by another element via a <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> relation (<a
class="property-reference"
href="#aria-controls"
><code>aria-controls</code></a
>, <a class="property-reference" href="#aria-describedby"><code>aria-describedby</code></a
>, <a class="property-reference" href="#aria-flowto"><code>aria-flowto</code></a
>, <a class="property-reference" href="#aria-labelledby"><code>aria-labelledby</code></a> or <a class="property-reference" href="#aria-owns"><code>aria-owns</code></a
>) and are not <a class="termref">hidden</a>.
</li>
</ul>
<p>The latest version of the source document [[CORE-AAM]] should be consulted for the normative text.</p>
<p>
The exception for hidden elements means that SVG metadata elements or other non-rendered content may be used in the accessible name and description of another element without themselves
being included in the accessiblity tree. For example, current best practice for fallback browser support is to use <code>aria-labelledby</code> and <code>aria-describedby</code>
to redundantly link to
<code>title</code> and <code>desc</code> child elements. Including these elements as separate nodes in the tree would unnecessarily complicate the document presented to screen reader
users.
</p>
</div>
<p>
Interactive elements are covered by the requirement regarding elements that may fire an Accessibility API event. Specifically, for SVG the following elements are interactive and MUST be
included in the accessibility tree, without exception, regardless of whether they would otherwise be considered hidden or presentational:
</p>
<ul>
<li>
A <a href="https://svgwg.org/svg2-draft/render.html#TermRenderedElement">rendered</a> element (or instance of an element in a use-element shadow tree) with a positive integer value for
the <code>tabindex</code> attribute, or which is <a href="https://svgwg.org/svg2-draft/interact.html#TermFocusable">focusable</a> by default and has not been removed from the tab order
with a negative integer <code>tabindex</code> attribute, which may receive keyboard focus and therefore keyboard input events.
</li>
<li>
A <a href="https://svgwg.org/svg2-draft/render.html#TermRenderedElement">rendered</a> element (or instance of an element) that currently has keyboard
<a href="https://svgwg.org/svg2-draft/interact.html#Focus">focus</a>
(e.g., after being focused from a script), which may receive keyboard input events.
</li>
</ul>
<p>
With regards to pointer events, which bubble up the DOM tree, the exact element that receives the event may not have semantic meaning (that is, it may still be presentational). However,
the ability to receive pointer events overrides any exclusion based on the <code>visibility: hidden</code> style property.
</p>
<p class="note">
The <code>tabindex</code> attribute and the <code>pointer-events</code> property have no impact on elements which are not rendered at all, because of the
<code>display: none</code> property or because of host language semantics.
</p>
</section>
</section>
<section id="mapping_conflicts">
<h3>Conflicts between native markup semantics and <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr></h3>
<p>
<abbr title="Scalable Vector Graphics">SVG</abbr> user agents <span class="rfc2119">MUST</span> conform to
<a class="core-mapping" href="#mapping_conflicts">Conflicts between native markup semantics and WAI-ARIA</a> in the Core Accessibility API Mappings [[!CORE-AAM]] where the host language is
SVG and the native semantics are as described in the <a href="#mapping_role_table">SVG Element Mapping Tables</a>, the
<a href="#mapping_state-property">State and Property Mapping</a> section, and the <a href="#mapping_additional">Special Processing Requiring Additional Computation</a> section.
</p>
<p>
Elements for which no accessible object is created and no role may be applied, as defined in the <a href="#mapping_role_table">SVG Element Mapping Tables</a>, have no implicit role
<a>semantics</a>. The
<span class="attr-name"
>‘<a class="property-reference" href="#aria-roledescription"><span>aria-roledescription</span></a
>’</span
>
attribute MUST NOT be exposed on these elements. All other SVG elements have implicit role semantics when used with global WAI-ARIA attributes, including
<span class="attr-name"
>‘<a class="property-reference" href="#aria-roledescription"><span>aria-roledescription</span></a
>’</span
>.
</p>
</section>
<section id="mapping_nodirect">
<h3>Exposing attributes that do not directly map to accessibility <abbr title="application programming interface">API</abbr> properties</h3>
<p>
SVG user agents <span class="rfc2119">MUST</span> conform to
<a class="core-mapping" href="#mapping_nodirect">Exposing attributes that do not directly map to accessibility <abbr title="application programming interface">API</abbr> properties</a> in
the Core Accessibility API Mappings [[!CORE-AAM]].
</p>
</section>
</section>
<section id="mapping_role">
<h2>Role mapping</h2>
<p>
Platform <a class="termref" href="#dfn-accessibility-api">accessibility <abbr title="Application Programming Interfaces">APIs</abbr></a> traditionally have had a finite set of predefined
<a href="#dfn-role" class="termref">roles</a> that are expected by <a class="termref" href="#dfn-assistive-technologies">assistive technologies</a>
on that platform and only one or two roles may be exposed.
</p>
<p>
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr>
only supports one active role at a time. However, multiple roles may be specified as an ordered set of space-separated valid role tokens. The additional roles are fallback roles, similar to
the concept of specifying multiple font families in case the first choice font is not supported. This allows the role taxonomy to be extended in future for specialized applications. The entire
role string is exposed to accessibility technologies where possible, so they can respond appropriately even if there is no equivalent role in the platform
<abbr title="Application Programming Interfaces">API</abbr>.
</p>
<section id="roleMappingGeneralRules">
<h3>General Rules</h3>
<p>
SVG user agents <span class="rfc2119">MUST</span> conform to the Role Mapping <a class="core-mapping" href="#mapping_general">General Rules</a> accessibility API computational requirements
in the Core Accessibility API Mappings [[!CORE-AAM]].
</p>
</section>
<section id="mapping_role_table">
<h3>SVG Element Mapping Tables</h3>
<p>
This section defines how elements in SVG2 map to WAI-ARIA roles and platform accessibility APIs based on their native host language semantics, including which WAI-ARIA roles may be applied.
This section refers directly to both the
<a class="core-mapping" href="#mapping_role_table"><code>Role Mappings</code></a>
in the Core Accessibility API Mappings [[!CORE-AAM]] specification and the <a class="graphics-mapping" href="#mapping_role_table"><code>Role Mappings</code></a> in the Graphics Accessibility
API Mappings [[!GRAPHICS-AAM]] specification, which define how WAI-ARIA roles are mapped to platform accessibility APIs.
</p>
<h4 id="role-map-a"><code>a</code></h4>
<table aria-labelledby="role-map-a">
<tbody>
<tr>
<th>SVG Specification</th>
<td>
<a class="element-reference" href="http://www.w3.org/TR/SVG2/linking.html#AElement"><code>a</code></a>
</td>
</tr>
<tr>
<th>
Default Platform
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings
</th>
<td>
<a class="core-mapping" href="#role-map-link"><code>link</code></a> role if the element has a valid <code>href</code> or <code>xlink:href</code> attribute. For <code>a</code> elements
that are not links, use the mapping for <code>tspan</code> if the <code>a</code> element is a descendent of <code>text</code>, or the mapping for <code>g</code> otherwise.
</td>
</tr>
<tr>
<th>Allowed <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Roles and Platform <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings</th>
<td>
any role; see the <a class="core-mapping" href="#mapping_role_table"><code>Core Accessibility API Role Mappings</code></a> and the
<a class="graphics-mapping" href="#mapping_role_table"><code>Graphics Accessibility API Role Mappings</code></a>
</td>
</tr>
</tbody>
</table>
<h4 id="role-map-animate"><code>animate</code></h4>
<table aria-labelledby="role-map-animate">
<tbody>
<tr>
<th>SVG Specification</th>
<td>
<a class="element-reference" href="https://svgwg.org/specs/animations/#AnimateElement"><code>animate</code></a>
</td>
</tr>
<tr>
<th>
Default Platform
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings
</th>
<td>no <a class="termref" data-lt="accessible object">accessible object</a> created</td>
</tr>
<tr>
<th>Allowed <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Roles and Platform <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings</th>
<td>no role may be applied</td>
</tr>
</tbody>
</table>
<h4 id="role-map-animatemotion"><code>animateMotion</code></h4>
<table aria-labelledby="role-map-animatemotion">
<tbody>
<tr>
<th>SVG Specification</th>
<td>
<a class="element-reference" href="https://svgwg.org/specs/animations/#AnimateMotionElement"><code>animateMotion</code></a>
</td>
</tr>
<tr>
<th>
Default Platform
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings
</th>
<td>no <a class="termref" data-lt="accessible object">accessible object</a> created</td>
</tr>
<tr>
<th>Allowed <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Roles and Platform <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings</th>
<td>no role may be applied</td>
</tr>
</tbody>
</table>
<h4 id="role-map-animatetransform"><code>animateTransform</code></h4>
<table aria-labelledby="role-map-animatetransform">
<tbody>
<tr>
<th>SVG Specification</th>
<td>
<a class="element-reference" href="https://svgwg.org/specs/animations/#AnimateTransformElement"><code>animateTransform</code></a>
</td>
</tr>
<tr>
<th>
Default Platform
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings
</th>
<td>no <a class="termref" data-lt="accessible object">accessible object</a> created</td>
</tr>
<tr>
<th>Allowed <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Roles and Platform <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings</th>
<td>no role may be applied</td>
</tr>
</tbody>
</table>
<h4 id="role-map-audio"><code>audio</code></h4>
<table aria-labelledby="role-map-audio">
<tbody>
<tr>
<th>SVG Specification</th>
<td>
<a class="element-reference" href="http://www.w3.org/TR/html5/embedded-content-0.html#the-audio-element"><code>audio</code></a>
</td>
</tr>
<tr>
<th>
Default Platform
<abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings
</th>
<td>
Follow the recommendations for <a class="html-mapping" href="#el-audio">the HTML audio element</a>
in the HTML Accessibility API Mappings specification [[!HTML-AAM]].
</td>
</tr>
<tr>
<th>Allowed <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Roles and Platform <abbr title="Accessible Rich Internet Application">WAI-ARIA</abbr> Role Mappings</th>
<td>
<a class="core-mapping" href="#role-map-application"><code title="attr-aria-role-application">application</code></a> role