forked from w3c/wcag-act
-
Notifications
You must be signed in to change notification settings - Fork 0
/
act-rules-format.html
1431 lines (1397 loc) · 111 KB
/
act-rules-format.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 lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<title>Accessibility Conformance Testing (ACT) Rules Format 1.0</title>
<meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
<meta content="w3c/ED" name="w3c-status">
<link href="https://www.w3.org/StyleSheets/TR/2016/W3C-ED" rel="stylesheet" type="text/css">
<meta content="Bikeshed version 39652c9ea7fd5d09639da5e1182cd481b0c5ae70" name="generator">
<link href="https://w3c.github.io/wcag-act/act-rules-format.html" rel="canonical">
<style>
.rfc2119 {
text-transform: uppercase;
}
pre.highlight {
background: white !important;
border: solid 1px #ded390;
border-radius: 2px;
}
pre.highlight c-[s],
pre.highlight c-[u] {
color: #79532e;
}
pre.highlight c-[f] {
color: #578201;
}
pre.highlight c-[p] {
color: #757575;
}
</style>
<style>/* style-md-lists */
/* This is a weird hack for me not yet following the commonmark spec
regarding paragraph and lists. */
[data-md] > :first-child {
margin-top: 0;
}
[data-md] > :last-child {
margin-bottom: 0;
}</style>
<style>/* style-selflinks */
.heading, .issue, .note, .example, li, dt {
position: relative;
}
a.self-link {
position: absolute;
top: 0;
left: calc(-1 * (3.5rem - 26px));
width: calc(3.5rem - 26px);
height: 2em;
text-align: center;
border: none;
transition: opacity .2s;
opacity: .5;
}
a.self-link:hover {
opacity: 1;
}
.heading > a.self-link {
font-size: 83%;
}
li > a.self-link {
left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
top: auto;
left: auto;
opacity: 0;
width: 1.5em;
height: 1.5em;
background: gray;
color: white;
font-style: normal;
transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
opacity: 1;
}
dfn > a.self-link:hover {
color: black;
}
a.self-link::before { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before { content: "#"; }</style>
<style>/* style-counters */
body {
counter-reset: example figure issue;
}
.issue {
counter-increment: issue;
}
.issue:not(.no-marker)::before {
content: "Issue " counter(issue);
}
.example {
counter-increment: example;
}
.example:not(.no-marker)::before {
content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
content: "Invalid Example" counter(example);
}
figcaption {
counter-increment: figure;
}
figcaption:not(.no-marker)::before {
content: "Figure " counter(figure) " ";
}</style>
<style>/* style-autolinks */
.css.css, .property.property, .descriptor.descriptor {
color: #005a9c;
font-size: inherit;
font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
content: "‘";
}
.css::after, .property::after, .descriptor::after {
content: "’";
}
.property, .descriptor {
/* Don't wrap property and descriptor names */
white-space: nowrap;
}
.type { /* CSS value <type> */
font-style: italic;
}
pre .property::before, pre .property::after {
content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
content: "’";
}
[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
content: "";
}
[data-link-type=element],
[data-link-type=element-attr] {
font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after { content: ">" }
[data-link-type=biblio] {
white-space: pre;
}</style>
<style>/* style-dfn-panel */
.dfn-panel {
position: absolute;
z-index: 35;
height: auto;
width: -webkit-fit-content;
width: fit-content;
max-width: 300px;
max-height: 500px;
overflow: auto;
padding: 0.5em 0.75em;
font: small Helvetica Neue, sans-serif, Droid Sans Fallback;
background: #DDDDDD;
color: black;
border: outset 0.2em;
}
.dfn-panel:not(.on) { display: none; }
.dfn-panel * { margin: 0; padding: 0; text-indent: 0; }
.dfn-panel > b { display: block; }
.dfn-panel a { color: black; }
.dfn-panel a:not(:hover) { text-decoration: none !important; border-bottom: none !important; }
.dfn-panel > b + b { margin-top: 0.25em; }
.dfn-panel ul { padding: 0; }
.dfn-panel li { list-style: inside; }
.dfn-panel.activated {
display: inline-block;
position: fixed;
left: .5em;
bottom: 2em;
margin: 0 auto;
max-width: calc(100vw - 1.5em - .4em - .5em);
max-height: 30vh;
}
.dfn-paneled { cursor: pointer; }
</style>
<style>/* style-syntax-highlighting */
.highlight:not(.idl) { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
c-[a] { color: #990055 } /* Keyword.Declaration */
c-[b] { color: #990055 } /* Keyword.Type */
c-[c] { color: #708090 } /* Comment */
c-[d] { color: #708090 } /* Comment.Multiline */
c-[e] { color: #0077aa } /* Name.Attribute */
c-[f] { color: #669900 } /* Name.Tag */
c-[g] { color: #222222 } /* Name.Variable */
c-[k] { color: #990055 } /* Keyword */
c-[l] { color: #000000 } /* Literal */
c-[m] { color: #000000 } /* Literal.Number */
c-[n] { color: #0077aa } /* Name */
c-[o] { color: #999999 } /* Operator */
c-[p] { color: #999999 } /* Punctuation */
c-[s] { color: #a67f59 } /* Literal.String */
c-[t] { color: #a67f59 } /* Literal.String.Single */
c-[u] { color: #a67f59 } /* Literal.String.Double */
c-[cp] { color: #708090 } /* Comment.Preproc */
c-[c1] { color: #708090 } /* Comment.Single */
c-[cs] { color: #708090 } /* Comment.Special */
c-[kc] { color: #990055 } /* Keyword.Constant */
c-[kn] { color: #990055 } /* Keyword.Namespace */
c-[kp] { color: #990055 } /* Keyword.Pseudo */
c-[kr] { color: #990055 } /* Keyword.Reserved */
c-[ld] { color: #000000 } /* Literal.Date */
c-[nc] { color: #0077aa } /* Name.Class */
c-[no] { color: #0077aa } /* Name.Constant */
c-[nd] { color: #0077aa } /* Name.Decorator */
c-[ni] { color: #0077aa } /* Name.Entity */
c-[ne] { color: #0077aa } /* Name.Exception */
c-[nf] { color: #0077aa } /* Name.Function */
c-[nl] { color: #0077aa } /* Name.Label */
c-[nn] { color: #0077aa } /* Name.Namespace */
c-[py] { color: #0077aa } /* Name.Property */
c-[ow] { color: #999999 } /* Operator.Word */
c-[mb] { color: #000000 } /* Literal.Number.Bin */
c-[mf] { color: #000000 } /* Literal.Number.Float */
c-[mh] { color: #000000 } /* Literal.Number.Hex */
c-[mi] { color: #000000 } /* Literal.Number.Integer */
c-[mo] { color: #000000 } /* Literal.Number.Oct */
c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
c-[sc] { color: #a67f59 } /* Literal.String.Char */
c-[sd] { color: #a67f59 } /* Literal.String.Doc */
c-[se] { color: #a67f59 } /* Literal.String.Escape */
c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
c-[si] { color: #a67f59 } /* Literal.String.Interpol */
c-[sx] { color: #a67f59 } /* Literal.String.Other */
c-[sr] { color: #a67f59 } /* Literal.String.Regex */
c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
c-[vc] { color: #0077aa } /* Name.Variable.Class */
c-[vg] { color: #0077aa } /* Name.Variable.Global */
c-[vi] { color: #0077aa } /* Name.Variable.Instance */
c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
</style>
<body class="h-entry">
<div class="head">
<header>
<p data-fill-with="logo"><a href="https://www.w3.org/"><img alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2016/logos/W3C" width="72"></a> </p>
<h1 class="p-name no-ref" id="title">Accessibility Conformance Testing (ACT) Rules Format 1.0</h1>
<h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2019-07-22">22 July 2019</time></span></h2>
</header>
<div data-fill-with="spec-metadata">
<dl>
<dt>This version:
<dd><a class="u-url" href="https://w3c.github.io/wcag-act/act-rules-format.html">https://w3c.github.io/wcag-act/act-rules-format.html</a>
<dt>Previous Versions:
<dd><a href="https://w3c.github.io/wcag-act/archive_act-format/2019-07-12.html" rel="prev">https://w3c.github.io/wcag-act/archive_act-format/2019-07-12.html</a>
<dt class="editor">Editors:
<dd class="editor p-author h-card vcard"><span class="p-name fn">Wilco Fiers</span> (<span class="p-org org">Deque Systems</span>)
<dd class="editor p-author h-card vcard"><span class="p-name fn">Maureen Kraft</span> (<span class="p-org org">IBM Corp.</span>)
<dd class="editor p-author h-card vcard"><span class="p-name fn">Mary Jo Mueller</span> (<span class="p-org org">IBM Corp.</span>)
<dd class="editor p-author h-card vcard"><span class="p-name fn">Shadi Abou-Zahra</span> (<span class="p-org org">W3C</span>)
</dl>
</div>
<div data-fill-with="warning"></div>
<p class="copyright" data-fill-with="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2019 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="https://ev.buaa.edu.cn/">Beihang</a>). 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 for header">
</div>
<div class="p-summary" data-fill-with="abstract">
<h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
<p>The Accessibility Conformance Testing (ACT) Rules Format 1.0 defines a format for writing accessibility test rules. These test rules can be used for developing automated testing tools and manual testing methodologies. It provides a common format that allows any party involved in accessibility testing to document and share their testing procedures in a robust and understandable manner. This enables transparency and harmonization of testing methods, including methods implemented by accessibility test tools.</p>
</div>
<h2 class="no-num no-toc no-ref heading settled" id="status"><span class="content">Status of this document</span></h2>
<div data-fill-with="status">
<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 <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at https://www.w3.org/TR/.</em></p>
<p>This is an Editor Draft of Accessibility Conformance Testing (ACT) Rules Format 1.0, prepared by the <a href="http://www.w3.org/wai/gl/task-forces/conformance-testing/">Accessibility Conformance Testing (ACT) Task Force</a> of the <a href="https://www.w3.org/WAI/GL/">Accessibility Guidelines Working Group (AGWG)</a>. This document is an Editor Draft and does not represent consensus of the <a href="https://www.w3.org/WAI/GL/">Accessibility Guidelines Working Group</a>. This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation after further review and refinement.</p>
<p>This is an Editor Draft for review and refinement within ACT TF and AGWG. It is not ready for public comments. Before commenting, please first review the <a href="https://github.com/w3c/wcag-act/"><abbr title="World Wide Web Consortium">W3C</abbr> ACT TF GitHub repository</a> for related comments. New comments can be submitted as <a href="https://github.com/w3c/wcag-act/issues/new">new GitHub issues</a> or by email to <a href="mailto:public-wcag-act-comments@w3.org?subject=ACT%20Framework%201.0%20public%20comment">public-wcag-act-comments@w3.org</a> (<a href="https://lists.w3.org/Archives/Public/public-wcag-act-comments/">pulic list archive</a>).</p>
<p>Publication as an Editor Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> 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 class="css" data-link-type="property" href="https://www.w3.org/Consortium/Patent-Policy/" id="sotd_patent"><abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>. <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="https://www.w3.org/2004/01/pp-impl/35422/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="https://www.w3.org/Consortium/Patent-Policy/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Disclosure">section 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.</p>
<p>This document is governed by the <a href="https://www.w3.org/2019/Process-20190301/" id="w3c_process_revision">1 March 2019 W3C Process Document</a>. </p>
<p></p>
</div>
<div data-fill-with="at-risk"></div>
<nav data-fill-with="table-of-contents" id="toc">
<h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
<ol class="toc" role="directory">
<li><a href="#intro"><span class="secno">1</span> <span class="content">Introduction</span></a>
<li><a href="#scope"><span class="secno">2</span> <span class="content">Scope</span></a>
<li><a href="#rule-types"><span class="secno">3</span> <span class="content">ACT Rule Types</span></a>
<li>
<a href="#act-rule-structure"><span class="secno">4</span> <span class="content">ACT Rule Structure</span></a>
<ol class="toc">
<li><a href="#rule-identifier"><span class="secno">4.1</span> <span class="content">Rule Identifier</span></a>
<li><a href="#rule-description"><span class="secno">4.2</span> <span class="content">Rule Description</span></a>
<li><a href="#rule-type"><span class="secno">4.3</span> <span class="content">Rule Type</span></a>
<li>
<a href="#accessibility-requirements-mapping"><span class="secno">4.4</span> <span class="content">Accessibility Requirements Mapping</span></a>
<ol class="toc">
<li><a href="#outcome-mapping"><span class="secno">4.4.1</span> <span class="content">Outcome Mapping</span></a>
<li><a href="#mapping-outside-wcag"><span class="secno">4.4.2</span> <span class="content">Mapping Outside WCAG</span></a>
<li><a href="#rules-without-accessibility-requirements"><span class="secno">4.4.3</span> <span class="content">Rules Without Accessibility Requirements</span></a>
<li><a href="#external-accessibility-requirements-mapping"><span class="secno">4.4.4</span> <span class="content">External Accessibility Requirements Mapping</span></a>
</ol>
<li>
<a href="#input"><span class="secno">4.5</span> <span class="content">Rule Input</span></a>
<ol class="toc">
<li><a href="#input-aspects"><span class="secno">4.5.1</span> <span class="content">Input Aspects (Atomic rules only)</span></a>
<li><a href="#input-rules"><span class="secno">4.5.2</span> <span class="content">Input Rules (Composite rules only)</span></a>
</ol>
<li>
<a href="#applicability"><span class="secno">4.6</span> <span class="content">Applicability</span></a>
<ol class="toc">
<li><a href="#applicability-atomic"><span class="secno">4.6.1</span> <span class="content">Applicability for Atomic Rules</span></a>
<li><a href="#applicability-composite"><span class="secno">4.6.2</span> <span class="content">Applicability for Composite Rules</span></a>
</ol>
<li>
<a href="#expectations"><span class="secno">4.7</span> <span class="content">Expectations</span></a>
<ol class="toc">
<li><a href="#expectations-atomic"><span class="secno">4.7.1</span> <span class="content">Expectations for Atomic Rules</span></a>
<li><a href="#expectations-composite"><span class="secno">4.7.2</span> <span class="content">Expectations for Composite Rules</span></a>
</ol>
<li><a href="#assumptions"><span class="secno">4.8</span> <span class="content">Assumptions</span></a>
<li><a href="#accessibility-support"><span class="secno">4.9</span> <span class="content">Accessibility Support</span></a>
<li><a href="#test-cases"><span class="secno">4.10</span> <span class="content">Test Cases</span></a>
<li><a href="#change-log"><span class="secno">4.11</span> <span class="content">Change Log</span></a>
<li><a href="#glossary"><span class="secno">4.12</span> <span class="content">Glossary</span></a>
<li><a href="#issues-list"><span class="secno">4.13</span> <span class="content">Issues List (optional)</span></a>
<li><a href="#background"><span class="secno">4.14</span> <span class="content">Background (optional)</span></a>
<li><a href="#acknowledgements"><span class="secno">4.15</span> <span class="content">Acknowledgements (optional)</span></a>
</ol>
<li><a href="#rule-accuracy"><span class="secno">5</span> <span class="content">Rule Accuracy</span></a>
<li><a href="#harmonization"><span class="secno">6</span> <span class="content">Harmonization</span></a>
<li><a href="#definitions"><span class="secno">7</span> <span class="content">Definitions</span></a>
<li><a href="#appendix-data-example"><span class="secno"></span> <span class="content">Appendix 1: Expressing ACT Rule results with JSON-LD and EARL</span></a>
<li>
<a href="#Acknowledgments"><span class="secno"></span> <span class="content">Appendix 2: Acknowledgments</span></a>
<ol class="toc">
<li><a href="#participants"><span class="secno"></span> <span class="content">Participants of the AG WG active in the development of this document</span></a>
<li><a href="#enabling-funders"><span class="secno"></span> <span class="content">Enabling funders</span></a>
</ol>
<li><a href="#Change_History"><span class="secno"></span> <span class="content">Appendix 3: Change History</span></a>
<li><a href="#conformance"><span class="secno"></span> <span class="content"> Conformance</span></a>
<li>
<a href="#index"><span class="secno"></span> <span class="content">Index</span></a>
<ol class="toc">
<li><a href="#index-defined-here"><span class="secno"></span> <span class="content">Terms defined by this specification</span></a>
</ol>
<li>
<a href="#references"><span class="secno"></span> <span class="content">References</span></a>
<ol class="toc">
<li><a href="#normative"><span class="secno"></span> <span class="content">Normative References</span></a>
<li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
</ol>
</ol>
</nav>
<main>
<h2 class="heading settled" data-level="1" id="intro"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#intro"></a></h2>
<p>There are currently many test procedures and tools available which aid their users in testing web content for conformance to accessibility standards such as the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag">[WCAG]</a>. As the Web develops in both size and complexity, these procedures and tools are essential for managing the accessibility of resources available on the Web.</p>
<p>This format is intended to enable a consistent interpretation of how to test conformance to WCAG and other <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document">accessibility requirements documents</a> and promote consistent results in accessibility testing. The rules format is designed to describe both manual accessibility tests, as well as automated tests as performed by accessibility testing tools.</p>
<p>Documenting how to test <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement">accessibility requirements</a> will result in accessibility tests that are transparent, with test results that are reproducible. The Accessibility Conformance Testing (ACT) Rules Format defines the requirements for these test descriptions, known as Accessibility Conformance Testing Rules (ACT Rules).</p>
<p>An ACT Rule is a plain language description of how to test a specific type of content for a specific aspect of an accessibility requirement. An ACT Rule describes what kind of content it applies to and which conditions are true about the applicable elements for them to meet all expectations of the rule. In the context of WCAG, ACT Rules test for failures in satisfying Success Criteria. Such failures are often described in <a href="https://www.w3.org/TR/WCAG21/#wcag-2-layers-of-guidance">common failures</a> documented for WCAG. ACT Rules are written for the testing process and are usually more specific than common failures.</p>
<p>The ACT Rules Format defines the requirements and rule structure for the types of information each rule needs to include to be called an ACT Rule. The structure of the ACT rule is defined in the <a href="#act-rule-structure">ACT Rule Structure</a> section. Each ACT Rule also contains a plain language description of the type of content under test, the test to perform, and the expected result. Where the test result affects conformance, the rule documents the particular requirement being tested. The resulting outcomes from the test can be used to help determine conformance or non-conformance to the requirement. Test cases are also written as part of the ACT rule to provide a way to verify that implementations of the rule can successfully determine the expected outcomes.</p>
<h2 class="heading settled" data-level="2" id="scope"><span class="secno">2. </span><span class="content">Scope</span><a class="self-link" href="#scope"></a></h2>
<p>The ACT Rules Format defined in this specification is designed for rules that can be used in testing content created using web technologies, such as <a href="https://www.w3.org/TR/html/">Hypertext Markup Language</a> <a data-link-type="biblio" href="#biblio-html">[HTML]</a>, <a href="https://www.w3.org/TR/CSS/">Cascading Style Sheets</a> <a data-link-type="biblio" href="#biblio-css-2018">[css-2018]</a>, <a href="https://www.w3.org/WAI/standards-guidelines/aria/">Accessible Rich Internet Applications</a> <a data-link-type="biblio" href="#biblio-wai-aria">[WAI-ARIA]</a>, <a href="https://www.w3.org/TR/SVG/">Scalable Vector Graphics</a> <a data-link-type="biblio" href="#biblio-svg2">[SVG2]</a>, <a href="http://www.idpf.org/epub3/latest/">EPUB 3</a>, and more. The ACT Rules Format is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies.</p>
<p>The ACT Rules Format can be used to describe ACT Rules dedicated to testing the <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement①">accessibility requirements</a> defined in the Web Content Accessibility Guidelines <a data-link-type="biblio" href="#biblio-wcag">[WCAG]</a>, which are specifically designed for web content. Other accessibility requirements applicable to web technologies can also be testable with ACT Rules. For example, ACT Rules could be developed to test the conformance of web-based user agents to the <a href="https://www.w3.org/WAI/standards-guidelines/uaag/">User Agent Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-uaag20">[UAAG20]</a>. The ACT Rules Format might not always be suitable to describe tests for other types of accessibility requirements.</p>
<h2 class="heading settled" data-level="3" id="rule-types"><span class="secno">3. </span><span class="content">ACT Rule Types</span><a class="self-link" href="#rule-types"></a></h2>
<p>In accessibility, there are often different technical solutions to make the same type of content accessible. For example, there are multiple methods for giving an <code>img</code> element in HTML an accessible name. Multiple solutions could be tested in a single rule; however, such a rule tends to be quite complex, making it difficult to understand and maintain. The ACT Rules Format solves this by providing two types of rules:</p>
<ul>
<li data-md>
<p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="atomic-rules">Atomic rules</dfn> describe how to test a specific type of solution. It contains a precise definition of what elements, nodes or other "parts" of a <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject">test subject</a> are to be tested, and when those test targets are considered to pass or fail the rule. These rules are to be kept small and <em>atomic</em>. This means that atomic rules test a single "condition" and do so without using the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome">outcomes</a> from other rules.</p>
<li data-md>
<p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="composite-rules">Composite rules</dfn> describe how the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①">outcomes</a> of multiple <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules">atomic rules</a> can be combined into a single outcome for each <a data-link-type="dfn" href="#test-target" id="ref-for-test-target">test target</a>. A composite rule can have multiple "conditions", each of these tested in a separate atomic rule. The logic in the composite rule describes how any one of these satisfying conditions, or some combination of them, is used to determine a single outcome.</p>
</ul>
<p>Composite rules cannot contain other composite rules. Any time a nested composite rule would be needed, all of the relevant atomic rules can be combined directly into the new composite rule.</p>
<aside class="example" id="example-73f36a1c">
<a class="self-link" href="#example-73f36a1c"></a>
<header>Example of using multiple input rules in a composite rule:</header>
<blockquote>
<p>Each HTML <code>video</code> element meets all expectations from at least one of the following rules:</p>
<ul>
<li>Video elements have a transcript
<li>Video elements have an audio description
<li>Video elements have a description track
</ul>
</blockquote>
</aside>
<p>Not all atomic rules have to be part of a composite rule. Composite rules are used when the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome②">outcomes</a> of multiple atomic rules need to be combined to determine if a <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject①">test subject</a> does not satisfy an <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement②">accessibility requirement</a>.</p>
<p>The separation between atomic rules and composite rules creates a division of responsibilities. Atomic rules test if web content is correctly implemented in a particular solution. Composite rules can test if a combination of <a data-link-type="dfn" href="#outcome" id="ref-for-outcome③">outcomes</a> from other atomic rules satisfy the accessibility requirement, in part or as a whole.</p>
<h2 class="heading settled" data-level="4" id="act-rule-structure"><span class="secno">4. </span><span class="content">ACT Rule Structure</span><a class="self-link" href="#act-rule-structure"></a></h2>
<p>An ACT Rule <em class="rfc2119">must</em> consist of at least the following items:</p>
<ul>
<li data-md>
<p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="descriptive-title">Descriptive Title</dfn></p>
<li data-md>
<p><a href="#rule-identifier">Rule Identifier</a></p>
<li data-md>
<p><a href="#rule-description">Rule Description</a></p>
<li data-md>
<p><a href="#rule-type">Rule Type</a></p>
<li data-md>
<p><a href="#accessibility-requirements-mapping">Accessibility Requirements Mapping</a></p>
<li data-md>
<p><a href="#input">Rule Input</a>, which is one of the following:</p>
<ul>
<li data-md>
<p><a href="#input-aspects">Input Aspects</a> (for atomic rules) OR</p>
<li data-md>
<p><a href="#input-rules">Input Rules</a> (for composite rules)</p>
</ul>
<li data-md>
<p><a href="#applicability">Applicability</a></p>
<li data-md>
<p><a href="#expectations">Expectations</a></p>
<li data-md>
<p><a href="#assumptions">Assumptions</a></p>
<li data-md>
<p><a href="#accessibility-support">Accessibility Support</a></p>
<li data-md>
<p><a href="#test-cases">Test Cases</a></p>
<li data-md>
<p><a href="#change-log">Change Log</a></p>
<li data-md>
<p><a href="#glossary">Glossary</a></p>
</ul>
<p>An ACT Rule MAY also contain:</p>
<ul>
<li data-md>
<p><a href="#issues-list">Issues List</a> (optional)</p>
<li data-md>
<p><a href="#background">Background</a> (optional)</p>
<li data-md>
<p><a href="#acknowledgements">Acknowledgements</a> (optional)</p>
</ul>
<p>The ACT Rules format does not prescribe what format ACT Rules can be written in (e.g. HTML, DOCX, PDF, etc.). However, ACT Rules <em class="rfc2119">must</em> be written in a document that conforms to the Web Content Accessibility Guidelines <a data-link-type="biblio" href="#biblio-wcag">[WCAG]</a> or a comparable accessibility standard. This ensures that ACT Rules are accessible to people with disabilities. ACT Rule <a href="#test-cases">test cases</a> are allowed to contain inaccessible content. If any test case contains accessibility issues listed in <a href="https://www.w3.org/TR/WCAG21/#cc5">WCAG 2.1 Section 5.2.5 Non-Interference</a>, users <em class="rfc2119">must</em> be warned of this in advance. In addition to supporting people with disabilities, using an accessible format also makes internationalization of ACT Rules easier.</p>
<h3 class="heading settled" data-level="4.1" id="rule-identifier"><span class="secno">4.1. </span><span class="content">Rule Identifier</span><a class="self-link" href="#rule-identifier"></a></h3>
<p>An ACT Rule <em class="rfc2119">must</em> have an identifier. This identifier <em class="rfc2119">must</em> be unique when the rule is part of a ruleset. The identifier can be any text, such as plain text, URL, or a database identifier.</p>
<aside class="example" id="example-8adf6793">
<a class="self-link" href="#example-8adf6793"></a>
<header>Example of identifiers that are also used as filenames; They include a technology directory, followed by a handle that includes an element name or attribute:</header>
<blockquote>
<ul>
<li>html+svg/video-alternative
<li>html+svg/meta-no-refresh
<li>html+svg/unique-id
</ul>
</blockquote>
</aside>
<p>In addition to the identifier, each new release of an ACT Rule <em class="rfc2119">must</em> be versioned with either a date or a number. A reference to the previous version of that rule <em class="rfc2119">must</em> be available. The identifier <em class="rfc2119">must not</em> be changed when the rule is updated. For substantial changes, a new rule <em class="rfc2119">should</em> be created with a new identifier, and the old rule <em class="rfc2119">should</em> be deprecated.</p>
<aside class="example" id="example-c6a27e25">
<a class="self-link" href="#example-c6a27e25"></a>
<header>Example situation of updating a rule:</header>
<blockquote>
<p>When updating a rule that is about buttons, to now also be about links, menu items and tabs, the buttons rule is deprecated. As a replacement, a new rule is created that is applicable to all those elements.</p>
</blockquote>
</aside>
<h3 class="heading settled" data-level="4.2" id="rule-description"><span class="secno">4.2. </span><span class="content">Rule Description</span><a class="self-link" href="#rule-description"></a></h3>
<p>An ACT Rule <em class="rfc2119">must</em> have a description that is in plain language which provides a brief explanation of what the rule does.</p>
<aside class="example" id="example-5275cb2a">
<a class="self-link" href="#example-5275cb2a"></a>
<header>Example of a rule description:</header>
<blockquote>
<p>This rule checks that the HTML page has a title</p>
</blockquote>
</aside>
<h3 class="heading settled" data-level="4.3" id="rule-type"><span class="secno">4.3. </span><span class="content">Rule Type</span><a class="self-link" href="#rule-type"></a></h3>
<p>An ACT Rule <em class="rfc2119">must</em> have a rule type which is one of the following:</p>
<ul>
<li>Atomic rule
<li>Composite rule
</ul>
<p>Refer to the <a href="#rule-types">Rule Type</a> section for detailed definitions of the rule types.</p>
<h3 class="heading settled" data-level="4.4" id="accessibility-requirements-mapping"><span class="secno">4.4. </span><span class="content">Accessibility Requirements Mapping</span><a class="self-link" href="#accessibility-requirements-mapping"></a></h3>
<p>When an ACT Rule is designed to test conformance to one or more <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document①">Accessibility requirements documents</a>, the rule <em class="rfc2119">must</em> list all <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement③">accessibility requirements</a> from those documents that are not satisfied when one or more of the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome④">outcomes</a> of the rule is <code>failed</code>. For example, when designing a rule for WCAG that tests if image buttons have alternative text, the rule maps to success criteria 1.1.1 Non-text content, and 4.1.2 Name, Role, Value. That ACT Rule will list both success criteria in its accessibility requirements mapping.</p>
<p>Each <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement④">accessibility requirement</a> in the mapping <em class="rfc2119">must</em> include the following:</p>
<ol>
<li data-md>
<p>either the name, title, identifier or summary of the accessibility requirement, and</p>
<li data-md>
<p>the name of the <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document②">accessibility requirements document</a>, and</p>
<li data-md>
<p>a link or reference to the <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document③">accessibility requirements document</a> if one exists, and</p>
<li data-md>
<p>the conformance level associated with the accessibility requirement, if one exists.</p>
</ol>
<h4 class="heading settled" data-level="4.4.1" id="outcome-mapping"><span class="secno">4.4.1. </span><span class="content">Outcome Mapping</span><a class="self-link" href="#outcome-mapping"></a></h4>
<p>For each accessibility requirement in the mapping, an ACT Rule <em class="rfc2119">must</em> indicate what the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑤">outcomes</a> of the rule mean for satisfying that accessibility requirement for that <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject②">test subject</a>. When one or more of the outcomes for a test target is <code>failed</code>, the accessibility requirements are <dfn data-dfn-type="dfn" data-noexport id="not-satisfied">not satisfied<a class="self-link" href="#not-satisfied"></a></dfn> for the test subject. When all of the outcomes are <code>passed</code> or <code>inapplicable</code>, the accessibility requirements could be <dfn data-dfn-type="dfn" data-noexport id="satisfied">satisfied<a class="self-link" href="#satisfied"></a></dfn>, or <dfn data-dfn-type="dfn" data-noexport id="further-testing-is-needed">further testing is needed<a class="self-link" href="#further-testing-is-needed"></a></dfn>. Rules that can be used to determine if an accessibility requirement is <em>satisfied</em> are called <dfn data-dfn-type="dfn" data-noexport id="satisfying-tests">satisfying tests<a class="self-link" href="#satisfying-tests"></a></dfn>.</p>
<div class="note" role="note">
<p><strong>Note:</strong> In the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag">[WCAG]</a>, success criteria do not evaluate to <code>passed</code>, <code>failed</code> or <code>inapplicable</code>. Rather they can be <em>satisfied</em> (or not). (See the <a href="https://www.w3.org/TR/WCAG21/#dfn-satisfies">WCAG 2.1 definition: satisfies a success criterion</a>.) If a success criterion is <em>not satisfied</em>, a web page can only conform if there is a conforming alternative version, as described in <a href="https://www.w3.org/TR/WCAG21/#cc1">WCAG 2.1 Conformance Requirement 1</a>.</p>
</div>
<aside class="example" id="example-cd520eaa">
<a class="self-link" href="#example-cd520eaa"></a>
<header>Example accessibility requirements mapping for a rule that tests if an image button has an accessible name:</header>
<blockquote>
<ul>
<li>
<a href="https://www.w3.org/TR/WCAG21/#non-text-content">Success criterion 1.1.1: Non-text content</a>
<ul>
<li><strong>Required for conformance</strong> to WCAG 2.0 and WCAG 2.1 level A and higher
<li>
Outcome mapping:
<ul>
<li>Any <code>failed</code> outcomes: not satisfied
<li>All <code>passed</code> outcomes: further testing is needed
<li>An <code>inapplicable</code> outcome: further testing is needed
</ul>
</ul>
<li>
<a href="https://www.w3.org/TR/WCAG21/#name-role-value">Success criterion 4.1.2: Name, Role, Value</a>
<ul>
<li><strong>Required for conformance</strong> to WCAG 2.0 and WCAG 2.1 level A and higher
<li>
Outcome mapping:
<ul>
<li>Any <code>failed</code> outcomes: not satisfied
<li>All <code>passed</code> outcomes: further testing is needed
<li>An <code>inapplicable</code> outcome: further testing is needed
</ul>
</ul>
</ul>
</blockquote>
</aside>
<h4 class="heading settled" data-level="4.4.2" id="mapping-outside-wcag"><span class="secno">4.4.2. </span><span class="content">Mapping Outside WCAG</span><a class="self-link" href="#mapping-outside-wcag"></a></h4>
<p>ACT Rules can be used to test accessibility requirements that are not part of a W3C accessibility standard, such as accessibility requirements in <a href="https://www.w3.org/TR/html/">Hypertext Markup Language</a> <a data-link-type="biblio" href="#biblio-html">[HTML]</a>, or tests in a methodology like <a href="https://disic.github.io/rgaa_referentiel_en/criteria.html">RGAA 3 2016</a>. An ACT Rule <em class="rfc2119">must</em> indicate whether or not the <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑤">accessibility requirement</a> it maps to is required for conformance in its <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document④">accessibility requirements document</a>. Examples of accessibility requirements that are not required for conformance are WCAG sufficient techniques, or a company style guide that includes both requirements and optional "best practices". The distinction between what is required and what is optional has to be clear.</p>
<aside class="example" id="example-fd451b99">
<a class="self-link" href="#example-fd451b99"></a>
<header>Example accessibility requirements mapping for a rule that tests that each <code>img</code> element has an <code>alt</code> attribute:</header>
<blockquote>
<ul>
<li>
<a href="https://www.w3.org/TR/WCAG20-TECHS/H37.html">Technique H37: Using alt attributes on img elements</a>
<ul>
<li><strong>Not required</strong> for conformance to WCAG 2.0 and WCAG 2.1 at any level
<li>
Outcome mapping:
<ul>
<li>Any <code>failed</code> outcomes: not satisfied
<li>All <code>passed</code> outcomes: satisfied
<li>An <code>inapplicable</code> outcome: satisfied
</ul>
</ul>
<li>
<a href="https://disic.github.io/rgaa_referentiel_en/criteria.html#test-1-1-1">RGAA 3, Test 1.1.1: Does each image have a text alternative</a>
<ul>
<li><strong>Required for conformance</strong> to RGAA 3 level A and higher
<li>
Outcome mapping:
<ul>
<li>Any <code>failed</code> outcomes: not satisfied
<li>All <code>passed</code> outcomes: satisfied
<li>An <code>inapplicable</code> outcome: satisfied
</ul>
</ul>
</ul>
</blockquote>
</aside>
<h4 class="heading settled" data-level="4.4.3" id="rules-without-accessibility-requirements"><span class="secno">4.4.3. </span><span class="content">Rules Without Accessibility Requirements</span><a class="self-link" href="#rules-without-accessibility-requirements"></a></h4>
<p>If the rule does not map to any <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑥">accessibility requirement</a>, the accessibility requirement mapping will only contain the explainer that it is not required for conformance to the <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document⑤">accessibility requirements document</a>. This is common with atomic rules used in composite rules.</p>
<aside class="example" id="example-707e7231">
<a class="self-link" href="#example-707e7231"></a>
<header>Example of a rule that tests if <code>role=alert</code> is used to satisfy <a href="https://www.w3.org/TR/WCAG21/#status-messages">WCAG 2.1 success criterion 4.1.3 Status Messages</a>:</header>
<blockquote>
<p>This rule is <strong>not required</strong> for conformance to WCAG 2.1 at any level.</p>
</blockquote>
</aside>
<p>If the <code>failed</code> <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑥">outcome</a> cannot be mapped to an <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑦">accessibility requirement</a>, there <em class="rfc2119">must not</em> be an accessibility requirement in the accessibility requirements mapping. The optional <a href="#background">Background section</a> could be used to list <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document⑥">accessibility requirements documents</a> when they are thematically related, but for which the rule is not a failure test.</p>
<h4 class="heading settled" data-level="4.4.4" id="external-accessibility-requirements-mapping"><span class="secno">4.4.4. </span><span class="content">External Accessibility Requirements Mapping</span><a class="self-link" href="#external-accessibility-requirements-mapping"></a></h4>
<p>This section is <em>non-normative</em>.</p>
<p>While rules are often designed for one, or possibly a small collection of <a data-link-type="dfn" href="#accessibility-requirements-document" id="ref-for-accessibility-requirements-document⑦">accessibility requirements documents</a>, it is likely that other accessibility requirements documents also map to those ACT Rules. For example, rules can be written for the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag">[WCAG]</a>, but many of those could also map to a company’s internal accessibility policy. In such a scenario, an external accessibility requirements mapping could be created. An external accessibility requirements mapping amends the accessibility requirements mapping of an ACT rule by adding mapping to a different accessibility requirements document. An external accessibility requirements mapping avoids duplication of a rule for the sole purpose of changing the mapping.</p>
<h3 class="heading settled" data-level="4.5" id="input"><span class="secno">4.5. </span><span class="content">Rule Input</span><a class="self-link" href="#input"></a></h3>
<p>To evaluate content using an ACT Rule, the rule requires some information from the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject③">test subject</a>. This is the input for the rule. What input is required is made explicit, to help testers understand what capabilities are required to use a rule. <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules①">Atomic rules</a> and <a data-link-type="dfn" href="#composite-rules" id="ref-for-composite-rules">composite rules</a> have different input.</p>
<ul>
<li data-md>
<p>Atomic rules have <a href="#input-aspects">Input Aspects</a></p>
<li data-md>
<p>Composite rules have <a href="#input-rules">Input Rules</a></p>
</ul>
<h4 class="heading settled" data-level="4.5.1" id="input-aspects"><span class="secno">4.5.1. </span><span class="content">Input Aspects (Atomic rules only)</span><a class="self-link" href="#input-aspects"></a></h4>
<p>An input aspect is a distinct part of the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject④">test subject</a>. Rendering a particular piece of content to an end user commonly involves different technologies, some or all of which are required as input for an <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules②">atomic rule</a>. For example, some rules need to operate directly on the <a href="https://tools.ietf.org/html/rfc7230">Hypertext Transfer Protocol</a> <a data-link-type="biblio" href="#biblio-http11">[http11]</a> messages exchanged between a server and a client, while others need to operate on the <a href="https://dom.spec.whatwg.org">Document Object Model</a> <a data-link-type="biblio" href="#biblio-dom">[DOM]</a> tree exposed by a web browser.</p>
<p><a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules③">Atomic rules</a> <em class="rfc2119">must</em> list the aspects used as input for the <a href="#applicability-atomic">applicability</a> and <a href="#expectations-atomic">expectations</a> of the atomic rule. Rules can operate on several aspects simultaneously, such as both the HTTP messages and the DOM tree.</p>
<p>Some input aspects are well defined in a formal specification, such as HTTP messages, the DOM tree, and CSS styling <a data-link-type="biblio" href="#biblio-css-2018">[css-2018]</a>. For these, a reference to the corresponding section in the <a href="https://w3c.github.io/wcag-act/NOTE-act-rules-common-aspects.html">Common Input Aspects note</a> is sufficient as a description of the aspect. For input aspects that are not well defined, an ACT Rule <em class="rfc2119">must</em> include either a detailed description of the aspect in question, or a reference to a well defined description.</p>
<aside class="example" id="example-43214b40">
<a class="self-link" href="#example-43214b40"></a>
<header>Example input aspects for a rule that checks if a transcript is available for videos:</header>
<blockquote>
<ul>
<li>DOM Tree
<li>CSS Styling
<li>Audio output
<li>Visual output
</ul>
</blockquote>
</aside>
<aside class="example" id="example-22444586">
<a class="self-link" href="#example-22444586"></a>
<header>Example input aspects for a rule that checks for use of (language specific) generic link texts like "click here" and "more":</header>
<blockquote>
<ul>
<li>DOM Tree
<li>CSS Styling
<li>Language
</ul>
</blockquote>
</aside>
<p>The method through which an input aspect is served is not relevant. For example a DOM tree can be served through HTTP as HTML, it can be bundled as several pages in an <a href="http://www.idpf.org/epub3/latest/">EPUB publication</a>, or it can be inferred from a <a href="https://facebook.github.io/jsx/">JSX source file</a>. All rules that have only DOM tree as an input aspect can be applied to those technologies.</p>
<h4 class="heading settled" data-level="4.5.2" id="input-rules"><span class="secno">4.5.2. </span><span class="content">Input Rules (Composite rules only)</span><a class="self-link" href="#input-rules"></a></h4>
<p>A <a data-link-type="dfn" href="#composite-rules" id="ref-for-composite-rules①">composite rule</a> uses <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑦">outcomes</a> from <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules④">atomic rules</a> and applies logic to them so that a single outcome can be determined for each <a data-link-type="dfn" href="#test-target" id="ref-for-test-target①">test target</a>. The <a href="#rule-identifier">identifier</a> and <a data-link-type="dfn" href="#descriptive-title" id="ref-for-descriptive-title">descriptive title</a> of all the atomic rules used in the <a href="#expectations-composite">expectations</a> <em class="rfc2119">must</em> be listed in the composite rule. The input rules describe the input for composite rules, similar to how <a href="#input-aspects">input aspects</a> describe the input for atomic rules.</p>
<h3 class="heading settled" data-level="4.6" id="applicability"><span class="secno">4.6. </span><span class="content">Applicability</span><a class="self-link" href="#applicability"></a></h3>
<p>The applicability describes what parts of the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑤">test subject</a> are tested.</p>
<h4 class="heading settled" data-level="4.6.1" id="applicability-atomic"><span class="secno">4.6.1. </span><span class="content">Applicability for Atomic Rules</span><a class="self-link" href="#applicability-atomic"></a></h4>
<p>The applicability section is a required part of an <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules⑤">atomic rule</a>. It <em class="rfc2119">must</em> contain a precise description of the parts of the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑥">test subject</a> to which the rule applies. For example, specific nodes in the DOM <a data-link-type="biblio" href="#biblio-dom">[DOM]</a> tree, or tags that are incorrectly closed in an HTML <a data-link-type="biblio" href="#biblio-html">[HTML]</a> document. These are known as the <a data-link-type="dfn" href="#test-target" id="ref-for-test-target②">test targets</a>. The applicability <em class="rfc2119">must</em> only use information made available through the listed <a href="#input-aspects">input aspects</a> in the rule. No other information can be used in the applicability. Applicability <em class="rfc2119">must</em> be described objectively, unambiguously and in plain language.</p>
<p>An objective description is one that can be resolved without uncertainty, in a given technology. Examples of objective properties in HTML are tag names, their computed role, the distance between two elements, etc. Subjective properties on the other hand, are concepts like decorative, navigation mechanism and pre-recorded.</p>
<p>Even concepts like headings and images can be misunderstood. These terms could refer to the tag name, the semantic role, or the element’s purpose on the web page because they are ambiguous. The latter of which is almost impossible to define objectively. When used in applicability, potentially ambiguous concepts <em class="rfc2119">must</em> be defined objectively. Definitions can be put in the rule <a href="#glossary">glossary</a>, or they can be defined in the section where they are used.</p>
<aside class="example" id="example-7b01134a">
<a class="self-link" href="#example-7b01134a"></a>
<header>Example applicability of an atomic rule testing <a href="https://www.w3.org/WAI/WCAG21/quickref/#audio-control">WCAG 2.1 success criterion 1.4.2 Audio Control</a>:</header>
<blockquote>
<p>Each <code>video</code> or <code>audio</code> element with the <code>autoplay</code> attribute, as well as each <code>object</code> element that is used for automatically playing video or audio when the web page loads.</p>
<p>Note: A web page is considered "loaded" when the <code>document.readyState</code> is set to <code>complete</code>.</p>
</blockquote>
</aside>
<aside class="example" id="example-5412edb8">
<a class="self-link" href="#example-5412edb8"></a>
<header>Example applicability of a rule with the page as a test target</header>
<blockquote>
<p>The rule applies to any page where the document element is an <code>html</code> element, and the <code>html</code> element is rendered in a top-level context (i.e. the <code>html</code> element is not embedded in another page, such as through <code>iframe</code> or <code>object</code> elements). </p>
</blockquote>
</aside>
<aside class="example" id="example-2aec263c">
<a class="self-link" href="#example-2aec263c"></a>
<header>Example applicability of a rule with a DOM attribute as a test target</header>
<blockquote>
<p>The rule applies to any <code>role</code> attribute that is specified on an HTML or SVG element.</p>
</blockquote>
</aside>
<h4 class="heading settled" data-level="4.6.2" id="applicability-composite"><span class="secno">4.6.2. </span><span class="content">Applicability for Composite Rules</span><a class="self-link" href="#applicability-composite"></a></h4>
<p>The applicability of a composite rule is defined as the union of all applicability definitions from the rules listed in the <a href="#input-rules">input rules</a>. Rule authors <em class="rfc2119">may</em> omit a description of the applicability for composite rules. This can be useful if it is difficult to express the combined applicability in plain language. If the composite rule includes applicability, it <em class="rfc2119">must</em> be the union of all the applicability in the <a href="#input-rules">input rules</a>.</p>
<p>Note that input rules in a composite rule <em class="rfc2119">may</em> have different applicability. Because of this, not every test target applicable within the composite rule is tested by every input rule.</p>
<aside class="example" id="example-5ca938b6">
<a class="self-link" href="#example-5ca938b6"></a>
<header>Example of the union of applicability of input rules in a composite rule:</header>
<blockquote>
<p><strong>Input applicability:</strong></p>
<ul>
<li><strong>Input Rule 1:</strong> All <code>img</code> element <em>with</em> an <code>alt</code> attribute
<li><strong>Input Rule 2:</strong> All <code>img</code> element <em>without</em> an <code>alt</code> attribute
</ul>
<p><strong>Combined applicability:</strong></p>
<p>All <code>img</code> elements.</p>
</blockquote>
</aside>
<h3 class="heading settled" data-level="4.7" id="expectations"><span class="secno">4.7. </span><span class="content">Expectations</span><a class="self-link" href="#expectations"></a></h3>
<p>An ACT Rule <em class="rfc2119">must</em> contain one or more expectations. The expectations describe what the requirements are for the <a data-link-type="dfn" href="#test-target" id="ref-for-test-target③">test targets</a> derived from the <a href="#applicability">applicability</a>. An expectation is an assertion about a <a data-link-type="dfn" href="#test-target" id="ref-for-test-target④">test target</a>. When a test target meets all expectations, the test target <code>passed</code> the rule. If the test target does not meet all expectations, the test target <code>failed</code> the rule. If there are no test targets, the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑧">outcome</a> for the rule is <code>inapplicable</code>.</p>
<p>Each expectation <em class="rfc2119">must</em> be distinct, unambiguous, and be written in plain language.</p>
<h4 class="heading settled" data-level="4.7.1" id="expectations-atomic"><span class="secno">4.7.1. </span><span class="content">Expectations for Atomic Rules</span><a class="self-link" href="#expectations-atomic"></a></h4>
<p>All expectations of an <a data-link-type="dfn" href="#atomic-rules" id="ref-for-atomic-rules⑥">atomic rule</a> <em class="rfc2119">must</em> describe the logic that is used to determine a single <code>passed</code> or <code>failed</code> <a data-link-type="dfn" href="#outcome" id="ref-for-outcome⑨">outcome</a> for a <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑤">test target</a>. The expectation <em class="rfc2119">must</em> only use information available in the <a href="#input-aspects">input aspects</a>, from the applicability, and other expectations of the same rule. No other information can be used in the expectation. So for instance, an expectation could be "Expectation 1 is true and ...", but it can’t be "Rule XYZ passed and ...". This ensures that atomic rules are encapsulated.</p>
<aside class="example" id="example-6e5a951f">
<a class="self-link" href="#example-6e5a951f"></a>
<header>Example expectations of a rule to test for accessible names of HTML <code>input</code> elements:</header>
<blockquote>
<ol>
<li>Each HTML <code>input</code> element has an accessible name (as described in <a href="https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te">Accessible Name and Description: Computation and API Mappings 1.1</a>). <a data-link-type="biblio" href="#biblio-accname-aam-11">[accname-aam-1.1]</a>
<li>The accessible name describes the purpose of each HTML <code>input</code> element.
</ol>
</blockquote>
</aside>
<aside class="example" id="example-3722e455">
<a class="self-link" href="#example-3722e455"></a>
<header>Example expectation of a rule to test if a <code>role</code> attribute is valid:</header>
<blockquote>
<ol>
<li>Each <code>role</code> attribute has a value that corresponds to a non-abstract <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA 1.1</a> role.
</ol>
</blockquote>
</aside>
<div class="note" role="note">
<p><strong>Note:</strong> Sometimes there is the need for rules with more complex aggregation, for example that X% of all images on a web page are expected to have text alternatives. In this case, the page itself needs to become the test target. The expectation would then be "The test target (the page) has a text alternative for X% of all img elements". The logic for calculating the expectations in such rules is left to the implementations, to avoid over-complexity of this rules format.</p>
</div>
<h4 class="heading settled" data-level="4.7.2" id="expectations-composite"><span class="secno">4.7.2. </span><span class="content">Expectations for Composite Rules</span><a class="self-link" href="#expectations-composite"></a></h4>
<p>All expectations of a <a data-link-type="dfn" href="#composite-rules" id="ref-for-composite-rules②">composite rule</a> <em class="rfc2119">must</em> describe the logic that is used to determine a single <code>passed</code> or <code>failed</code> <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①⓪">outcome</a> for a <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑥">test target</a>, based on the outcomes of rules in its <a href="#input-rules">input rules</a>. A composite rule expectation <em class="rfc2119">must not</em> use information from <a href="#input-aspects">input aspects</a>. The outcome for a composite rule is <code>inapplicable</code> when all input rules are inapplicable.</p>
<aside class="example" id="example-b02f1892">
<a class="self-link" href="#example-b02f1892"></a>
<header>Example expectations for the composite rule 'video elements have an audio description or media alternative' (<a href="https://www.w3.org/WAI/WCAG21/quickref/#audio-description-or-media-alternative-prerecorded">WCAG 2.1 success criterion 1.2.3 Audio Description or Media Alternative</a>):</header>
<blockquote>
<p>Each HTML <code>video</code> element meets all expectations from at least one of the following rules:</p>
<ul>
<li>video elements have a transcript
<li>video elements have an audio description
<li>video elements have a description track
</ul>
</blockquote>
</aside>
<aside class="example" id="example-b218f8a4">
<a class="self-link" href="#example-b218f8a4"></a>
<header>Example expectations for a composite rule that checks if a mechanism is available to escape a keyboard trap; Either through a standard mechanism, or one for which instructions are available:</header>
<blockquote>
<p>For each focusable element, the outcome of one of the following rules is <code>passed</code>:</p>
<ul>
<li>Keyboard trap with standard escape mechanism
<li>Keyboard trap with escape instructions
</ul>
</blockquote>
</aside>
<h3 class="heading settled" data-level="4.8" id="assumptions"><span class="secno">4.8. </span><span class="content">Assumptions</span><a class="self-link" href="#assumptions"></a></h3>
<p>An ACT Rule <em class="rfc2119">must</em> list any known assumptions, limitations or any exceptions for the evaluation, the test environment, technologies being used or the subject being tested. For example, a rule that would partially test <a href="https://www.w3.org/WAI/WCAG21/quickref/#contrast-minimum">WCAG 2.1 success criterion 1.4.3 Contrast (Minimum)</a> based on the inspection of CSS properties could state that it is only applicable to HTML text content styleable with CSS, and that the rule does not support images of text.</p>
<p>Sometimes there are multiple plausible ways that an accessibility requirement can be interpreted. For instance, it is not immediately obvious if emoji characters are "text" or "non-text content" in the <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag">[WCAG]</a>. Whatever the interpretation is, this <em class="rfc2119">must</em> be documented in the rule.</p>
<p>While the assumptions <em class="rfc2119">must</em> be included in the ACT Rule, it <em class="rfc2119">may</em> be empty when there are no known assumptions, limitations or exceptions.</p>
<h3 class="heading settled" data-level="4.9" id="accessibility-support"><span class="secno">4.9. </span><span class="content">Accessibility Support</span><a class="self-link" href="#accessibility-support"></a></h3>
<p>Content can be designed to rely on the support for particular accessibility features by different assistive technologies and user agents. For example, content using a particular <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA 1.1</a> feature relies on that feature to be supported by assistive technologies and user agents. This content would not work for assistive technologies and user agents that do not support WAI-ARIA. See the WCAG definition for <a href="https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported">accessibility supported</a> use of a web technology.</p>
<p>An ACT Rule <em class="rfc2119">must</em> include known limitations on accessibility support.</p>
<aside class="example" id="example-9e5ab5bd">
<a class="self-link" href="#example-9e5ab5bd"></a>
<header>
Example of a rule that checks if <code>aria-errormessage</code> is used to satisfy <a href="https://www.w3.org/TR/WCAG21/#status-messages">WCAG 2.1 success criterion 4.1.3 Status messages</a>:
<header>
<blockquote>
<p> The <code>aria-errormessage</code> property is known to have limited support with several major screen readers. This method cannot be relied on for support. Alternatives, like using live regions, could serve as fallback. (January 2019) </p>
</blockquote>
</header>
</header>
</aside>
<p>While an accessibility support section <em class="rfc2119">must</em> be included in the ACT Rule, it <em class="rfc2119">may</em> be empty when there are no known accessibility support issues.</p>
<div class="note" role="note">
<p><strong>Note:</strong> The Website Accessibility Conformance Evaluation Methodology (WCAG-EM) provides guidance on defining an <a href="https://www.w3.org/TR/WCAG-EM/#step1c">accessibility support baseline</a> for test scenarios, which can help users of ACT Rules to select the appropriate rules for their own circumstance.</p>
</div>
<h3 class="heading settled" data-level="4.10" id="test-cases"><span class="secno">4.10. </span><span class="content">Test Cases</span><a class="self-link" href="#test-cases"></a></h3>
<p>Test cases are (snippets of) content that can be used to validate the implementation of ACT Rules. Each rule <em class="rfc2119">must</em> have one or more test cases for <code>passed</code>, <code>failed</code>, and <code>inapplicable</code> <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①①">outcomes</a>. A test case consists of two pieces of data, a snippet of each <a href="#input-aspects">input aspect</a> for a rule, and the expected outcome for that rule. Test cases serve two functions, firstly as example scenarios for readers to understand when the outcome of a rule is <code>passed</code>, <code>failed</code>, or <code>inapplicable</code>. It also serves developers and users of accessibility testing tools and methodologies to validate that a rule is correctly implemented.</p>
<aside class="example" id="example-09b9695b">
<a class="self-link" href="#example-09b9695b"></a>
<header>Example of HTML test cases for a rule that checks if <code>img</code> elements have a text alternative:</header>
<blockquote>
<p>Example of a <code>passed</code> outcome:</p>
<pre class="language-html highlight"><c- p><</c-><c- f>img</c-> <c- e>alt</c-><c- o>=</c-><c- s>"W3C Logo"</c-> <c- e>src</c-><c- o>=</c-><c- s>"image/w3c.png"</c-><c- p>></c->
</pre>
<p>Example of a <code>failed</code> outcome:</p>
<pre class="language-html highlight"><c- p><</c-><c- f>img</c-> <c- e>src</c-><c- o>=</c-><c- s>"image/w3c.png"</c-><c- p>></c->
</pre>
<p>Example of an <code>inapplicable</code> outcome:</p>
<pre class="language-html highlight"><c- p><</c-><c- f>input</c-> <c- e>type</c-><c- o>=</c-><c- s>"image"</c-> <c- e>alt</c-><c- o>=</c-><c- s>"W3C Logo"</c-> <c- e>src</c-><c- o>=</c-><c- s>"image/w3c.png"</c-><c- p>></c->
</pre>
</blockquote>
</aside>
<h3 class="heading settled" data-level="4.11" id="change-log"><span class="secno">4.11. </span><span class="content">Change Log</span><a class="self-link" href="#change-log"></a></h3>
<p>It is important to keep track of changes to the ACT Rules so that users of the rules can understand if changes in test results are due to changes in the rules used when performing the tests, or from changes in the content itself. All changes to an ACT Rule that can change the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①②">outcomes</a> of an evaluation <em class="rfc2119">must</em> be recorded in a change log. The change log can either be part of the rule document itself or be referenced from it.</p>
<h3 class="heading settled" data-level="4.12" id="glossary"><span class="secno">4.12. </span><span class="content">Glossary</span><a class="self-link" href="#glossary"></a></h3>
<p>ACT Rules <em class="rfc2119">must</em> have a glossary section. The glossary <em class="rfc2119">must</em> contain the <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①③">outcome</a> definition, as well as any definitions used in <a href="#applicability">applicability</a> and <a href="#expectations">expectations</a> sections in the rule. Since changes to the definition change the rule, those definitions cannot be maintained independently of the rule. If a shared glossary is used for rules, any definition changes <em class="rfc2119">must</em> be included in the <a href="#change-log">change log</a> of all rules that use that definition.</p>
<h3 class="heading settled" data-level="4.13" id="issues-list"><span class="secno">4.13. </span><span class="content">Issues List (optional)</span><a class="self-link" href="#issues-list"></a></h3>
<p>An ACT Rule <em class="rfc2119">may</em> include a list or a reference to a list of any known issues. The issues list would be used to record cases where an <a data-link-type="dfn" href="#outcome" id="ref-for-outcome①④">outcome</a> of an ACT Rule was <code>failed</code> where it ought to have been <code>passed</code> or <code>inapplicable</code>, or vice versa. There are several reasons why this might occur. See <a href="#rule-accuracy">rule accuracy</a> for more information.</p>
<p>The issues list serves two purposes. For users of ACT Rules, the issues list gives insight into why an inaccurate result occurred, as well as provide confidence in the result of that rule. For the designer of the rule, the issues list is also useful to plan future updates to the rule. In a new version of the rule, resolved issues would be moved to the change log.</p>
<h3 class="heading settled" data-level="4.14" id="background"><span class="secno">4.14. </span><span class="content">Background (optional)</span><a class="self-link" href="#background"></a></h3>
<p>An ACT Rule <em class="rfc2119">may</em> contain information about the background for the development of the rule, or references to relevant reading. The background information is optional, but whenever it is included in the rule, the relationship to the relevant reading can be specified. Examples of relevant background references for a rule for a <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> <a data-link-type="biblio" href="#biblio-wcag">[WCAG]</a> success criterion could be <a href="https://www.w3.org/WAI/WCAG21/Understanding/">WCAG 2.1 Understanding documents</a>, <a href="https://www.w3.org/WAI/WCAG21/Techniques/">WCAG 2.1 Techniques</a>, or <a href="https://www.w3.org/TR/wai-aria/">WAI-ARIA 1.1</a>, CSS <a data-link-type="biblio" href="#biblio-css-2018">[css-2018]</a>, or HTML <a data-link-type="biblio" href="#biblio-html">[HTML]</a> specifications.</p>
<h3 class="heading settled" data-level="4.15" id="acknowledgements"><span class="secno">4.15. </span><span class="content">Acknowledgements (optional)</span><a class="self-link" href="#acknowledgements"></a></h3>
<p>An ACT Rule <em class="rfc2119">may</em> contain acknowledgements. This can include, but is not limited to:</p>
<ul>
<li data-md>
<p>List of rule authors</p>
<li data-md>
<p>List of rule reviewers/contributors</p>
<li data-md>
<p>Funding or other support</p>
</ul>
<h2 class="heading settled" data-level="5" id="rule-accuracy"><span class="secno">5. </span><span class="content">Rule Accuracy</span><a class="self-link" href="#rule-accuracy"></a></h2>
<p>This section is <em>non-normative</em>.</p>
<p>While <a href="#test-cases">test cases</a> can be used to determine if an ACT Rule was correctly implemented, they do not guarantee that implementations will never produce incorrect results. When writing ACT Rules, it is almost inevitable that edge cases will be overlooked. Technologies are always evolving, and content authors are constantly coming up with new and unexpected ways to use them. Some examples of causes for inaccuracy are:</p>
<ul>
<li data-md>
<p><a href="#assumptions">Assumptions</a> were made about the test subject that turned out to be untrue</p>
<li data-md>
<p>Technologies were used in an unusual and difficult to predict manner</p>
<li data-md>
<p>Technologies have changes, or aspects of the technologies were overlooked</p>
<li data-md>
<p>The accessibility requirement was not correctly interpreted</p>
</ul>
<p>There are two types of inaccuracies that can produce incorrect results. Inaccuracies in the <strong>implementation</strong> can be addressed with test cases, but inaccuracies in the <strong>ACT Rule itself</strong> cannot. After all, rule inaccuracies come from the rule author being unaware of a particular edge case.</p>
<p>When a test result incorrectly indicates non-conformance to an accessibility requirement, this is known as a false positive. Opposite, when a rule incorrectly indicates conformance, this is a false negative. A percentage of false positives and false negatives can be calculated by comparing it to results from an accessibility audit:</p>
<ul>
<li data-md>
<p><strong>False positives:</strong> This is the percentage of <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑦">test targets</a>, that were <code>failed</code> by the rule, but satisfy the <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑧">accessibility requirements</a>.</p>
<li data-md>
<p><strong>False negatives:</strong> This is the percentage of <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑧">test targets</a>, that were <code>passed</code> by the rule, but do not satisfy the <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement⑨">accessibility requirements</a>.</p>
</ul>
<p>The ever present possibility of false positives and false negatives with ACT Rules means they will likely require ongoing maintenance. Designing a process for maintaining ACT Rules is outside the scope of the ACT Rules Format, which is limited to the rules themselves. Nevertheless, it is suggested that rule authors work out a process for maintaining their rules.</p>
<h2 class="heading settled" data-level="6" id="harmonization"><span class="secno">6. </span><span class="content">Harmonization</span><a class="self-link" href="#harmonization"></a></h2>
<p>This section is <em>non-normative</em>.</p>
<p>While the ACT Rules Format is designed to stimulate harmonization, there are no direct requirement in the ACT Rules Format that prevent a rule author from writing rules inconsistent with already established ACT Rules. Neither are there requirements for ACT Rules to have a certain number of implementations, or to have a certain level of accuracy. This allows quality requirements to be different for different rulesets, and allows them to develop over time.</p>
<p>Harmonization occurs when a group of rule implementors collectively accept the validity of an ACT Rule. For example, a community group of accessibility testing tool vendors could declare they have harmonized on a particular set of ACT Rules. Such a group can set acceptance criteria for rules, and have quality requirements that go beyond the ACT Rules Format.</p>
<aside class="example" id="example-65a5c06a">
<a class="self-link" href="#example-65a5c06a"></a>
<header>Example of acceptance criteria for a group working on EPUB rules:</header>
<blockquote>
<ul>
<li>An ACT EPUB Rule is harmonized when it is approved by members of 3 organizations, AND
<li>An ACT EPUB Rule is harmonized when it has 2 independent implementations
</ul>
</blockquote>
</aside>
<p>An example of such a process is the <a href="https://w3c.github.io/wcag-act-rules/review-process.html">WCAG ACT Review Process</a>.</p>
<h2 class="heading settled" data-level="7" id="definitions"><span class="secno">7. </span><span class="content">Definitions</span><a class="self-link" href="#definitions"></a></h2>
<dl>
<dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="accessibility-requirement">Accessibility requirement</dfn>
<dt>
<dd>
<p>A requirement is a condition that has to be satisfied in order to conform to a standard, or to comply with a contract, policy or regulation. An accessibility requirement is a requirement aimed at improving access for people with disabilities to an ICT product.</p>
<p>A common example of accessibility requirements are the WCAG success criteria. There are other standards, including W3C standards, that have recommendations for accessibility, such as WAI-ARIA and HTML. Accessibility requirements are also often found in company policies, regional standards or in legislation.</p>
<dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="accessibility-requirements-document">Accessibility requirements document</dfn>
<dt>
<dd>
<p>A document, such as a standard, contract, policy or regulation, that includes <a data-link-type="dfn" href="#accessibility-requirement" id="ref-for-accessibility-requirement①⓪">accessibility requirements</a>. For example, WCAG 2.1, WAI-ARIA 1.1, HTML 5.2, EPUB Accessibility 1.0, BBC HTML Accessibility Standards v2.0</p>
<dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="outcome">Outcome</dfn>
<dd>
<p>A conclusion that comes from evaluating an ACT Rule on a <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑦">test subject</a> or one of its constituent <a data-link-type="dfn" href="#test-target" id="ref-for-test-target⑨">test target</a>. An outcome can be one of the three following types:</p>
<ul>
<li><strong>Inapplicable:</strong> No part of the test subject matches the applicability
<li><strong>Passed:</strong> A <a data-link-type="dfn" href="#test-target" id="ref-for-test-target①⓪">test target</a> meets all expectations
<li><strong>Failed:</strong> A <a data-link-type="dfn" href="#test-target" id="ref-for-test-target①①">test target</a> does not meet all expectations
</ul>
<div class="note" role="note">
<p><strong>Note:</strong> A rule has one <code>passed</code> or <code>failed</code> outcome for every <a data-link-type="dfn" href="#test-target" id="ref-for-test-target①②">test target</a>. When there are no test targets the rule has one <code>inapplicable</code> outcome. This means that each <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑧">test subject</a> will have one or more outcomes.</p>
</div>
<div class="note" role="note">
<p><strong>Note:</strong> Implementers using the <a data-link-type="biblio" href="#biblio-earl10-schema">[EARL10-Schema]</a> can express the outcome with the <a href="https://www.w3.org/TR/EARL10-Schema/#outcome">outcome property</a>. In addition to <code>passed</code>, <code>failed</code> and <code>inapplicable</code>, EARL 1.0 also defined an <code>incomplete</code> outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the <code>incomplete</code> outcome. </p>
</div>
<dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="test-subject">Test Subject</dfn>
<dd>
<p>A resource or collection of resources that can be evaluated by an ACT Rule.</p>
<aside class="example" id="example-42b1dee1">
<a class="self-link" href="#example-42b1dee1"></a>
<header>Example of test subjects:</header>
<blockquote>
<ul>
<li>An HTML page, including all embedded scripts, style and images
<li>An EPUB publication
<li>A web component file
</ul>
</blockquote>
</aside>
<div class="note" role="note">
<p><strong>Note:</strong> Implementers using the <a data-link-type="biblio" href="#biblio-earl10-schema">[EARL10-Schema]</a> can express the test subject with the <a href="https://www.w3.org/TR/EARL10-Schema/#subject">subject property</a></p>
</div>
<dt><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="test-target">Test Target</dfn>
<dd>
<p>A distinct part of the <a data-link-type="dfn" href="#test-subject" id="ref-for-test-subject⑨">test subject</a>, as defined by the <a href="#applicability">applicability</a>.</p>
<aside class="example" id="example-cd7029f9">
<a class="self-link" href="#example-cd7029f9"></a>
<header>Example of test targets:</header>
<blockquote>
<ul>
<li>Nodes within an HTML page
<li>A period of time within a video
<li>A range of characters within a text document
</ul>
</blockquote>
</aside>
<div class="note" role="note">
<p><strong>Note:</strong> Implementers using the <a data-link-type="biblio" href="#biblio-earl10-schema">[EARL10-Schema]</a> can express the test target with the <a href="https://www.w3.org/TR/EARL10-Schema/#pointer">pointer property</a></p>
</div>
</dl>
<h2 class="heading settled" id="appendix-data-example"><span class="content">Appendix 1: Expressing ACT Rule results with JSON-LD and EARL</span><a class="self-link" href="#appendix-data-example"></a></h2>
<p>This section is <em>non-normative</em>.</p>
<p>This section provides examples of expressing results from carrying out ACT Rules using EARL and JSON-LD (See <a href="https://www.w3.org/WAI/standards-guidelines/earl/">Evaluation and Report Language</a> and <a href="https://www.w3.org/TR/json-ld/">A JSON-based Serialization for Linked Data (JSON-LD)</a>). More examples and background is proivided on the <a href="https://github.com/w3c/earl">JSON-LD serialization of EARL</a> GitHub repository.</p>
<p>Examples in this section include:</p>
<ul>
<li data-md>
<p>Example 1: Minimal outcome from one <a class="property" data-link-type="propdesc">Assertion</a></p>
<li data-md>
<p>Example 2: Results from more than one <a class="property" data-link-type="propdesc">Assertion</a></p>
<li data-md>
<p>Example 3: Aggregating based on <a class="property" data-link-type="propdesc">Requirement</a></p>
<li data-md>
<p>Example 4: Aggregating based on 'Test Subject'</p>
<li data-md>
<p>Example 5: Assumed <a class="property" data-link-type="propdesc">Context</a> for this section</p>
</ul>
<p><strong>Example 1:</strong> Minimal outcome for one <a class="property" data-link-type="propdesc">Assertion</a></p>
<pre class="language-javascript highlight"><c- p>{</c->
<c- u>"@context"</c-><c- o>:</c-> <c- u>"context.json"</c-><c- p>,</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c->
<c- u>"assertedBy"</c-><c- o>:</c-> <c- u>"https://example.org/MyTool"</c-><c- p>,</c->
<c- u>"subject"</c-><c- o>:</c-> <c- u>"https://example.org/page1.html"</c-><c- p>,</c->
<c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-CG:rules/23a2a8"</c-><c- p>,</c->
<c- u>"result"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c->
<c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:first-child"</c->
<c- p>}</c->
<c- p>}</c->
</pre>
<p><strong>Example 2:</strong> Results for more than one <a class="property" data-link-type="propdesc">Assertion</a></p>
<pre class="language-javascript highlight"><c- p>{</c->
<c- u>"@context"</c-><c- o>:</c-> <c- u>"context.json"</c-><c- p>,</c->
<c- u>"@graph"</c-><c- o>:</c-> <c- p>[{</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c->
<c- u>"assertedBy"</c-><c- o>:</c-> <c- u>"https://example.org/MyTool"</c-><c- p>,</c->
<c- u>"subject"</c-><c- o>:</c-> <c- u>"https://example.org/page1.html"</c-><c- p>,</c->
<c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-CG:rules/23a2a8"</c-><c- p>,</c->
<c- u>"result"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c->
<c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:first-child"</c->
<c- p>}</c->
<c- p>},</c-> <c- p>{</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c->
<c- u>"assertedBy"</c-><c- o>:</c-> <c- u>"https://example.org/AnotherTool"</c-><c- p>,</c->
<c- u>"subject"</c-><c- o>:</c-> <c- u>"https://example.org/page1.html"</c-><c- p>,</c->
<c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-CG:rules/23a2a8"</c-><c- p>,</c->
<c- u>"result"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:passed"</c-><c- p>,</c->
<c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:nth-child(2)"</c->
<c- p>}</c->
<c- p>}]</c->
<c- p>}</c->
</pre>
<p><strong>Example 3:</strong> Aggregating based on <a class="property" data-link-type="propdesc">Requirement</a> (eg. WCAG Success Criteria)</p>
<pre class="language-javascript highlight"><c- p>{</c->
<c- u>"@context"</c-><c- o>:</c-> <c- u>"context.json"</c-><c- p>,</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c->
<c- u>"assertedBy"</c-><c- o>:</c-> <c- u>"https://example.org/MyTool"</c-><c- p>,</c->
<c- u>"subject"</c-><c- o>:</c-> <c- u>"https://example.org/page1.html"</c-><c- p>,</c->
<c- u>"test"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c->
<c- u>"@id"</c-><c- o>:</c-> <c- u>"WCAG21:non-text-content"</c->
<c- p>},</c->
<c- u>"result"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c->
<c- u>"source"</c-><c- o>:</c-> <c- p>[{</c->
<c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-CG:rules/23a2a8"</c-><c- p>,</c->
<c- u>"result"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c->
<c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:first-child"</c->
<c- p>}</c->
<c- p>},</c-> <c- p>{</c->
<c- u>"test"</c-><c- o>:</c-> <c- u>"ACT-RULES-CG:rules/23a2a8"</c-><c- p>,</c->
<c- u>"result"</c-> <c- o>:</c-> <c- p>{</c->
<c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:passed"</c-><c- p>,</c->
<c- u>"pointer"</c-><c- o>:</c-> <c- u>"html > body > h1:nth-child(2)"</c->
<c- p>}</c->
<c- p>}]</c->
<c- p>}</c->
<c- p>}</c->
</pre>
<p><strong>Example 4:</strong> Aggregating based on 'Test Subject' (eg. for a website)</p>
<pre class="language-javascript highlight"><c- p>{</c->
<c- u>"@context"</c-><c- o>:</c-> <c- u>"context.json"</c-><c- p>,</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"Assertion"</c-><c- p>,</c->
<c- u>"assertedBy"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"Organization"</c-><c- p>,</c->
<c- u>"@id"</c-><c- o>:</c-> <c- u>"_:myOrg"</c-><c- p>,</c->
<c- u>"title"</c-><c- o>:</c-> <c- u>"My Organization"</c-><c- p>,</c->
<c- u>"description"</c-> <c- o>:</c-> <c- u>"Accessibility testing service"</c-><c- p>,</c->
<c- u>"homepage"</c-> <c- o>:</c-> <c- u>"http://example.org/myOrg/"</c->
<c- p>},</c->
<c- u>"subject"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"@type"</c-><c- o>:</c-> <c- p>[</c-><c- u>"WebSite"</c-><c- p>,</c-> <c- u>"TestSubject"</c-><c- p>],</c->
<c- u>"@id"</c-><c- o>:</c-> <c- u>"https://example.org/"</c->
<c- p>},</c->
<c- u>"test"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c->
<c- u>"@id"</c-><c- o>:</c-> <c- u>"http://www.w3.org/WAI/WCAG2A-Conformance"</c->
<c- p>},</c->
<c- u>"result"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c->
<c- u>"source"</c-><c- o>:</c-> <c- p>[{</c->
<c- u>"test"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c->
<c- u>"@id"</c-><c- o>:</c-> <c- u>"WCAG21:non-text-content"</c->
<c- p>},</c->
<c- u>"result"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"outcome"</c-><c- o>:</c-> <c- u>"earl:failed"</c-><c- p>,</c->
<c- u>"source"</c-><c- o>:</c-> <c- p>[</c-> … <c- p>]</c->
<c- p>}</c->
<c- p>},</c-> <c- p>{</c->
<c- u>"test"</c-><c- o>:</c-> <c- p>{</c->
<c- u>"@type"</c-><c- o>:</c-> <c- u>"earl:TestRequirement"</c-><c- p>,</c->
<c- u>"@id"</c-><c- o>:</c-> <c- u>"WCAG21:audio-only-and-video-only-prerecorded"</c->
<c- p>},</c->