-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathchecklist.html
More file actions
2200 lines (2060 loc) · 97.8 KB
/
checklist.html
File metadata and controls
2200 lines (2060 loc) · 97.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
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 charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="color-scheme" content="light dark" />
<title>FAST Checklist</title>
<link rel="stylesheet" href="checklist.css" />
</head>
<body>
<main>
<h1>[DRAFT] <abbr title="Framework for Accessible Specification of Technologies">FAST</abbr> Checklist</h1>
<p>
This is a draft checklist to support <a href="https://raw.githack.com/w3c/fast/checklist-W3C-format/index.html">Framework for Accessible Specification of Technologies (FAST)</a> prepared by the <a href="https://www.w3.org/WAI/about/groups/apawg/">Accessible Platform Architectures Working Group</a>. The goal of <abbr title="Framework for Accessible Specification of Technologies">FAST</abbr> is to describe the features that web technologies should provide to ensure it is possible to create content that is accessible to users with disabilities. The full framework references an analysis of user requirements, describes how technologies, content authoring, and user agents work together to meet these needs, and provides comprehensive guidance to technology developers. This checklist extracts that information at a high level to aid in self-review of technologies. Specification developers can use this to help ensure the technology will address features likely to be raised during horizontal review from accessibility proponents.
</p>
<p>Web technologies address a variety of needs, and play a variety of roles in web accessibility. Content languages describe primary content, styling languages impact presentation, APIs enable manipulation and data interchange, and protocols tie it all together. Each of these types of technologies can impact accessibility.</p>
<p>This checklist is organized by types of features that a technology may provide. If the technology provides such a feature, the checklist items under the heading are applicable and should be examined. If the technology does not provide such a feature, the checklist items under the heading are not applicable and can be passed over.</p>
<fieldset>
<legend>Document or spec being reviewed</legend>
<div class="grid-2c">
<label for="spec-name">Name:</label>
<input id="spec-name" type="text" name="spec-name" required />
<label for="spec-url">URL:</label>
<input id="spec-url" type="text" name="spec-url" aria-describedby="spec-url-desc" required />
</div>
<div id="spec-url-desc">
<p>Please ensure this dated, or for a specific commit, for example:</p>
<ul>
<li>
<p><a
href="https://www.w3.org/TR/2025/CRD-compute-pressure-20250521">https://www.w3.org/TR/2025/CRD-compute-pressure-20250521</a>
</p>
</li>
<li>
<p><a
href="https://github.com/guidou/webrtc-encoded-transform/blob/d9648352c57804b3bc805a3c649b3f2624025a7b/timestamps.md">https://github.com/guidou/webrtc-encoded-transform/blob/d9648352c57804b3bc805a3c649b3f2624025a7b/timestamps.md</a>
</p>
</li>
</ul>
</div>
</fieldset>
<fieldset>
<legend>GitHub repository of the document or spec being reviewed</legend>
<div class="grid-2c">
<label for="spec-repo">URL:</label>
<input id="spec-repo" type="text" name="spec-repo" aria-describedby="spec-repo-format" />
</div>
<p id="spec-repo-format"><b>Format: </b>https://github.com/org/repo</p>
</fieldset>
<fieldset>
<legend>
If technology allows visual rendering of content
</legend>
<input type="radio" id="q1_yes" name="q1" value="Yes" required aria-describedby="q1Description" checked />
<label for="q1_yes">Yes</label>
<input type="radio" id="q1_no" name="q1" value="No" required aria-describedby="q1Description" />
<label for="q1_no">No</label>
<details>
<summary>
Visual rendering checklist
</summary>
<table
role="table"
aria-label="If technology allows visual rendering of content checklist"
id="table1"
>
<thead>
<tr>
<th scope="col">Checkpoint</th>
<th scope="col">References</th>
<th scope="col">Met?</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row" aria-labelledby="s1">
<details open>
<summary id="s1">
There is a defined way for a non-visual rendering to be created.
</summary>
<p>
Content is frequently authored with visual rendering the primary
consideration. Some users are not able to access visual content,
and must use other forms of the content, such as text or audio.
</p>
</details>
</th>
<td> <a
href="https://www.w3.org/WAI/WCAG20/quickref/#non-text-content"
target="_blank"
rel="noopener noreferrer"
>WCAG 2.0 Quick Reference</a
></td>
</td>
<td class="met-column">
<label><input type="radio" id="met1" name="met1" value="yes"> Yes</label>
<label><input type="radio" id="met1" name="met1" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s2">
<details open>
<summary id="s2">
Content can be resized.
</summary>
<p>
Many users need content to be displayed larger than the default,
not just because of un-sharp vision but also to mitigate other
visual perception difficulties such as difficulty separating
foreground from background.
</p>
</details>
</th>
<td>
<a
href="https://www.w3.org/WAI/WCAG20/quickref/#resize-text"
target="_blank"
rel="noopener noreferrer"
>WCAG 2.0 Quick Reference</a
></td>
<td class="met-column">
<label><input type="radio" id="met2" name="met2" value="yes"> Yes</label>
<label><input type="radio" id="met2" name="met2" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s3">
<details open>
<summary id="s3">
Luminosity and hue contrast can adapt to user requirements.
</summary>
<p>
Users with color vision deficits and other visual impairments have
more difficulty separating certain foreground from background
colors than average.
</p>
</details>
</th>
<td>
<a
href="https://www.w3.org/WAI/WCAG20/quickref/#contrast-minimum"
target="_blank"
rel="noopener noreferrer"
>WCAG 2.0 Quick Reference</a
>
<td class="met-column">
<label><input type="radio" id="met3" name="met3" value="yes"> Yes</label>
<label><input type="radio" id="met3" name="met3" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s4">
<details open>
<summary id="s4">
Text presentation attributes can be changed.
</summary>
<p>
Some users with visual impairments and learning disabilities find
that customizing text presentation improves their ability to
distinguish letters, track lines, etc. Technologies should provide
features allowing users to customize typeface, font weight, font
style, line / word / letter spacing, margins, line length,
justification.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met4" name="met4" value="yes"> Yes</label>
<label><input type="radio" id="met4" name="met4" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s5">
<details open>
<summary id="s5">
Visual presentation of pointers and cursors can be adjusted.
</summary>
<p>
Sometimes pointer and cursor indicators are difficult for users to
distinguish and locate, and incessant animation, even simple
blinking, can be excessively distracting for some users.
Technologies that define pointer and cursor indicators should
provide features for user to customize size, color, and animation.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met5" name="met5" value="yes"> Yes</label>
<label><input type="radio" id="met5" name="met5" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s6">
<details open>
<summary id="s6">
Changing content presentation does not render it unreadable.
</summary>
<p>
Many accessibility requirements come down to allowing users to
customize presentation. When presentation is changed in a way the
author or designer did not anticipate, unexpected side effects
often appear that create new problems. A frequent situation is
when content is resized but the region for the content is not,
causing the content to be clipped. Another is when regions resize
but do not reposition, making it difficult to use the content at
the new scale. Change of font attributes sometimes leads to a
similar problem, such as when users change to a heavier font but
the space allocated for characters does not increase. Technologies
should provide features to ensure that change of display
attributes does not create unintended side effects.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met6" name="met6" value="yes"> Yes</label>
<label><input type="radio" id="met6" name="met6" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s7">
<details open>
<summary id="s7">
Technology does not allow blinking or flashing of content, or
provides a feature for users to quickly turn it off or
permanently disable it.
</summary>
<p>
Technologies should not provide features that allow authors to
create content that
<a
href="https://www.w3.org/TR/WCAG20/#blinksdef"
target="_blank"
rel="noopener noreferrer"
>blinks</a
>
(which can be excessively distracting) or
<a
href="https://www.w3.org/TR/WCAG20/#flash-def"
target="_blank"
rel="noopener noreferrer"
>flashes</a
>
(which can be medically disastrous). However, technologies that
provide general animation features (even simple ones) may be
unable to rule out author usages that create these effects. It is
important for such technologies to provide a feature for users to
stop animation, or prevent it until requested. More complex
technologies should also provide means to mark potentially
problematic content, warn users who have opted into the warning,
and give users the option to skip or suppress problematic regions
of content.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met7" name="met7" value="yes"> Yes</label>
<label><input type="radio" id="met7" name="met7" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s8">
<details open>
<summary id="s8">
It is possible to make navigation order correspond to the visual
presentation.
</summary>
<p>
Flexible display mechanisms can cause content to appear in
unpredicted locations. This is often a good feature as it allows
optimization of display. However, the navigation order of such
content sometimes does not match the perceived order, and users
have difficulty using linear (i.e., keyboard-based) navigation
effectively. Technologies should provide features to ensure when
the visual order of content changes, the interaction order changes
to match.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met8" name="met8" value="yes"> Yes</label>
<label><input type="radio" id="met8" name="met8" value="no"> No</label>
</td>
</tr>
</tbody>
</table>
</details>
</fieldset>
<fieldset>
<legend>
If technology provides author control over color
</legend>
<input type="radio" id="q2_yes" name="q2" value="Yes" required aria-describedby="q2Description" checked />
<label for="q2_yes">Yes</label>
<input type="radio" id="q2_no" name="q2" value="No" required aria-describedby="q2Description" />
<label for="q2_no">No</label>
<details>
<summary>
Author control checklist
</summary>
<table
role="table"
aria-label="If technology provides author control over color checklist"
id="table2"
>
<thead>
<tr>
<th scope="col">Checkpoint</th>
<th scope="col">References</th>
<th scope="col">Met?</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row" aria-labelledby="s9">
<details open>
<summary id="s9">
There is a mechanism for users to override colors of text and
user interface components.
</summary>
<p>
Custom color settings benefits not only users with visual
perception impairments, but also users who can be distracted by
certain colors or combinations. Technologies should provide
features to allow users to set their own colors or contrast for
text (including background) and standard user interface
components.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met9" name="met9" value="yes"> Yes</label>
<label><input type="radio" id="met9" name="met9" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s10">
<details open>
<summary id="s10">
There is a feature for authors to define semantically available
"color classes" that users can easily map to custom colors, and
give preference to this vs. coloring objects individually.
</summary>
<p>
Allowing user override of author design is most effective when the
technology provides rich semantics for content, on which author or
default colors are based, that can be easily recolored in a
meaningful manner. Technologies should define semantics, or a way
for authors to define and communicate the semantics they use, to
allow most effective recoloring with minimal advance knowledge of
site implementation.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met10" name="met10" value="yes"> Yes</label>
<label><input type="radio" id="met10" name="met10" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s11">
<details open>
<summary id="s11">
There is a feature for users to choose color schemata that work
for them.
</summary>
<p>
Content authors are frequently concerned with branding, and want
to ensure that the color scheme of content communicates the brand.
But when the color scheme makes content inaccessible to users this
goal can be counter-productive. Technologies can increase author
control and user accessibility by providing a way for authors to
define multiple color schemes, allowing more accessible schemes
still to partake in the branding process, and allowing users to
choose from among available schemes.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met11" name="met11" value="yes"> Yes</label>
<label><input type="radio" id="met11" name="met11" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s12">
<details open>
<summary id="s12">
The foreground and background color of an object can be reported
to the user via AT.
</summary>
<p>
Experienced color of content is frequently the way users refer to
it; for instance in "redlined" text people may say "find my edits
in red". Users of assistive technologies who cannot perceive the
color directly therefore still have a need to know the color in
order to interact with others. Therefore, technologies should
define a way for foreground and background color to be reported to
assistive technologies and easily searched.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met12" name="met12" value="yes"> Yes</label>
<label><input type="radio" id="met12" name="met12" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s13">
<details open>
<summary id="s13">
There are ways to set foreground and background colors
separately for all objects.
</summary>
<p>
Color contrast problems often arise when the foreground color of
one object is overlaid onto the (foreground or background) color
of another object, resulting in an unintended contrast. It is
therefore important for technologies to allow both the foreground
and background color of objects to be set to reasonable values and
avoid this overlay problem.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met13" name="met13" value="yes"> Yes</label>
<label><input type="radio" id="met13" name="met13" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s14">
<details open>
<summary id="s14">
Compositing rules for foreground and background colors are well
defined.
</summary>
<p>
When color compositing rules are not clearly designed, unexpected
color contrast can occur. The most frequent problem is when
aliasing of edges causes visual artifacts, which in the case of
text with its narrow strokes can significantly impact perception.
Impacts of borders, shadows, and transparency can also lead to
inaccessible contrast. Therefore technologies should specify
compositing rules very precisely.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met14" name="met14" value="yes"> Yes</label>
<label><input type="radio" id="met14" name="met14" value="no"> No</label>
</td>
</tr>
</tbody>
</table>
</details>
</fieldset>
<fieldset>
<legend>
If technology provides features to accept user input
</legend>
<input type="radio" id="q3_yes" name="q3" value="Yes" required aria-describedby="q3Description" checked />
<label for="q3_yes">Yes</label>
<input type="radio" id="q3_no" name="q3" value="No" required aria-describedby="q3Description" />
<label for="q3_no">No</label>
<details>
<summary>
User input checklist
</summary>
<table
role="table"
aria-label="If technology provides features to accept user input checklist"
id="table3"
>
<thead>
<tr>
<th scope="col">Checkpoint</th>
<th scope="col">References</th>
<th scope="col">Met?</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row" aria-labelledby="s15">
<details open>
<summary id="s15">
There is a mechanism to label user input controls in an
unambiguous and clear manner.
</summary>
<p>
When collecting user input, users must know what input is required
for each control. Often this is made evident by visual context,
but this does not help non-visual users or users of alternate
visual presentations such as magnification. When labels are
provided, if they are not programmatically associated with the
control, users may not be able to find the correct label.
Therefore it is important for technologies to provide ways to
associate labels with their controls.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met15" name="met15" value="yes"> Yes</label>
<label><input type="radio" id="met15" name="met15" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s16">
<details open>
<summary id="s16">
Authors can associate extended help information with a control.
</summary>
<p>
When authors request user input that may require special
assistance, such as details of the input format required or how to
find an account number on a bill, they may provide extended help
in addition to the label. Even if this is positioned near the
control, some users may not reliably find it. Therefore
technologies should provide a way for authors to explicitly attach
extended help (including links to extended help) directly to the
control.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met16" name="met16" value="yes"> Yes</label>
<label><input type="radio" id="met16" name="met16" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s17">
<details open>
<summary id="s17">
If there is an input error, it is possible to associate the
error message clearly with the specific control that is in
error.
</summary>
<p>
If a user inputs data that is not accepted by the system, a report
of the issue is made and the user given an opportunity to correct
the input. Such error messages are frequently provided at the top
of the form, from where it can be difficult for the user to locate
the control that needs input corrected. Even if the error message
is positioned closer to the control, it can be difficult to find
the correct control. Therefore, much like labels and help content,
technologies need to provide a way to associate error messages
directly with the control to which they apply.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met17" name="met17" value="yes"> Yes</label>
<label><input type="radio" id="met17" name="met17" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s18">
<details open>
<summary id="s18">
There is a mechanism to report and set the state or value of
controls programmatically.
</summary>
<p>
While much user input is collected using platform input services,
some users use assistive technologies that work better when
interacting programmatically with the content directly,
effectively in an alternate user interface. For this to work,
technologies need to provide a means for assistive technologies to
get and set the nature, state, and value of input controls.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met18" name="met18" value="yes"> Yes</label>
<label><input type="radio" id="met18" name="met18" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s19">
<details open>
<summary id="s19">
Authors can address multiple types of input hardware (keyboard,
pointing device, touch screen, voice recognition, etc.), or the
technology supports hardware-agnostic input methods.
</summary>
<p>
A basic tenet of accessibility is that users should be able to
user input and output hardware that is optimal for them. Some use
alternate versions of familiar hardware, such as
keyboard-compatible and pointing devices, while others use less
widespread types of hardware, such as voice recognition,
single-switch devices, Braille displays, etc. Technologies should
design content input and output methods to be agnostic to the
specific hardware used, and provide application programming
interfaces for supported hardware types such as keyboard and
pointer so other hardware can effectively interact. Technologies
should also emphasize the most hardware-neutral form of authoring
feasible via more abstract events, and when providing
hardware-specific features ensure that multiple types of hardware
can be addressed.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met19" name="met19" value="yes"> Yes</label>
<label><input type="radio" id="met19" name="met19" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s20">
<details open>
<summary id="s20">
User input does not require specific physical characteristics
(e.g., fingerprint readers).
</summary>
<p>
Some user input depends on specific physical characteristics of
users. For instance, early touch screens required users to have a
physical, not a prosthetic, finger, and fingerprint readers also
require users to have a fingerprint. Some users do not have the
ability to interact with such devices. Technologies should not
require specific user characteristics, and should provide
alternate ways to accomplish tasks if such features are provided.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met20" name="met20" value="yes"> Yes</label>
<label><input type="radio" id="met20" name="met20" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s21">
<details open>
<summary id="s21">
Authors can ensure a "meaningful" order of controls exists
regardless of presentation.
</summary>
<p>
Much like the issue of navigation order deviating from display
order mentioned above, control order is another frequent source of
confusion for users when presentation has been customized.
Technologies should provide ways for authors to define the
intended order of user input controls.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met21" name="met21" value="yes"> Yes</label>
<label><input type="radio" id="met21" name="met21" value="no"> No</label>
</td>
</tr>
</tbody>
</table>
</details>
</fieldset>
<fieldset>
<legend>
If technology provides user interaction features
</legend>
<input type="radio" id="q4_yes" name="q4" value="Yes" required aria-describedby="q4Description" checked />
<label for="q4_yes">Yes</label>
<input type="radio" id="q4_no" name="q4" value="No" required aria-describedby="q4Description" />
<label for="q4_no">No</label>
<details>
<summary>
User interaction features checklist
</summary>
<table
role="table"
aria-label="If technology provides user interaction features checklist"
id="table4"
>
<thead>
<tr>
<th scope="col">Checkpoint</th>
<th scope="col">References</th>
<th scope="col">Met?</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row" aria-labelledby="s22">
<details open>
<summary id="s22">
For every user interface object type, the "type" of object can
be exposed as a role to accessibility APIs.
</summary>
<p>
A major way some users with disabilities access content is via
assistive technologies, which provide various supplemental
supports for interaction. Many assistive technologies interact
with content primarily via accessibility APIs, which contain an
abstract model of the content that includes information about each
object. The "type" of an object is important for users to know how
to use it, which is typically exposed to accessibility APIs as a
"role". Technologies should ensure features have a defined type
and, if necessary, document accessibility API mappings for the
several APIs in use.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met22" name="met22" value="yes"> Yes</label>
<label><input type="radio" id="met22" name="met22" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s23">
<details open>
<summary id="s23">
For every user interface object type, there is a clearly defined
mechanism for authors to provide and / or user agents determine
the "accessible name" for accessibility APIs.
</summary>
<p>
Accessibility APIs provide an "accessible name" for each object,
which labels it for the user. The accessible name is frequently
the label for a form control or the text alternative for an
object. Technologies should define how the accessible name for
each object type can be determined, and provide features to allow
authors to set the accessible name.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met23" name="met23" value="yes"> Yes</label>
<label><input type="radio" id="met23" name="met23" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s24">
<details open>
<summary id="s24">
For user interface objects that can have states, properties, or values,
authors can set these and these can be exposed to accessibility APIs.
</summary>
<p>
Along with the role, many objects require information about properties, states, and values to be fully usable.
Properties are generally specific to object types and refine the type of object; states are also specific to
object type and provide information about a changeable condition such as checked status of a checkbox
or visibility status of an object. All objects have values as well, which is often the text content but
can be from another source, such as the user input in a form control. Technologies should define ways
for user agents to expose and authors to set properties, states, and values in accessibility
APIs that are relevant to full understanding of and interaction with the object type.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met24" name="met24" value="yes"> Yes</label>
<label><input type="radio" id="met24" name="met24" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s25">
<details open>
<summary id="s25">
When providing imperative mechanisms to implement technology features (e.g., scripts),
authors can expose accessibility information to accessibility APIs.
</summary>
<p>
Declarative technologies provide structured semantic helping authors to define complete models for
objects that can be exposed to accessibility APIs. Imperative technologies give more freedom to the
author but provide less built-in accessibility semantics, and sometimes do not provide a way to address
accessibility APIs at all. Technologies that use imperative mechanisms to author content need to provide
full interfaces to accessibility APIs so authors can set the complete object model.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met25" name="met25" value="yes"> Yes</label>
<label><input type="radio" id="met25" name="met25" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s26">
<details open>
<summary id="s26">
User can obtain help information about the widget.
</summary>
<p>
Especially with novel widgets, users sometimes need context-specific help to learn how to use the widget effectively.
This information is only useful if users can easily find it. Therefore, technologies should provide a mechanism for
help information to be directly associated with and reachable from the control.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met26" name="met26" value="yes"> Yes</label>
<label><input type="radio" id="met26" name="met26" value="no"> No</label>
</td>
</tr>
</tbody>
</table>
</details>
</fieldset>
<fieldset>
<legend>
If technology defines document semantics
</legend>
<input type="radio" id="q5_yes" name="q5" value="Yes" required aria-describedby="q5Description" checked />
<label for="q5_yes">Yes</label>
<input type="radio" id="q5_no" name="q5" value="No" required aria-describedby="q5Description" />
<label for="q5_no">No</label>
<details>
<summary>
Document semantics checklist
</summary>
<table
role="table"
aria-label="If technology defines document semantics checklist"
id="table5"
>
<thead>
<tr>
<th scope="col">Checkpoint</th>
<th scope="col">References</th>
<th scope="col">Met?</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row" aria-labelledby="s27">
<details open>
<summary id="s27">
Authors can title Web pages.
</summary>
<p>
Web content is classically exposed on "pages", each of which
contains a different chunk of content. To help users easily
identify their location in a set of pages, and navigate to the
correct page, each pages should have a title that is effectively
metadata. Technologies should provide ways for authors to create
unique titles for each page.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met27" name="met27" value="yes"> Yes</label>
<label><input type="radio" id="met27" name="met27" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s28">
<details open>
<summary id="s28">
Authors can title sections of content.
</summary>
<p>
Web content is frequently divided into multiple sections, each of
which has a distinct topic. Users navigate among these sections to
find the content most relevant to their purpose, which is
especially important for users of assistive technology that don't
provide a two-dimensional view of the content. Technologies should
provide a mechanism for authors to provide section titles to help
users navigate and identify their location.
</p>
</details>
</th>
<td></td>
<td class="met-column">
<label><input type="radio" id="met28" name="met28" value="yes"> Yes</label>
<label><input type="radio" id="met28" name="met28" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s29">
<details open>
<summary id="s29">
Authors can clearly indicate the target of a hyperlink and
function of a control.
</summary>
<p>
Hyperlinks and controls cause changes to the user experience. It
is important that users know what change will happen, or what the
result of navigating a hyperlink will be. Default or contextual
indications may be sufficient for some users but not all.
Technologies must provide features allowing authors to
unambiguously provide this information.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met29" name="met29" value="yes"> Yes</label>
<label><input type="radio" id="met29" name="met29" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s30">
<details open>
<summary id="s30">
Authors can indicate content language, for the page as a whole and for blocks of content.
</summary>
<p>
Assistive technology that process language, such as screen readers, braille displays,
and voice input, change according to human language of content. For instance, pronunciation
rules and the effect of certain utterances may change. Technologies need to allow authors
to indicate the language of content, both as a whole and for regions where it differs.
</p>
</details>
</th>
<td> </td>
<td class="met-column">
<label><input type="radio" id="met30" name="met30" value="yes"> Yes</label>
<label><input type="radio" id="met30" name="met30" value="no"> No</label>
</td>
</tr>
<tr>
<th scope="row" aria-labelledby="s31">
<details open>
<summary id="s31">
Authors can support understanding of abbreviations / acronyms / initialisms, idioms, jargon, etc.
</summary>
<p>
Abbreviations, acronyms, initialisms, idioms, and jargon comprise usages of content that
may not be familiar to all users, so it can be helpful for authors to provide supplemental
information about meaning. Abbreviations, acronyms, and initialisms are also often frequently
pronounced different from their spelling, their special nature may not be obvious from pronunciation alone.
Therefore technologies should allow authors to provide pronunciation and meaning guidance for these language features.
</p>
</details>
</th>
<td> </td>
<td class="met-column">