web/ITL_AI-Inclusive-Design-Sprints_icf_exclusions_Windows.html at master · InclusiveTechLab/web · GitHub

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"/>
<title></title>
<style>
    body {font: 1rem/1.1 sans-serif; margin:2rem;}
    h2 {margin-top: 3rem;}
    h3 {font-size:1rem; margin-bottom:0rem;}
    ul {margin-top:0.3rem;}
  </style>
</head>
<body>
<main> <!-- Start editting at line: 400  -->
<!-- 1) Energy and drive functions -->
<article aria-labelledby="energy-and-drive-functions-h" id="energy-and-drive-functions">
<h2 id="energy-and-drive-functions-h">Energy and drive functions</h2>
<p class="icf-label"><b>Other/Context</b> Energy and drive functions</p>
<section aria-labelledby="energy-and-drive-functions-perceivable-h" id="energy-and-drive-functions-perceivable">
<h3 id="energy-and-drive-functions-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Focus Session timers in Clock use small, low-contrast toasts; users with magnification can miss break cues.</li>
<li data-principle="perceivable">Taskbar progress overlays (e.g., downloads) are subtle and color-only; color filters/grayscale hide state.</li>
<li data-principle="perceivable">Lock screen's rotating background can cause visual fatigue; no simple toggle for a static image during focus.</li>
</ul>
</section>
<section aria-labelledby="energy-and-drive-functions-operable-h" id="energy-and-drive-functions-operable">
<h3 id="energy-and-drive-functions-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Long troubleshooters time out without an "extend" option; keyboard-only or switch users may abandon.</li>
<li data-principle="operable">Cumulative updates sometimes require multiple restarts; sustaining attention/energy across cycles is hard.</li>
<li data-principle="operable">Battery-saver prompts appear late in workflow; fatigued users may not complete shutdown sequences.</li>
</ul>
</section>
<section aria-labelledby="energy-and-drive-functions-understandable-h" id="energy-and-drive-functions-understandable">
<h3 id="energy-and-drive-functions-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Windows Update messages vary in tone and surface (toast vs. Settings); effort/duration is hard to gauge.</li>
<li data-principle="understandable">Battery performance modes use vague terms ("Balanced", "Best performance") without energy impact context.</li>
</ul>
</section>
<section aria-labelledby="energy-and-drive-functions-robust-h" id="energy-and-drive-functions-robust">
<h3 id="energy-and-drive-functions-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Focus Session state isn't consistently exposed for AT to announce remaining time/breaks.</li>
<li data-principle="robust">Performance overlays conflict with battery notifications, duplicating or contradicting signals.</li>
</ul>
</section>
</article>
<!-- 2) Sound discrimination -->
<article aria-labelledby="sound-discrimination-h" id="sound-discrimination">
<h2 id="sound-discrimination-h">Sound discrimination</h2>
<p class="icf-label"><b>Hearing</b> Sound discrimination</p>
<section aria-labelledby="sound-discrimination-perceivable-h" id="sound-discrimination-perceivable">
<h3 id="sound-discrimination-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">System notification and error chimes share similar pitch/envelope; urgency is hard to tell by sound alone.</li>
<li data-principle="perceivable">Audio Devices auto-switch lacks synchronized visual cues; device changes are missed by deaf/HoH users.</li>
<li data-principle="perceivable">Service alerts (e.g., deprecations) reuse generic tones; auditory differentiation is impossible.</li>
<li data-principle="perceivable">Startup and error sounds play from same channel; no directional cue for unilateral hearing loss.</li>
</ul>
</section>
<section aria-labelledby="sound-discrimination-operable-h" id="sound-discrimination-operable">
<h3 id="sound-discrimination-operable-h">Operable</h3>
<ul>
<li data-principle="operable">When Bluetooth audio switches, there's no caption/notification; users can't confirm device routing.</li>
</ul>
</section>
<section aria-labelledby="sound-discrimination-understandable-h" id="sound-discrimination-understandable">
<h3 id="sound-discrimination-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Per-app volume mixer concepts (system vs. app vs. input) aren't labeled plainly.</li>
<li data-principle="understandable">Sound themes are abstractly named ("Default", "Sonata"); users can't infer cue semantics.</li>
<li data-principle="understandable">Audio troubleshooting uses device IDs, not friendly names; repair steps are unclear.</li>
</ul>
</section>
</article>
<!-- 3) Managing one's own behavior -->
<article aria-labelledby="managing-ones-own-behavior-h" id="managing-ones-own-behavior">
<h2 id="managing-ones-own-behavior-h">Managing one's own behavior</h2>
<p class="icf-label"><b>Cognition</b> Managing one's own behavior</p>
<section aria-labelledby="managing-ones-own-behavior-perceivable-h" id="managing-ones-own-behavior-perceivable">
<h3 id="managing-ones-own-behavior-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Widget notifications surface behind full-screen apps without persistent indicators.</li>
<li data-principle="perceivable">Focus Assist banners appear only momentarily; users needing extra time miss cues.</li>
</ul>
</section>
<section aria-labelledby="managing-ones-own-behavior-operable-h" id="managing-ones-own-behavior-operable">
<h3 id="managing-ones-own-behavior-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Focus mode toggles differ in Clock vs. Quick Settings; muscle memory fails across surfaces.</li>
<li data-principle="operable">Windows tips may reopen after dismissal; repeated interruptions disrupt routines.</li>
</ul>
</section>
<section aria-labelledby="managing-ones-own-behavior-understandable-h" id="managing-ones-own-behavior-understandable">
<h3 id="managing-ones-own-behavior-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Settings alternates "Notifications", "Banners", and "Alerts"; control concepts blur.</li>
<li data-principle="understandable">Performance recommendations use ambiguous wording ("may improve"); outcomes unclear.</li>
</ul>
</section>
<section aria-labelledby="managing-ones-own-behavior-robust-h" id="managing-ones-own-behavior-robust">
<h3 id="managing-ones-own-behavior-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Focus/Do Not Disturb state isn't consistently exposed to companion apps for routine support.</li>
<li data-principle="robust">Disabling Notification Center via registry blocks accessibility tools from retrieving alerts.</li>
<li data-principle="robust">Cross-device sync duplicates alerts; routine management becomes inconsistent across surfaces.</li>
</ul>
</section>
</article>
<!-- 4) Articulation of consonants -->
<article aria-labelledby="articulation-of-consonants-h" id="articulation-of-consonants">
<h2 id="articulation-of-consonants-h">Articulation of consonants</h2>
<p class="icf-label"><b>Speech</b> Articulation of consonants</p>
<section aria-labelledby="articulation-of-consonants-perceivable-h" id="articulation-of-consonants-perceivable">
<h3 id="articulation-of-consonants-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Voice typing confirmation tones are subtle; users can't tell when dictation begins/ends.</li>
<li data-principle="perceivable">Voice access status text is small; users with mixed speech/visual impairment can't verify mode.</li>
</ul>
</section>
<section aria-labelledby="articulation-of-consonants-operable-h" id="articulation-of-consonants-operable">
<h3 id="articulation-of-consonants-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Dictation bar requires mouse for punctuation; verbal-only users must spell every mark.</li>
<li data-principle="operable">Speech profiles don't migrate with MS account; re-training needed after device change.</li>
</ul>
</section>
<section aria-labelledby="articulation-of-consonants-understandable-h" id="articulation-of-consonants-understandable">
<h3 id="articulation-of-consonants-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Error copy cites device/privacy issues but lacks concrete repair steps.</li>
<li data-principle="understandable">Error text uses technical phrasing ("speech service unavailable"); plain tips absent.</li>
</ul>
</section>
<section aria-labelledby="articulation-of-consonants-robust-h" id="articulation-of-consonants-robust">
<h3 id="articulation-of-consonants-robust-h">Robust</h3>
<ul>
<li data-principle="robust">AT can't request alternative modalities (e.g., auto-open OSK) when speech confidence is low.</li>
<li data-principle="robust">Voice access logs aren't exposed to AT; users can't audit failed attempts for patterns.</li>
</ul>
</section>
</article>
<!-- 5) Parietal lobe (spatial / attention) -->
<article aria-labelledby="parietal-lobe-h" id="parietal-lobe">
<h2 id="parietal-lobe-h">Parietal lobe</h2>
<p class="icf-label"><b>Cognition</b> Parietal lobe</p>
<section aria-labelledby="parietal-lobe-perceivable-h" id="parietal-lobe-perceivable">
<h3 id="parietal-lobe-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Snap layouts rely on hover near window buttons; affordances are missed with spatial attention issues.</li>
<li data-principle="perceivable">Virtual Desktop thumbnails are small; magnifier users can't distinguish contexts without labels.</li>
</ul>
</section>
<section aria-labelledby="parietal-lobe-operable-h" id="parietal-lobe-operable">
<h3 id="parietal-lobe-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Drag-and-drop in File Explorer demands precise placement; keyboard reordering is inconsistent.</li>
<li data-principle="operable">Multi-monitor Arrange requires fine pointer control; keyboard-only repositioning is unclear.</li>
</ul>
</section>
<section aria-labelledby="parietal-lobe-understandable-h" id="parietal-lobe-understandable">
<h3 id="parietal-lobe-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">"Pin to taskbar" vs. "Pin to Start" is unclear; users misplace programs.</li>
<li data-principle="understandable">Virtual Desktop names don't persist; context for task switching is lost.</li>
</ul>
</section>
<section aria-labelledby="parietal-lobe-robust-h" id="parietal-lobe-robust">
<h3 id="parietal-lobe-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Assistive overlays can't query desktop thumbnails via secure compositor; location awareness drops.</li>
<li data-principle="robust">Custom shell replacements misreport window positions; overlays can't anchor accurately.</li>
</ul>
</section>
</article>
<!-- 6) Frontal lobe (planning / executive function) -->
<article aria-labelledby="frontal-lobe-h" id="frontal-lobe">
<h2 id="frontal-lobe-h">Frontal lobe</h2>
<p class="icf-label"><b>Cognition</b> Frontal lobe</p>
<section aria-labelledby="frontal-lobe-perceivable-h" id="frontal-lobe-perceivable">
<h3 id="frontal-lobe-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">"Finish setting up device" banner blends with background; onboarding is forgotten.</li>
</ul>
</section>
<section aria-labelledby="frontal-lobe-operable-h" id="frontal-lobe-operable">
<h3 id="frontal-lobe-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Hello recovery repeats identity confirmations; progress is lost across restarts.</li>
<li data-principle="operable">Nested Settings categories require many clicks; task completion strains planning.</li>
</ul>
</section>
<section aria-labelledby="frontal-lobe-understandable-h" id="frontal-lobe-understandable">
<h3 id="frontal-lobe-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Multi-step flows (BitLocker, Storage Spaces) hide prerequisites; users can't plan.</li>
<li data-principle="understandable">Update channels (stable/beta/dev) aren't contrasted plainly; stability tradeoffs unclear.</li>
<li data-principle="understandable">Backup options mix File History and OneDrive terms; scope of protection is unclear.</li>
</ul>
</section>
<section aria-labelledby="frontal-lobe-robust-h" id="frontal-lobe-robust">
<h3 id="frontal-lobe-robust-h">Robust</h3>
<ul>
<li data-principle="robust">AT querying dialog focus can return stale handles; navigation order is unreliable.</li>
<li data-principle="robust">Legacy MMC tools don't expose semantic roles; automation can't convey hierarchy.</li>
</ul>
</section>
</article>
<!-- 7) Hand and arm use -->
<article aria-labelledby="hand-and-arm-use-h" id="hand-and-arm-use">
<h2 id="hand-and-arm-use-h">Hand and arm use</h2>
<p class="icf-label"><b>Mobility</b> Hand and arm use</p>
<section aria-labelledby="hand-and-arm-use-perceivable-h" id="hand-and-arm-use-perceivable">
<h3 id="hand-and-arm-use-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Resize handles in Explorer panes/splitters are narrow; grab area isn't perceived with magnification.</li>
<li data-principle="perceivable">Icon spacing in Explorer is dense; large cursors cause mis-targeting.</li>
</ul>
</section>
<section aria-labelledby="hand-and-arm-use-operable-h" id="hand-and-arm-use-operable">
<h3 id="hand-and-arm-use-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Gesture-only actions (three-finger trackpad, back swipes) lack keyboard parity in some shells.</li>
<li data-principle="operable">Closing notifications via tiny "X" needs fine control; keyboard dismissal isn't advertised.</li>
</ul>
</section>
<section aria-labelledby="hand-and-arm-use-understandable-h" id="hand-and-arm-use-understandable">
<h3 id="hand-and-arm-use-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Pen/Ink settings use technical terms ("palm rejection", "hover"); mapping to outcomes is unclear.</li>
<li data-principle="understandable">Mouse Keys vs. Sticky Keys vs. Filter Keys aren't contrasted; wrong motor aid is chosen.</li>
<li data-principle="understandable">Pointer speed vs. precision settings are separated; users misconfigure expecting one control.</li>
</ul>
</section>
<section aria-labelledby="hand-and-arm-use-robust-h" id="hand-and-arm-use-robust">
<h3 id="hand-and-arm-use-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Full-screen apps can capture mouse, blocking AT from generating synthetic clicks reliably.</li>
<li data-principle="robust">HID remapping via third-party drivers conflicts with accessibility hooks; AT can't intercept.</li>
</ul>
</section>
</article>
<!-- 8) Looking after one's health -->
<article aria-labelledby="looking-after-ones-health-h" id="looking-after-ones-health">
<h2 id="looking-after-ones-health-h">Looking after one's health</h2>
<p class="icf-label"><b>Other/Context</b> Looking after one's health</p>
<section aria-labelledby="looking-after-ones-health-perceivable-h" id="looking-after-ones-health-perceivable">
<h3 id="looking-after-ones-health-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Accessibility shortcuts (Win+U) list is dense with limited grouping; relevant features are overlooked.</li>
<li data-principle="perceivable">Windows Security health banner uses small, icon-only indicators; risks aren't noticed quickly.</li>
</ul>
</section>
<section aria-labelledby="looking-after-ones-health-operable-h" id="looking-after-ones-health-operable">
<h3 id="looking-after-ones-health-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Windows Update restarts may schedule without an accessible snooze in keyboard-only flow.</li>
<li data-principle="operable">Magnifier reading mode cannot toggle while modal dialogs are open; users lose access mid-task.</li>
</ul>
</section>
<section aria-labelledby="looking-after-ones-health-understandable-h" id="looking-after-ones-health-understandable">
<h3 id="looking-after-ones-health-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Privacy &amp; Security health checks list issues without prioritization; users can't tell what to fix first.</li>
<li data-principle="understandable">Update health recommendations use jargon ("servicing stack"); plain-language summaries are missing.</li>
</ul>
</section>
<section aria-labelledby="looking-after-ones-health-robust-h" id="looking-after-ones-health-robust">
<h3 id="looking-after-ones-health-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Some Windows Security reports export as unstructured images; data is not programmatic.</li>
<li data-principle="robust">Reliability Monitor CSV exports lack headers; AT parsing and auditing are impeded.</li>
</ul>
</section>
</article>
<!-- Retrieval of memory -->
<article aria-labelledby="retrieval-of-memory-h" id="retrieval-of-memory">
<h2 id="retrieval-of-memory-h">Retrieval of memory</h2>
<p class="icf-label"><b>Cognition</b> Retrieval of memory</p>
<section aria-labelledby="retrieval-of-memory-perceivable-h" id="retrieval-of-memory-perceivable">
<h3 id="retrieval-of-memory-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Clipboard history previews truncate text without tooltips; users can't perceive which entry to recall.</li>
<li data-principle="perceivable">Notification history hides older toasts behind small chevrons; past cues needed for recall are visually buried.</li>
</ul>
</section>
<section aria-labelledby="retrieval-of-memory-operable-h" id="retrieval-of-memory-operable">
<h3 id="retrieval-of-memory-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Keyboard navigation of "Quick Access" and "Recent" lists is inconsistent across dialogs; users can't efficiently re-open prior items.</li>
<li data-principle="operable">Win+V Clipboard history requires precise focus management; switch users lose context when entries close on selection.</li>
</ul>
</section>
<section aria-labelledby="retrieval-of-memory-understandable-h" id="retrieval-of-memory-understandable">
<h3 id="retrieval-of-memory-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Similar icons and names across MRU items (e.g., multiple "Document1") lack disambiguating metadata like path or last action.</li>
<li data-principle="understandable">Search Scope labels ("All", "Apps", "Documents", "Web") are not explained; users misinterpret where results come from.</li>
<li data-principle="understandable">Clipboard history uses terse labels; users can't predict how pinned items persist across reboots.</li>
</ul>
</section>
<section aria-labelledby="retrieval-of-memory-robust-h" id="retrieval-of-memory-robust">
<h3 id="retrieval-of-memory-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Search indexer pauses under power-saving rules without signaling to AT; recall features silently degrade.</li>
<li data-principle="robust">Cloud-backed recents (OneDrive/SharePoint) fail offline; fallback metadata isn't exposed for AT to announce.</li>
<li data-principle="robust">Notification Center history isn't consistently exposed via automation; AT cannot retrieve prior toasts on demand.</li>
</ul>
</section>
</article>
<!-- Psychomotor functions -->
<article aria-labelledby="psychomotor-functions-h" id="psychomotor-functions">
<h2 id="psychomotor-functions-h">Psychomotor functions</h2>
<p class="icf-label"><b>Mobility</b> Psychomotor functions</p>
<section aria-labelledby="psychomotor-functions-perceivable-h" id="psychomotor-functions-perceivable">
<h3 id="psychomotor-functions-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Pointer trails and cursor size previews are small; users can't perceive motion assistance effects before applying.</li>
<li data-principle="perceivable">Touch targets for title bar controls are compact; hit areas aren't clearly delineated at high DPI.</li>
<li data-principle="perceivable">Double-click speed test UI provides limited visual feedback; users can't perceive timing success/failure.</li>
</ul>
</section>
<section aria-labelledby="psychomotor-functions-operable-h" id="psychomotor-functions-operable">
<h3 id="psychomotor-functions-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Hold-to-drag thresholds and window resize corners require fine control; one-switch or head-pointer users can't operate reliably.</li>
<li data-principle="operable">Context menus close on minor pointer jitter; tremor makes activation and selection unreliable.</li>
<li data-principle="operable">Touchpad three-finger gestures invoke global actions accidentally; disabling per-gesture requires deep settings navigation.</li>
</ul>
</section>
<section aria-labelledby="psychomotor-functions-understandable-h" id="psychomotor-functions-understandable">
<h3 id="psychomotor-functions-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">"Enhance pointer precision" label doesn't explain acceleration; users misconfigure for fine motor control.</li>
<li data-principle="understandable">Gesture nomenclature ("tap-and-hold", "press-and-hold", "drag") is inconsistent across tutorials.</li>
</ul>
</section>
<section aria-labelledby="psychomotor-functions-robust-h" id="psychomotor-functions-robust">
<h3 id="psychomotor-functions-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Custom HID drivers override system mappings; AT cannot reliably intercept or synthesize input events.</li>
<li data-principle="robust">Some legacy dialogs don't honor system pointer size; visual affordances for motor targeting disappear.</li>
<li data-principle="robust">Per-app high-DPI behavior breaks consistent hit testing; automation coordinates reported to AT are inaccurate.</li>
<li data-principle="robust">Secure desktops (UAC/lock) restrict OSK and AT invocation; motor accommodations drop at critical moments.</li>
</ul>
</section>
</article>
<!-- Emotional functions -->
<article aria-labelledby="emotional-functions-h" id="emotional-functions">
<h2 id="emotional-functions-h">Emotional functions</h2>
<p class="icf-label"><b>Cognition</b> Emotional functions</p>
<section aria-labelledby="emotional-functions-perceivable-h" id="emotional-functions-perceivable">
<h3 id="emotional-functions-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Error states use red and motion without alternative cues; users experiencing anxiety miss the actual message.</li>
<li data-principle="perceivable">Urgent toasts overlap with other banners; critical context is occluded during heightened arousal.</li>
<li data-principle="perceivable">Full-screen warnings dim the background heavily; content contrast becomes too low for accurate reading.</li>
<li data-principle="perceivable">Security badge icons are small; users can't perceive severity differences at a glance.</li>
</ul>
</section>
<section aria-labelledby="emotional-functions-operable-h" id="emotional-functions-operable">
<h3 id="emotional-functions-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Timed dialogs (e.g., restart countdowns) lack a clear "pause/snooze"; users under stress can't act in time.</li>
<li data-principle="operable">SmartScreen/UAC steal focus unexpectedly; keyboard users activate default actions by mistake.</li>
<li data-principle="operable">Critical notifications stack behind modals; reaching the right control requires complex focus recovery.</li>
<li data-principle="operable">High-salience sounds can't be muted independently from other cues; startle responses impair operation.</li>
</ul>
</section>
<section aria-labelledby="emotional-functions-understandable-h" id="emotional-functions-understandable">
<h3 id="emotional-functions-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Alarmist copy ("Act now") appears without context; users can't assess real risk.</li>
<li data-principle="understandable">Mixed terminology ("threat", "issue", "recommendation") lacks definitions; severity isn't clear.</li>
<li data-principle="understandable">Error dialogs suggest multiple unrelated fixes; users can't choose a first step.</li>
<li data-principle="understandable">Restart prompts don't estimate duration; uncertainty elevates stress and avoidance.</li>
</ul>
</section>
<section aria-labelledby="emotional-functions-robust-h" id="emotional-functions-robust">
<h3 id="emotional-functions-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Assistive technologies can't prioritize or filter high-stress alerts via a consistent severity taxonomy.</li>
<li data-principle="robust">Security notifications arrive via multiple channels (toasts, Action Center, banners) without de-duplication signals for AT.</li>
<li data-principle="robust">Some warning banners are bitmaps in WebView content; AT cannot parse the underlying structure.</li>
<li data-principle="robust">Programmatic hooks for countdown timers are inconsistent; AT can't announce remaining time reliably.</li>
</ul>
</section>
</article>
<!-- Regulation of emotion -->
<article aria-labelledby="regulation-of-emotion-h" id="regulation-of-emotion">
<h2 id="regulation-of-emotion-h">Regulation of emotion</h2>
<p class="icf-label"><b>Cognition</b> Regulation of emotion</p>
<section aria-labelledby="regulation-of-emotion-perceivable-h" id="regulation-of-emotion-perceivable">
<h3 id="regulation-of-emotion-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Notifications about failures (sync, backup) lack persistent indicators; users can't pace responses or return later.</li>
<li data-principle="perceivable">Auto-playing instructional videos in Settings draw attention away from self-calming strategies.</li>
<li data-principle="perceivable">High-motion UI during restore/reset keeps animating; users can't maintain emotional focus on steps.</li>
<li data-principle="perceivable">Color-only severity cues (yellow vs. red) are subtle in some themes; stress signals are misread.</li>
</ul>
</section>
<section aria-labelledby="regulation-of-emotion-operable-h" id="regulation-of-emotion-operable">
<h3 id="regulation-of-emotion-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Update countdowns and forced restarts offer limited snooze ranges; users can't defer until calm/focused.</li>
<li data-principle="operable">Do Not Disturb toggles reset after reboots; users lose protective buffers they rely on.</li>
<li data-principle="operable">Toast groups can't be batch-dismissed with a single keyboard action; clutter sustains arousal.</li>
<li data-principle="operable">Live Captions window steals focus when undocking/redocking; regaining control adds frustration.</li>
</ul>
</section>
<section aria-labelledby="regulation-of-emotion-understandable-h" id="regulation-of-emotion-understandable">
<h3 id="regulation-of-emotion-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Security recommendations lack a calming "safe path" summary; users ruminate on worst-case outcomes.</li>
<li data-principle="understandable">Multiple settings influence interruptions (Focus, Priority, App permissions); guidance for a single quiet state is missing.</li>
<li data-principle="understandable">Language in recovery flows warns of data loss without graded scenarios; users avoid necessary repairs.</li>
<li data-principle="understandable">Error messages omit estimated effort; users can't plan micro-breaks to regulate emotions during fixes.</li>
</ul>
</section>
<section aria-labelledby="regulation-of-emotion-robust-h" id="regulation-of-emotion-robust">
<h3 id="regulation-of-emotion-robust-h">Robust</h3>
<ul>
<li data-principle="robust">AT cannot subscribe to a unified "quiet mode" signal across OS surfaces; regulation strategies don't propagate.</li>
<li data-principle="robust">Some apps bypass Focus/Do Not Disturb via legacy APIs; emotional buffers fail unpredictably.</li>
<li data-principle="robust">Programmatic labels for alert severity vary by subsystem; AT can't consistently down-rank low-risk messages.</li>
<li data-principle="robust">Exported logs (reliability, updates) lack machine-readable cause?fix mapping; coaching agents can't scaffold de-escalation.</li>
</ul>
</section>
</article>
<!-- Visuospatial perception -->
<article aria-labelledby="visuospatial-perception-h" id="visuospatial-perception">
<h2 id="visuospatial-perception-h">Visuospatial perception</h2>
<p class="icf-label"><b>Cognition</b> Visuospatial perception</p>
<section aria-labelledby="visuospatial-perception-perceivable-h" id="visuospatial-perception-perceivable">
<h3 id="visuospatial-perception-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Snap layout guides appear near tiny window controls; users miss spatial options when relying on magnifier.</li>
<li data-principle="perceivable">Taskbar overflow tray uses compact icon-only items; relative positions are hard to perceive at high DPI.</li>
<li data-principle="perceivable">Virtual desktop indicators rely on faint bottom bars; active context is easy to misread.</li>
<li data-principle="perceivable">Multiple monitor edges show minimal visual anchors for dragging; screen boundaries are unclear.</li>
</ul>
</section>
<section aria-labelledby="visuospatial-perception-operable-h" id="visuospatial-perception-operable">
<h3 id="visuospatial-perception-operable-h">Operable</h3>
<ul>
<li data-principle="operable">File Explorer drag-and-drop requires precise hit targets between folders; users misplace items.</li>
<li data-principle="operable">Window resizing on thin borders demands accurate cursor placement; tremor or neglect impairs operation.</li>
<li data-principle="operable">Arrange Displays requires dragging monitor thumbnails to match physical layout; keyboard alternative is obscure.</li>
<li data-principle="operable">Grid snapping positions differ across mixed-DPI displays; predictable geometry breaks.</li>
</ul>
</section>
<section aria-labelledby="visuospatial-perception-understandable-h" id="visuospatial-perception-understandable">
<h3 id="visuospatial-perception-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Icon meaning vs. app instance (pinned vs. running) on the taskbar isn't clearly differentiated; users lose spatial mapping.</li>
<li data-principle="understandable">Folder grouping and sort order visuals can conflict; users can't infer where a moved file will appear.</li>
<li data-principle="understandable">Snap groups vs. individual windows aren't labeled plainly; layouts are mistaken for separate apps.</li>
<li data-principle="understandable">Display scaling warnings are terse; users don't understand why UI elements appear misaligned.</li>
</ul>
</section>
<section aria-labelledby="visuospatial-perception-robust-h" id="visuospatial-perception-robust">
<h3 id="visuospatial-perception-robust-h">Robust</h3>
<ul>
<li data-principle="robust">AT cannot consistently enumerate snap groups and their screen coordinates; spatial structures aren't exposed programmatically.</li>
<li data-principle="robust">Legacy apps render non-client areas differently; automation hit-testing for borders is unreliable.</li>
<li data-principle="robust">Secure desktop surfaces (UAC/lock) suppress custom pointers; spatial orientation aids disappear.</li>
<li data-principle="robust">High-DPI per-monitor awareness varies by app; reported bounds to AT don't match visual positions.</li>
</ul>
</section>
</article>
<!-- Pace of thought -->
<article aria-labelledby="pace-of-thought-h" id="pace-of-thought">
<h2 id="pace-of-thought-h">Pace of thought</h2>
<p class="icf-label"><b>Cognition</b> Pace of thought</p>
<section aria-labelledby="pace-of-thought-perceivable-h" id="pace-of-thought-perceivable">
<h3 id="pace-of-thought-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Transient system toasts auto-dismiss quickly; users who need more processing time miss key information.</li>
<li data-principle="perceivable">Loading indicators are minimal in Settings; users can't perceive when it's safe to proceed.</li>
<li data-principle="perceivable">Auto-advancing OOBE screens animate forward; longer processing time users lose content.</li>
<li data-principle="perceivable">Live Captions small "connected"/"disconnected" status text is easy to miss during setup.</li>
</ul>
</section>
<section aria-labelledby="pace-of-thought-operable-h" id="pace-of-thought-operable">
<h3 id="pace-of-thought-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Restart countdowns allow limited snooze choices; users can't defer until they're ready.</li>
<li data-principle="operable">Timed authentication prompts (Hello/OTP) expire mid-navigation; keyboard-only users can't respond in time.</li>
<li data-principle="operable">Installers lock UI during checks; pause/resume is unavailable for paced task execution.</li>
<li data-principle="operable">Automatic focus shifts (e.g., dialog steals focus) break step-by-step pacing strategies.</li>
</ul>
</section>
<section aria-labelledby="pace-of-thought-understandable-h" id="pace-of-thought-understandable">
<h3 id="pace-of-thought-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Complex flows (BitLocker, Storage Spaces) lack up-front time/effort estimates; planning is hard.</li>
<li data-principle="understandable">"Processing" messages don't say what's happening; users can't anticipate next steps.</li>
<li data-principle="understandable">Update terminology ("cumulative", "feature", "quality") isn't explained; decision-making slows.</li>
<li data-principle="understandable">Settings surfaces change section names between versions; learned pathways no longer map.</li>
</ul>
</section>
<section aria-labelledby="pace-of-thought-robust-h" id="pace-of-thought-robust">
<h3 id="pace-of-thought-robust-h">Robust</h3>
<ul>
<li data-principle="robust">AT can't query toast remaining time; tools can't extend/hold notifications for slow processing.</li>
<li data-principle="robust">Some progress UIs are bitmap-only; AT can't read stage counts or durations.</li>
<li data-principle="robust">Power policies throttle indexer/services unpredictably; assistive reminders fall behind real time.</li>
<li data-principle="robust">Modal system surfaces (UAC/lock) block task automation; pacing assistance can't continue.</li>
</ul>
</section>
</article>
<!-- Higher-level cognitive functions -->
<article aria-labelledby="higher-level-cognitive-functions-h" id="higher-level-cognitive-functions">
<h2 id="higher-level-cognitive-functions-h">Higher-level cognitive functions</h2>
<p class="icf-label"><b>Cognition</b> Higher-level cognitive functions</p>
<section aria-labelledby="higher-level-cognitive-functions-perceivable-h" id="higher-level-cognitive-functions-perceivable">
<h3 id="higher-level-cognitive-functions-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Task Manager uses dense tables by default; executive function users can't perceive priorities quickly.</li>
<li data-principle="perceivable">Security &amp; privacy settings split across multiple pages; critical controls lack visual prominence.</li>
<li data-principle="perceivable">Policy notifications in Settings appear as small banners; governance impact isn't noticeable.</li>
<li data-principle="perceivable">App permission prompts use tiny toggles; implications aren't visually emphasized.</li>
</ul>
</section>
<section aria-labelledby="higher-level-cognitive-functions-operable-h" id="higher-level-cognitive-functions-operable">
<h3 id="higher-level-cognitive-functions-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Switching between multiple administrative tools (MMC, Settings, Control Panel) requires context juggling.</li>
<li data-principle="operable">Group Policy/Registry edits demand precise sequences; mis-clicks cause wide-ranging effects.</li>
<li data-principle="operable">Managing notifications per-app demands repetitive navigation; no batch operations for common strategies.</li>
<li data-principle="operable">Window focus changes when new admin prompts appear; keyboard users lose their place.</li>
</ul>
</section>
<section aria-labelledby="higher-level-cognitive-functions-understandable-h" id="higher-level-cognitive-functions-understandable">
<h3 id="higher-level-cognitive-functions-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Advanced options (Hyper-V, WSL, virtualization) are jargon-heavy; users can't map to real tasks.</li>
<li data-principle="understandable">Security recommendations don't rank by impact/effort; prioritization is guesswork.</li>
<li data-principle="understandable">Multiple backup paradigms (OneDrive, File History, system image) lack a single mental model.</li>
<li data-principle="understandable">Task Manager "Efficiency mode" and "Power usage trend" lack clear relationships; reasoning is difficult.</li>
</ul>
</section>
<section aria-labelledby="higher-level-cognitive-functions-robust-h" id="higher-level-cognitive-functions-robust">
<h3 id="higher-level-cognitive-functions-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Automation hooks differ across Settings/Control Panel/MMC; AT can't deliver consistent guidance.</li>
<li data-principle="robust">Some admin surfaces render as custom UI without roles; screen readers can't parse structures.</li>
<li data-principle="robust">Policy-driven states aren't always exposed programmatically; companion coaching apps can't adapt.</li>
<li data-principle="robust">Exported reports (e.g., security) lack machine-readable severity; external tools can't synthesize a plan.</li>
</ul>
</section>
</article>
<!-- Organization and planning -->
<article aria-labelledby="organization-and-planning-h" id="organization-and-planning">
<h2 id="organization-and-planning-h">Organization and planning</h2>
<p class="icf-label"><b>Cognition</b> Organization and planning</p>
<section aria-labelledby="organization-and-planning-perceivable-h" id="organization-and-planning-perceivable">
<h3 id="organization-and-planning-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Start menu groups "Recommended" items without category cues; planning next steps is hard to perceive.</li>
<li data-principle="perceivable">Settings breadcrumbs are small and truncated; users lose sense of location within a plan.</li>
<li data-principle="perceivable">Taskbar badges overlap icons; outstanding work isn't visually prioritized.</li>
<li data-principle="perceivable">File Explorer's "Home" view mixes content types; planning workflows from a single hub is confusing.</li>
</ul>
</section>
<section aria-labelledby="organization-and-planning-operable-h" id="organization-and-planning-operable">
<h3 id="organization-and-planning-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Pinning/unpinning apps requires multiple locations (Start/Taskbar/All apps); maintaining an organized workspace is tedious.</li>
<li data-principle="operable">Renaming and reordering virtual desktops needs several steps; keyboard workflows aren't obvious.</li>
<li data-principle="operable">Scheduling restart times for updates opens separate surfaces; cohesive planning is interrupted.</li>
<li data-principle="operable">Focus/Quiet hours rules require navigating multiple panes; batch configuration is missing.</li>
</ul>
</section>
<section aria-labelledby="organization-and-planning-understandable-h" id="organization-and-planning-understandable">
<h3 id="organization-and-planning-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Start pin recommendations don't explain rationale; users can't predict what belongs in their plan.</li>
<li data-principle="understandable">"Apps for websites" and default apps settings overlap; mapping tasks to handlers is unclear.</li>
<li data-principle="understandable">Taskbar multi-instance grouping rules aren't documented; users lose planned window arrangements.</li>
<li data-principle="understandable">Storage cleanup recommendations lack effort and risk estimates; sequencing actions is guesswork.</li>
</ul>
</section>
<section aria-labelledby="organization-and-planning-robust-h" id="organization-and-planning-robust">
<h3 id="organization-and-planning-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Programmatic access to Start layout varies by edition/policy; planning tools can't maintain consistency.</li>
<li data-principle="robust">Some shell states (pinned apps, snap groups) aren't exposed with stable IDs; external organizers can't sync.</li>
<li data-principle="robust">Calendar/clock integrations surface via different APIs; AT can't aggregate schedules reliably.</li>
<li data-principle="robust">Notification scheduling metadata isn't standardized; assistants can't coordinate across apps.</li>
</ul>
</section>
</article>
<!-- Reception of language -->
<article aria-labelledby="reception-of-language-h" id="reception-of-language">
<h2 id="reception-of-language-h">Reception of language</h2>
<p class="icf-label"><b>Communication</b> Reception of language</p>
<section aria-labelledby="reception-of-language-perceivable-h" id="reception-of-language-perceivable">
<h3 id="reception-of-language-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Live Captions uses small status and speaker labels; users miss who is speaking in multi-source audio.</li>
<li data-principle="perceivable">Narrator default speech rate and punctuation verbosity make long dialogs hard to parse on first exposure.</li>
<li data-principle="perceivable">In Settings, explanatory text blends with interactive text; readers can't distinguish instructions from actions.</li>
<li data-principle="perceivable">Region/language indicators in the taskbar language switcher are two-letter codes; low-vision users misread the active input language.</li>
</ul>
</section>
<section aria-labelledby="reception-of-language-operable-h" id="reception-of-language-operable">
<h3 id="reception-of-language-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Changing display language requires multiple restarts/logouts; users relying on translated UI can't operate interim steps.</li>
<li data-principle="operable">Captions windows don't always remember position/size across sessions; users must repeatedly adjust to read comfortably.</li>
<li data-principle="operable">Text-to-speech voices can't be switched quickly from the screen; deep navigation interrupts comprehension strategies.</li>
<li data-principle="operable">The IME/keyboard language flyout closes on minor focus changes; keyboard-only users lose access to language toggles mid-task.</li>
</ul>
</section>
<section aria-labelledby="reception-of-language-understandable-h" id="reception-of-language-understandable">
<h3 id="reception-of-language-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Settings labels mix "language", "region", "locale", and "speech" without plain guidance; users can't predict which affects UI text.</li>
<li data-principle="understandable">Live Captions doesn't surface accuracy caveats (e.g., domain terms); users misinterpret critical information.</li>
<li data-principle="understandable">Narrator verbosity presets aren't described with outcomes (e.g., "concise for dialogs"); trial-and-error is required.</li>
<li data-principle="understandable">The difference between display language and app language is not explained; users expect all apps to switch automatically.</li>
</ul>
</section>
<section aria-labelledby="reception-of-language-robust-h" id="reception-of-language-robust">
<h3 id="reception-of-language-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Caption APIs expose text but limited context (speaker/source); third-party AT can't provide full comprehension aids.</li>
<li data-principle="robust">Some UWP/Win32 apps ignore system language settings; mixed-language UIs break comprehension flow.</li>
<li data-principle="robust">Offline TTS voice fallback is inconsistent; comprehension aids fail when connectivity is restricted.</li>
<li data-principle="robust">Programmatic events for language change are inconsistent across shells; AT can't reliably re-announce new UI language.</li>
</ul>
</section>
</article>
<!-- Expression of language -->
<article aria-labelledby="expression-of-language-h" id="expression-of-language">
<h2 id="expression-of-language-h">Expression of language</h2>
<p class="icf-label"><b>Communication</b> Expression of language</p>
<section aria-labelledby="expression-of-language-perceivable-h" id="expression-of-language-perceivable">
<h3 id="expression-of-language-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Voice typing start/stop indicators are subtle; users can't perceive when text entry is live.</li>
<li data-principle="perceivable">IME composition windows use small candidates and low contrast; users miss the intended selection.</li>
<li data-principle="perceivable">OSK feedback for long-press diacritics is visually tight; diacritic options are missed at high magnification.</li>
<li data-principle="perceivable">Microphone level meters are compact with thin bars; users can't perceive adequate input levels while dictating.</li>
</ul>
</section>
<section aria-labelledby="expression-of-language-operable-h" id="expression-of-language-operable">
<h3 id="expression-of-language-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Dictation and voice access share conflicting shortcuts; switching modes mid-field requires extra steps.</li>
<li data-principle="operable">IME candidate selection demands fine target acquisition; switch/eye-gaze users struggle to confirm choices.</li>
<li data-principle="operable">Punctuation via voice requires verbose phrasing; there's no terse, consistent command set across apps.</li>
<li data-principle="operable">Moving focus between fields can terminate dictation; users must repeatedly restart expression aids.</li>
</ul>
</section>
<section aria-labelledby="expression-of-language-understandable-h" id="expression-of-language-understandable">
<h3 id="expression-of-language-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Voice command grammar isn't demonstrated in-product; examples for editing and formatting are sparse.</li>
<li data-principle="understandable">IME personalization and learning features aren't explained; users don't know how to teach preferred vocabulary.</li>
<li data-principle="understandable">Differences between Dictation, Voice access, and Narrator "type with voice" are unclear; users choose the wrong tool.</li>
<li data-principle="understandable">OSK advanced layouts (split, one-handed) lack scenario guidance; users can't match layout to motor strategy.</li>
</ul>
</section>
<section aria-labelledby="expression-of-language-robust-h" id="expression-of-language-robust">
<h3 id="expression-of-language-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Speech services require connectivity for best accuracy; enterprise blocks cause silent quality degradation.</li>
<li data-principle="robust">AT can't automatically trigger alternative modalities on low speech-confidence (e.g., prompt OSK); expression stalls.</li>
<li data-principle="robust">IME APIs differ across Win32/UWP; third-party AT can't maintain consistent candidate control.</li>
<li data-principle="robust">Clipboard and input method events aren't unified; external AAC tools can't reliably insert text across shells.</li>
</ul>
</section>
</article>
<!-- Simple calculation -->
<article aria-labelledby="simple-calculation-h" id="simple-calculation">
<h2 id="simple-calculation-h">Simple calculation</h2>
<p class="icf-label"><b>Cognition</b> Simple calculation</p>
<section aria-labelledby="simple-calculation-perceivable-h" id="simple-calculation-perceivable">
<h3 id="simple-calculation-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Storage sizes in Settings mix units (GB, GiB) without visual emphasis; users misread quantities.</li>
<li data-principle="perceivable">Battery estimates show fluctuating numbers in small type; users can't perceive stable values for planning.</li>
<li data-principle="perceivable">Time zone offsets and DST indicators are subtle; calculating local time becomes error-prone.</li>
<li data-principle="perceivable">Calculator history uses light separators; previously computed results are hard to pick out.</li>
</ul>
</section>
<section aria-labelledby="simple-calculation-operable-h" id="simple-calculation-operable">
<h3 id="simple-calculation-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Copying values from Task Manager graphs requires precise selection; keyboard access to exact numbers is limited.</li>
<li data-principle="operable">Calculator mode switching (Standard/Scientific/Programmer) hides functions across menus; quick access is slow.</li>
<li data-principle="operable">Percent and unit conversions are buried; users must navigate multiple clicks to perform simple math.</li>
<li data-principle="operable">Selecting numeric text in Settings (e.g., disk quotas) is inconsistent; spin controls lack predictable keyboard increments.</li>
</ul>
</section>
<section aria-labelledby="simple-calculation-understandable-h" id="simple-calculation-understandable">
<h3 id="simple-calculation-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">"Available vs. Used" storage concepts aren't explained with examples; users miscalculate free space.</li>
<li data-principle="understandable">Network speed units (Mbps vs. MB/s) aren't clarified; users misjudge download times.</li>
<li data-principle="understandable">Battery "Estimated time remaining" lacks method disclosure; users can't gauge accuracy.</li>
<li data-principle="understandable">Calculator order-of-operations mode isn't explicit; novices misinterpret multi-step results.</li>
</ul>
</section>
<section aria-labelledby="simple-calculation-robust-h" id="simple-calculation-robust">
<h3 id="simple-calculation-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Programmatic access to numeric values in custom charts is limited; AT can't retrieve exact data points.</li>
<li data-principle="robust">Locale settings affect decimal separators; some apps don't follow system conventions, breaking calculations.</li>
<li data-principle="robust">Copy-as-text from system surfaces strips units; downstream tools can't preserve meaning.</li>
<li data-principle="robust">Calculator's history export lacks a tagged structure; external coaching tools can't analyze steps.</li>
</ul>
</section>
</article>
<!-- Experience of self and time functions -->
<article aria-labelledby="experience-of-self-and-time-functions-h" id="experience-of-self-and-time-functions">
<h2 id="experience-of-self-and-time-functions-h">Experience of self and time functions</h2>
<p class="icf-label"><b>Cognition</b> Experience of self and time functions</p>
<section aria-labelledby="experience-of-self-and-time-functions-perceivable-h" id="experience-of-self-and-time-functions-perceivable">
<h3 id="experience-of-self-and-time-functions-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Notification timestamps collapse to relative phrases ("a moment ago"); users can't perceive exact time anchors.</li>
<li data-principle="perceivable">Lock screen clock is small on some layouts; users miss current time and next calendar item.</li>
<li data-principle="perceivable">Focus Sessions progress indicators lack prominent end-time; temporal goals aren't visible.</li>
<li data-principle="perceivable">File Explorer date columns default to relative dates; exact times are hidden without view changes.</li>
</ul>
</section>
<section aria-labelledby="experience-of-self-and-time-functions-operable-h" id="experience-of-self-and-time-functions-operable">
<h3 id="experience-of-self-and-time-functions-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Switching time zones requires multiple pages; travelers can't quickly orient when landing in a new locale.</li>
<li data-principle="operable">Alarms &amp; Clock app requires precise pointer actions to set durations; keyboard entry paths are non-obvious.</li>
<li data-principle="operable">Timeline-like activity recall is fragmented (Recent files, Jump Lists, Notifications); operating a coherent history is difficult.</li>
<li data-principle="operable">Scheduling quiet hours across weekdays vs. weekends needs repetitive configuration; batch edit is absent.</li>
</ul>
</section>
<section aria-labelledby="experience-of-self-and-time-functions-understandable-h" id="experience-of-self-and-time-functions-understandable">
<h3 id="experience-of-self-and-time-functions-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Auto time sync vs. set time manually isn't contrasted; users can't reason about drift symptoms.</li>
<li data-principle="understandable">Focus Sessions lacks plain guidance for break ratios; users can't plan self-paced cycles.</li>
<li data-principle="understandable">Relative vs. absolute time in file views isn't explained; users misjudge recency.</li>
<li data-principle="understandable">Notifications center mixes app and system events; understanding daily rhythm is difficult.</li>
</ul>
</section>
<section aria-labelledby="experience-of-self-and-time-functions-robust-h" id="experience-of-self-and-time-functions-robust">
<h3 id="experience-of-self-and-time-functions-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Programmatic access to absolute timestamps in notifications is limited; AT can't announce exact times on demand.</li>
<li data-principle="robust">Calendar widgets from different apps use different APIs; assistants can't aggregate a stable "now/next".</li>
<li data-principle="robust">Time zone changes aren't consistently broadcast to all apps; some surfaces show stale times post-travel.</li>
<li data-principle="robust">Exporting activity history is fragmented; external tools can't reconstruct a timeline for orientation aids.</li>
</ul>
</section>
</article>
<!-- Visual acuity (far/near) -->
<article aria-labelledby="visual-acuity-h" id="visual-acuity">
<h2 id="visual-acuity-h">Visual acuity (far/near)</h2>
<p class="icf-label"><b>Sensory</b> Visual acuity (far/near)</p>
<section aria-labelledby="visual-acuity-perceivable-h" id="visual-acuity-perceivable">
<h3 id="visual-acuity-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Taskbar badges use tiny numerals; at 125-150% scaling the glyphs remain small and low-contrast.</li>
<li data-principle="perceivable">Title-bar window controls shrink on high-DPI monitors; hit targets and icons are difficult to resolve at distance.</li>
<li data-principle="perceivable">Settings side-nav uses compact text with limited weight contrast; near acuity challenges reduce readability.</li>
<li data-principle="perceivable">File Explorer column headers truncate without tooltip expansion; users can't perceive full labels at common zoom levels.</li>
</ul>
</section>
<section aria-labelledby="visual-acuity-operable-h" id="visual-acuity-operable">
<h3 id="visual-acuity-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Increasing text size doesn't consistently enlarge controls in legacy dialogs; users still must operate small targets.</li>
<li data-principle="operable">Magnifier docked mode hides parts of controls; pointer and focus are hard to coordinate on small widgets.</li>
<li data-principle="operable">OSK resize handle is subtle; users with near-vision challenges struggle to adjust keyboard size quickly.</li>
<li data-principle="operable">Context menu submenus auto-open on hover; overshooting small items makes activation unreliable.</li>
</ul>
</section>
<section aria-labelledby="visual-acuity-understandable-h" id="visual-acuity-understandable">
<h3 id="visual-acuity-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Differences between "Text size", "Display scale", and "Ease font" aren't explained; users pick the wrong setting for acuity needs.</li>
<li data-principle="understandable">High DPI warnings use technical phrasing; users can't predict which apps won't scale text properly.</li>
<li data-principle="understandable">Cursor size and thickness controls are in different panes; users expect a single place to tune visibility.</li>
<li data-principle="understandable">"Make everything bigger" labels don't disclose exceptions (legacy apps); expectations aren't set for mixed results.</li>
</ul>
</section>
<section aria-labelledby="visual-acuity-robust-h" id="visual-acuity-robust">
<h3 id="visual-acuity-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Some Win32 apps render text as bitmaps; screen magnification and AT can't improve clarity programmatically.</li>
<li data-principle="robust">Per-monitor DPI awareness varies; app bounds reported to AT don't match visual scale for precise targeting.</li>
<li data-principle="robust">System font scaling isn't uniformly honored in WebView/embedded controls; mixed legibility across surfaces.</li>
<li data-principle="robust">AT cannot query per-control font scale overrides; companion tools can't enforce consistent readable sizing.</li>
</ul>
</section>
</article>
<!-- Quality of vision -->
<article aria-labelledby="quality-of-vision-h" id="quality-of-vision">
<h2 id="quality-of-vision-h">Quality of vision</h2>
<p class="icf-label"><b>Sensory</b> Quality of vision</p>
<section aria-labelledby="quality-of-vision-perceivable-h" id="quality-of-vision-perceivable">
<h3 id="quality-of-vision-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Acrylic/translucent backgrounds reduce text contrast in Start and context menus; halos blur letterforms.</li>
<li data-principle="perceivable">Thin glyph styles in system icons reduce stroke clarity; low-contrast themes further degrade legibility.</li>
<li data-principle="perceivable">Notification toasts use image-heavy previews; compression artifacts and small text impair recognition.</li>
<li data-principle="perceivable">Subpixel rendering varies across monitors; clarity shifts when moving windows between displays.</li>
</ul>
</section>
<section aria-labelledby="quality-of-vision-operable-h" id="quality-of-vision-operable">
<h3 id="quality-of-vision-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Low-contrast focus indicators in some controls make keyboard traversal hard for users with blurred vision.</li>
<li data-principle="operable">Edge-resize cursors are thin; users with ghosting/diplopia can't confirm they've hit the edge to drag.</li>
<li data-principle="operable">Small, low-contrast scrollbars in modern apps hinder precise scrolling when vision quality fluctuates.</li>
<li data-principle="operable">Color filter and contrast themes don't apply inside some custom-rendered panes; interaction remains visually noisy.</li>
</ul>
</section>
<section aria-labelledby="quality-of-vision-understandable-h" id="quality-of-vision-understandable">
<h3 id="quality-of-vision-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">"Transparency effects" doesn't explain readability tradeoffs; users can't connect the toggle to clarity issues.</li>
<li data-principle="understandable">"Contrast themes" vs. "Dark mode" aren't contrasted; users expect dark mode to meet contrast needs.</li>
<li data-principle="understandable">Font smoothing options use technical names; users can't choose the clearest rendering for their display.</li>
<li data-principle="understandable">HDR/cleartype calibration flows don't preview common UI surfaces; users misjudge real-world clarity.</li>
</ul>
</section>
<section aria-labelledby="quality-of-vision-robust-h" id="quality-of-vision-robust">
<h3 id="quality-of-vision-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Some app surfaces bypass system theme contrast; AT and system policies can't enforce readable color pairs.</li>
<li data-principle="robust">Per-app rendering engines (WinUI, WPF, Electron) expose different accessibility trees; clarity aids can't be applied uniformly.</li>
<li data-principle="robust">Wallpaper/theme sync changes appearance across devices unexpectedly; clarity settings don't roam predictably.</li>
<li data-principle="robust">Programmatic color/contrast metrics aren't exposed for all elements; tooling can't detect low-clarity states.</li>
</ul>
</section>
</article>
<!-- Visual field functions -->
<article aria-labelledby="visual-field-functions-h" id="visual-field-functions">
<h2 id="visual-field-functions-h">Visual field functions</h2>
<p class="icf-label"><b>Sensory</b> Visual field functions</p>
<section aria-labelledby="visual-field-functions-perceivable-h" id="visual-field-functions-perceivable">
<h3 id="visual-field-functions-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Key indicators (toast close button, taskbar overflow chevron) sit at screen edges; users with tunnel vision don't see them.</li>
<li data-principle="perceivable">System dialogs can appear behind fullscreen apps; peripheral-only banners go unnoticed.</li>
<li data-principle="perceivable">Snap hints render near the top edges; users focusing centrally miss spatial cues.</li>
<li data-principle="perceivable">Notification counter in Action Center is small and off-axis; peripheral scotomas hide it.</li>
</ul>
</section>
<section aria-labelledby="visual-field-functions-operable-h" id="visual-field-functions-operable">
<h3 id="visual-field-functions-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Edge-swipe gestures on tablets require peripheral awareness; users with hemianopia can't trigger reliably.</li>
<li data-principle="operable">Drag-to-reorder taskbar icons depends on lateral vision; keyboard alternatives aren't obvious.</li>
<li data-principle="operable">Multi-monitor cursor travel crosses bezels; users with field loss lose pointer and context.</li>
<li data-principle="operable">Window controls are spaced widely; users relying on central islands of vision overshoot buttons.</li>
</ul>
</section>
<section aria-labelledby="visual-field-functions-understandable-h" id="visual-field-functions-understandable">
<h3 id="visual-field-functions-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">No in-product guidance explains how to reposition UI (e.g., toast origin) for central vision users.</li>
<li data-principle="understandable">Pointer trails vs. large pointer aren't contrasted; users don't know which helps field loss more.</li>
<li data-principle="understandable">"Automatically hide taskbar" doesn't warn about discoverability impacts for reduced peripheral vision.</li>
<li data-principle="understandable">Snap layouts vs. zones aren't described with central-vision examples; users can't choose supportive patterns.</li>
</ul>
</section>
<section aria-labelledby="visual-field-functions-robust-h" id="visual-field-functions-robust">
<h3 id="visual-field-functions-robust-h">Robust</h3>
<ul>
<li data-principle="robust">AT can't change toast anchor or safe area programmatically; peripheral placement remains inaccessible.</li>
<li data-principle="robust">Per-monitor taskbars and overlays expose inconsistent bounds; assistive focus boxes misalign across displays.</li>
<li data-principle="robust">Secure desktop prevents custom focus rings/trails; field-compensation aids disappear at critical moments.</li>
<li data-principle="robust">OS doesn't expose a unified "central focus mode" signal; apps can't adapt layouts for narrowed fields.</li>
</ul>
</section>
</article>
<!-- Sound detection -->
<article aria-labelledby="sound-detection-h" id="sound-detection">
<h2 id="sound-detection-h">Sound detection</h2>
<p class="icf-label"><b>Hearing</b> Sound detection</p>
<section aria-labelledby="sound-detection-perceivable-h" id="sound-detection-perceivable">
<h3 id="sound-detection-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Minor system sounds lack parallel visual cues; users who don't detect soft beeps miss status changes.</li>
<li data-principle="perceivable">Bluetooth connect/disconnect tones are quiet and similar; users can't perceive device state transitions.</li>
<li data-principle="perceivable">Noisy backgrounds mask alert chimes; toast banners fade quickly before they're noticed.</li>
<li data-principle="perceivable">Battery low alerts are brief; users with limited hearing don't detect the short tone in time.</li>
</ul>
</section>
<section aria-labelledby="sound-detection-operable-h" id="sound-detection-operable">
<h3 id="sound-detection-operable-h">Operable</h3>
<ul>
<li data-principle="operable">There's no single toggle to convert all critical sounds into persistent visual alerts; configuration is scattered.</li>
<li data-principle="operable">Hardware volume keys provide tonal feedback without haptic/visual parity; users can't operate volume changes confidently.</li>
<li data-principle="operable">Per-app sound routing lacks a clear on-screen confirmation; deaf/HoH users can't verify with a glance.</li>
<li data-principle="operable">Live Captions doesn't auto-start on system boot; users can't operate a "sound detection first" workflow hands-free.</li>
</ul>
</section>
<section aria-labelledby="sound-detection-understandable-h" id="sound-detection-understandable">
<h3 id="sound-detection-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Sound theme names don't communicate urgency semantics; users can't map tones to importance.</li>
<li data-principle="understandable">Mixer terms (input/output, system vs. app) are jargon; users can't reason about where audio goes.</li>
<li data-principle="understandable">Spatial audio labels suggest directionality for alerts; users expect location cues that aren't provided.</li>
<li data-principle="understandable">"Mono audio" setting doesn't clarify effect on stereo alerts; users misinterpret what's merged.</li>
</ul>
</section>
<section aria-labelledby="sound-detection-robust-h" id="sound-detection-robust">
<h3 id="sound-detection-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Caption and notification APIs don't uniformly expose non-speech audio events; AT can't detect all cues.</li>
<li data-principle="robust">Some system sounds originate from drivers/OEM tools outside accessibility hooks; visual parity isn't triggered.</li>
<li data-principle="robust">Audio device changes may not fire consistent automation events; companion apps miss state transitions.</li>
<li data-principle="robust">There's no severity taxonomy for alerts across subsystems; assistants can't prioritize conversions to visual alarms.</li>
</ul>
</section>
</article>
<!-- Sound discrimination -->
<article aria-labelledby="sound-discrimination-h" id="sound-discrimination">
<h2 id="sound-discrimination-h">Sound discrimination</h2>
<p class="icf-label"><b>Hearing</b> Sound discrimination</p>
<section aria-labelledby="sound-discrimination-perceivable-h" id="sound-discrimination-perceivable">
<h3 id="sound-discrimination-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">Critical error, warning, and information tones share similar timbre and duration; urgency is hard to distinguish by ear alone.</li>
<li data-principle="perceivable">Quiet "device connected" and "device disconnected" tones sound alike; users can't perceive which event occurred.</li>
<li data-principle="perceivable">Volume change "ticks" mask concurrent notification chimes; overlapping sounds blur distinctions.</li>
<li data-principle="perceivable">Background Focus music and system alerts mix at similar loudness; signals are not perceptually separated.</li>
</ul>
</section>
<section aria-labelledby="sound-discrimination-operable-h" id="sound-discrimination-operable">
<h3 id="sound-discrimination-operable-h">Operable</h3>
<ul>
<li data-principle="operable">There is no "preview all system sounds with labels" panel; testing differences requires hunting through multiple dialogs.</li>
<li data-principle="operable">Per-app volume mixer lacks a one-step "solo alerts" control; isolating notification sounds during setup is tedious.</li>
<li data-principle="operable">Hardware media keys produce tones without on-screen type/level indicators; non-hearing users can't confirm the action taken.</li>
<li data-principle="operable">Sound theme changes are buried; switching quickly to a high-contrast audio set isn't streamlined.</li>
</ul>
</section>
<section aria-labelledby="sound-discrimination-understandable-h" id="sound-discrimination-understandable">
<h3 id="sound-discrimination-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">Sound theme names are aesthetic ("Calligraphy", "Default") rather than semantic; users can't infer alert hierarchy.</li>
<li data-principle="understandable">Mixer labels like "System sounds" vs. "Notifications" aren't defined; users can't map tones to categories.</li>
<li data-principle="understandable">Auto-ducking is described briefly; users don't understand why music dips when alerts play.</li>
<li data-principle="understandable">Spatial audio marketing copy implies clarity improvements; users expect better discrimination that isn't provided for alerts.</li>
</ul>
</section>
<section aria-labelledby="sound-discrimination-robust-h" id="sound-discrimination-robust">
<h3 id="sound-discrimination-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Audio notification metadata (type, priority) isn't uniformly exposed to AT; third-party captioners can't label tones distinctly.</li>
<li data-principle="robust">Driver-level tones (Bluetooth stack, camera) bypass system hooks; visual equivalence isn't guaranteed.</li>
<li data-principle="robust">Exclusive-mode audio from apps can mask or delay alert cues; no guaranteed side-channel for critical signals.</li>
<li data-principle="robust">No shared urgency taxonomy across subsystems; assistants can't programmatically style or rank alert sounds.</li>
</ul>
</section>
</article>
<!-- Localization of sound source -->
<article aria-labelledby="localization-of-sound-source-h" id="localization-of-sound-source">
<h2 id="localization-of-sound-source-h">Localization of sound source</h2>
<p class="icf-label"><b>Hearing</b> Localization of sound source</p>
<section aria-labelledby="localization-of-sound-source-perceivable-h" id="localization-of-sound-source-perceivable">
<h3 id="localization-of-sound-source-perceivable-h">Perceivable</h3>
<ul>
<li data-principle="perceivable">System alerts don't include optional visual "source" badges; users can't perceive which app or device produced the sound.</li>
<li data-principle="perceivable">Per-app meters in the volume mixer are small; quickly perceiving which app is sounding is difficult.</li>
<li data-principle="perceivable">Device-connection tones are identical for different ports (USB-C vs. dock); source localization by context is weak.</li>
<li data-principle="perceivable">No visual spatial map for multi-output setups; users can't see which physical device is active when a sound plays.</li>
</ul>
</section>
<section aria-labelledby="localization-of-sound-source-operable-h" id="localization-of-sound-source-operable">
<h3 id="localization-of-sound-source-operable-h">Operable</h3>
<ul>
<li data-principle="operable">Switching default output via Quick Settings doesn't highlight the originating app; re-routing sound is trial-and-error.</li>
<li data-principle="operable">There is no "Identify playing app" shortcut; users must open the mixer and scan small meters.</li>
<li data-principle="operable">When multiple devices play system tones, there's no per-device visual ping; locating the speaker requires manual testing.</li>
<li data-principle="operable">Mono audio mode removes directional cues without adding visual alternatives; operation relies on guesswork.</li>
</ul>
</section>
<section aria-labelledby="localization-of-sound-source-understandable-h" id="localization-of-sound-source-understandable">
<h3 id="localization-of-sound-source-understandable-h">Understandable</h3>
<ul>
<li data-principle="understandable">"App volume and device preferences" lacks examples; users don't understand how to bind one app to one device.</li>
<li data-principle="understandable">Labels like "Default communications device" vs. "Default device" are not explained; routing rules are opaque.</li>
<li data-principle="understandable">Spatial audio descriptions emphasize immersion; users expect it to identify sources of alerts, which it doesn't.</li>
<li data-principle="understandable">No guidance on using visual indicators (toasts, badges) to substitute for sound localization cues.</li>
</ul>
</section>
<section aria-labelledby="localization-of-sound-source-robust-h" id="localization-of-sound-source-robust">
<h3 id="localization-of-sound-source-robust-h">Robust</h3>
<ul>
<li data-principle="robust">Apps using exclusive-mode or custom engines don't surface activity to system mixers; AT can't discover the source.</li>
<li data-principle="robust">Bluetooth multipoint switching isn't consistently signaled via automation events; assistants miss device changes.</li>