-
Notifications
You must be signed in to change notification settings - Fork 2
/
LCcomments.html
4481 lines (4419 loc) · 267 KB
/
LCcomments.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>Disposition of Comments on UAAG 2.0 Last Call Working Draft of 7 November 2013</title>
<link rel="stylesheet" href="http://www.w3.org/WAI/wai-main.css" type="text/css" />
<!--[if IE 7]><link rel="stylesheet" href="/WAI/ie-old.css" type="text/css" media="all" /><![endif]-->
<style type="text/css">
table {
border-collapse:collapse;
}
th, td {
border: 1px solid black;
vertical-align:top;
}
.editor-notes {
border: 1px solid red;
}
.proposed-text: {
background-color: #FFCCFF !important;
}
.editorial {
background-color:#F9F
}
.not-addressed {
background-color:#C00
}
.under-discussion {
background-color: #CF0
}
.done {
background-color:#060;
color:#FFF
}
tr.header {
background-color: #FFFF00;
}
tr.h1 {
background-color: #FF9933;
}
tr.h2 {
background-color: #99FF99;
}
tr.h3 {
background-color: #CCFFFF;
}
tr.h1 td.whole-line, tr.h2 td.whole-line {
font-style: bold;
}
.proposed-text {
BACKGROUND-COLOR:#FFCCFF !important;
}
.summary {
padding: 1em;
font-weight:200;
color:#000000;
background-color:#FFFFFF;
border:thin solid #666666;
}
.summary1 { margin: .5em;
padding: 1em;
font-weight:200;
color:#000000;
background-color:#FFFFFF;
border:thin solid #666666;
}
</style>
</head>
<body>
<div id="controls">
<ul>
<li><a href="#skip" shape="rect"><img src="/Icons/downinpage.png" alt="" /> Skip to Content </a></li>
<li><a href="/WAI/changedesign.html" shape="rect"> | Change
text size or colors </a> </li>
</ul>
</div>
<div id="masthead">
<p id="logos"><a href="http://www.w3.org/" title="W3C Home" shape="rect"><img alt="W3C logo" src="/Icons/w3c_home" /></a><a href="http://www.w3.org/WAI/" title="WAI Home" shape="rect"><img alt="Web Accessibility initiative" src="/WAI/images/wai-temp" /></a></p>
</div>
<div id="tagline">
<p>WAI: Strategies, guidelines, resources to make the
Web accessible to people with disabilities</p>
</div>
<p><strong>Site Navigation: <a href="http://www.w3.org/">W3C Home</a> > <a href="http://www.w3.org/WAI/">WAI Home</a> > <a href="http://www.w3.org/WAI/UA/">UAWG Home</a></strong></p>
<div id="skipwrapper"> <a id="skip" shape="rect">-</a></div>
<div>
<h1>Disposition of Comments: <br />
UAAG 2.0 and Implementing UAAG 2.0 Last Call<br />
Working Drafts of 7 November 2013 </h1>
<dl>
<dt>Updated on:</dt>
<dd>26 September, 2014</dd>
<dt>This Version (Editors draft: Github)</dt>
<dd><a href="http://jspellman.github.io/UAAG-LC-Comment/LCcomments">http://jspellman.github.io/UAAG-LC-Comment/LCcomments</a></dd>
<dt>Latest Version</dt>
<dd><a href="http://www.w3.org/WAI/UA/2014/LCcomments.html">http://www.w3.org/WAI/UA/2014/LCcomments.html</a></dd>
<dt>Previous Version (pre-Github):</dt>
<dd><a href="http://w3.org/WAI/UA/2014/LCcomments-20140122.html">http://w3.org/WAI/UA/2014/LCcomments-20140410.html</a></dd>
</dl>
<p>This is a working document from the User Agent Accessibility
Guidelines Working Group (UAWG) that details action taken on the 102
issues received from 12 commenters on the Last Call working drafts of 7
November 2013 of UAAG 2.0 and Implementing UAAG 2.0. The table includes
relevent text from UAAG 2.0 and Implementing UAAG 2.0; the
classification of the comment, the UAWG response, and whether the
commenter agreed with the change. There may also be highlighted text in
the Response column whether or not the change has been accepted into
the <a href="http://www.w3.org/WAI/UA/UAAG20/">latest Editors' Draft</a>. If there was extensive discussion in UAWG about the issue, the word "UAWG" in the response is linked to the minutes of that meeting. </p>
<p>See also: <br />
<a href="http://www.w3.org/TR/2013/WD-UAAG20-20131107/">UAAG 2.0 Last Call Working Draft of 7 November 2013</a><br />
<a href="http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/">Implementing UAAG 2.0 Working Draft of 7 November 2013 </a></p>
<h2>Comments Received from:</h2>
<dl>
<dt>Education & Outreach Working Group (EO) <span class="done">[done]</span></dt>
<dd><a href="http://www.w3.org/WAI/EO/wiki/UAAG_review_December_2013">http://www.w3.org/WAI/EO/wiki/UAAG_review_December_2013</a></dd>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0013.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0013.html</a></dd>
<dt>Wayne Dick (WD) - 2 issues <span class="done">[done]</span></dt>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2013Dec/0000.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2013Dec/0000.html</a></dd>
<dt>James Craig, Apple (AP) - 2 issues <span class="done">[done]</span> </dt>
<dd>direct email</dd>
<dt>Silas Brown (SB) - 6 issues <span class="done">[done]</span></dt>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0000.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0000.html</a></dd>
<dt>Dominic Mazzilli, Chrome (CR) - 7 issues <span class="done">[done]</span></dt>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0001.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0001.html</a></dd>
<dt>Alex Li, Microsoft (MS) - 9 issues <span class="done">[done<a href="http://www.w3.org/WAI/UA/tracker/actions/976"></a>]</span> </dt>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0002.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0002.html</a></dd>
<dt>Joshue O'Connor, WCAG WG (JO) - 22 issues <span class="done">[done]</span></dt>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0005.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0005.html</a></dd>
<dt>Laurent Goderre, Web Experience Toolkit Player (LG)
- 4 issues <span class="done">[done<a href="https://www.w3.org/WAI/UA/tracker/actions/987"></a>]</span> </dt><dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0007.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0007.html</a></dd>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0009.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0009.html</a></dd>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0010.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0010.html</a></dd>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0011.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0011.html</a></dd>
<dt>Shwetank Dixit, Opera (OP) - 7 issues <span class="done">[done]</span></dt>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0008.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0008.html</a></dd>
<dt>Eric Hansen, Educational Testing Serive (EH) - 15 issues <span class="done">[done]</span> </dt>
<dd><a href="http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0024.html">http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0024.html</a></dd>
<dt>Simon Harper, RDWG (SH) - 6 issues <span class="done">[done]</span></dt>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0012.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0012.html</a></dd>
<dt>Lisa Seeman, Cognative Accessibility Task Force (CA) - 6 issues <span class="done">[done]</span></dt>
<dd><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Feb/0000.html">http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Feb/0000.html</a></dd>
</dl>
<h2>Legend: </h2>
<ul>
<li><strong>Priority</strong>: The success criteria level (if applicable) A, AA, AAA</li>
<li><strong>Guidelines and Success Criteria</strong>: text from the 7 November 2013 Last Call Working Draft</li>
<li><strong>Comments</strong>: received from reviewer</li>
<li><strong>Type</strong>: substantive, editorial, question</li>
<li><strong>Response</strong>: the action taken by the group with a link to the minutes or survey documenting the decision. </li>
<li><strong>Disposition</strong>: the group response (proposal not accepted, accepted, partial accept, alternative action taken)</li>
<li><strong>Acknowledgement</strong>: from reviewer about our disposition of comment</li>
<li><strong>Highlighting</strong>: orange=Principle (heading level 2), green=Guideline (heading level 3)</li>
</ul>
<h2>Disposition of Comments</h2>
<table rules="none" cellspacing="0" border="0">
<colgroup>
<col width="5%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="15%" />
<col width="5%" />
<col width="10%" />
</colgroup>
<tbody>
<tr class="header">
<th align="center" valign="top"><strong>Priority</strong></th>
<th align="center" valign="top"><strong>Whole Line</strong></th>
<th align="center" valign="top"><strong>Comments</strong></th>
<th align="center" valign="top"><strong>Response</strong></th>
<th align="center" valign="top"><strong>Disposition</strong></th>
<th align="center" valign="top"><strong>type</strong></th>
<th align="center" valign="top"><strong>Acknowledgment</strong></th>
</tr>
<tr class="h1">
<td align="left" valign="top"> </td>
<td align="left" valign="top"><h2>General Comments</h2></td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top"><p>CR01: Chrome has a general
philosophy that users should not be presented with too many settings or
switches to control. Settings that are only enabled by a small
minority of users increase the perceived complexity for everyone else
and also increase the number of possible configurations for the
developer to support and test. We prefer many such features to be
available via extensions or add-ons instead. This document contains a
large number of recommendations for additional configurations a user
can specify, presumably via a specific option or setting built-into the
browser.</p>
<p> What do you think about having extensions available for each
of these features, rather than building them into the browser? Would
Chrome be considered compliant with this spec if we implemented all of
these guidelines as extensions and published an easy-to-use catalog of
these for users to browse and install the ones they want? </p>
<p>The "Implementing" spec even references Firefox add-ons, like
Text Equivalent Expand Abbreviations. Do the spec authors feel that
such features should be built into the browser, or merely that such an
option must be available to users?</p></td>
<td align="left" valign="top"><p><span class="done">[done]</span> <a href="www.w3.org/2014/04/17-ua-minutes.html#item04">UAWG</a> adjusted the wording of the conformance section to specifically allow extensions. In order to claim compliance, the claimant must demonstrate that solutions, and any required additional components, are available to non-expert users. Enabling the creation of such solutions is not by itself sufficient. </p>
<p>UAWG also edited the Introduction to highlight using extensions. </p></td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">CR03: Some of the recommendations seem overly technical and narrow: for
example, the use-case for Show Element Hierarchy is that a user might want
to write a custom stylesheet and needs to determine the path to a
particular element within a page to write a style rule for it. However,
there are already more innovative solutions to this problem available. A
popular Chrome extension, StyleBot, lets the user simply click on any
element on the page and modify the custom stylesheet with a friendly dialog
interface. They can explore the classes that this element belongs to and
apply the same style change to all elements in that class. My concern is
just that these guidelines should not specify one narrow solution to a
problem that precludes a more clever implementation.
</td>
<td align="left" valign="top"><span class="done">[done]</span> <a href="http://www.w3.org/2014/04/24-ua-minutes.html#item02">UAWG</a> thinks it is true that some of the success criteria have very technical and narrow requirements, and that other, more effective approaches to addressing the problems may be developed. However, we do not believe that requiring the base-level fallback feature discourages development or inclusion of more effective approaches. (It's also true that there are additional use cases for this feature, such as a user of assistive technology that wants their screen reader to notify them when a region of the document changes, or when they want to set up shortcuts that move focus or a magnifying window between specific locations.)</td>
<td align="left" valign="top">Partial accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">CR04: Many of the guidelines are specific to a desktop computer, and written in
a way that's too narrow to apply to a web browser running on a phone,
tablet, or other device that may not have a keyboard. The guidelines should
be written in a way that explain the user need and don't assume that a
keyboard is available.</td>
<td align="left" valign="top"><span class="done">[done]</span> <a href="http://www.w3.org/2014/04/24-ua-minutes.html#item03">UAWG</a> entirely agrees; any success criterion that relies on a physical keyboard, visual output, or other platform dependencies should be scoped in its own language. Please let us know of any success criteria that don't sufficiently address this. Please keep in mind that even devices without physical keyboards are expected to support keyboard emulators and other types of assistive technology that rely on keyboard emulation at the programming interface level. See the note added to Principle 2 and the updated definition of "keyboard interface". </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">CR05: Many of the guidelines suggest features that are already available in
existing assistive technology - for example opening an elements list,
navigation by headings, or using voice control to jump to an element. Do
the guidelines really mean to suggest that the browser should reimplement
these as browser features rather than making them features of the AT? It's
not clear to me that browsers should be providing these features directly -
rather, they should expose rich information to AT via accessibility APIs,
and allow AT to innovate ways to present this information to diverse groups
of users.</td>
<td align="left" valign="top"><span class="done">[done]</span> <a href="http://www.w3.org/2014/04/24-ua-minutes.html#item01">UAWG</a> agrees that there are certainly features which are only applicable to users of assistive technology, and almost anything *could* be delegated (or relegated) to assistive technology. However, there are some features that benefit users who would not require assistive technology. The disadvantages of relying on assistive technology include all of those mentioned above in regard to providing features as extensions, but even more so. Regarding your specific examples, note that 2.5.2 (Provide Navigation by Heading and within Tables) is implemented by extensions for some browsers. Navigation by heading is required but not speech input navigation by heading. </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">AP01:
I think most of the UAAG can already be achieved in most browsers
with a combination of user style sheets and user scripts.</td>
<td align="left" valign="top"><span class="done">[done]</span> UAWG agrees that many items in UAAG2 are relatively easy to achieve with user style sheets and user scripts, but the onus for developing the style sheets and scripts should be on user agent developers rather than users. In order to claim compliance, the claimant must demonstrate that solutions, and any required additional components, are available to non-expert users. Enabling the creation of such solutions is not by itself sufficient.</td>
<td align="left" valign="top">Partial accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">MS06: Setting realistic Level A, AA,
and AAA success criteria
Assuming the working group agrees to narrow the scope of UAAG, we then
ask that the delineation between the levels to be reexamined. It is our
position that a browser meeting level A should be able to:
a) interact with web content that meets WCAG 2.0, and
b) facilitate programmatic access of the content and its user interface
to and from AT, and
c) follow the accessibility settings from the OS, and
d) provide an user interface that is generally accessible, such as
enabling keyboard control on its own features when operating on an
environment where keyboard control is available, and
e) nothing more
Level AA should consist of success criteria that aid users in case of
common content failures and predictable solutions are available.
Level AAA should consist of success criteria that aid users in case of
content failures and where implementable solutions are available.
Microsoft appreciates the aspiration of the working group. But it must
be understood that the final deliverable must be grounded on reality and
that implementations are necessary for UAAG to be considered for
recommendation. We encourage the working group to channel its
aspiration and creativity elsewhere where developers can consult for
future-generation-ideas instead of cluttering UAAG with unclear,
untested, or unrealistic success criteria.</td>
<td align="left" valign="top"><p><span class="done">[done]</span> <a href="http://www.w3.org/2014/05/29-ua-minutes.html#item05">UAWG</a> discussed applying the recommended Level setting and decided that the proposal did not meet all the The way "a) interact with web content that meets WCAG 2.0" is phrased suggests that any SC relating to the rendering of content that fails to completely meet WCAG 2.0 should be relegated to lower priority levels. Just as most users expect browsers to make best efforts to render content that has errors in its HTML, users expect browsers to make reasonable effort to render content that does not fully and accurately comply with WCAG. We believe we'd be doing an injustice to say a browser is doing its part if it fails to make those efforts. </p>
<p>Aside from this difference, we've reviewed the proposal and generally agree with the importance of the a, b, c, d criteria you laid out as level A. But it seems that almost all of our success criteria would fit into the delineation proposed for level A. We decided on which SC's should be AA and AAA by balancing the benefit to the user versus the difficulty of implementation. The logic behind the levels section is detailed here: <a href="http://www.w3.org/TR/IMPLEMENTING-UAAG20/#intro-conf-levels">http://www.w3.org/TR/IMPLEMENTING-UAAG20/#intro-conf-levels</a></p>
<p> </p></td>
<td align="left" valign="top">Not accepted</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"><a href="http://jspellman.github.io/UAAG-LC-Comment/#MS06">Not accepted. See new comments - MS06</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">MS07: <strong>Think beyond desktop computers</strong>
Another fundamental flaw in UAAG is that it is unclear whether it
reflects the reality that user agents are commonly available in mobile
phones, tablet, wearable, and television form factors where keyboards,
if available, are used for text entry instead of navigation, for
example. Indeed, WCAG 2.0 did not account for this in 2008 because
these form factors were brand new at the time. But UAAG should be
better prepared to address mobile accessibility in 2014. We encourage
the working group to closely examine non-desktop environments and
consider whether there are unique constraints or requirements as a
result.</td>
<td align="left" valign="top"><span class="done">[done]</span> <a href="http://www.w3.org/2014/08/14-ua-minutes.html#item09">UAWG</a> put non-desktop examples throughout Implementing UAAG and published a separate Note of <a href="http://www.w3.org/TR/IMPLEMENTING-UAAG20/mobile">Mobile Accessibility Examples from Implementing UAAG</a>. UAWG chose to put most of their non-desktop examples in Implementing UAAG (a W3C Note), so it could be kept up to date without undermining the stability of UAAG success criteria. In addition, UAAG contains broad definitions of keyboard and a note under Principle 2 on Modality independence which also includes references to Indie UI. The term "keyboard" is not limited to physical keyboards, or even the on-screen keyboards provided by the platform. In our document the term also includes physical keyboards that can be connected externally, third-party on-screen keyboards that can add modifiers and navigation keys, and software interfaces that can be used by assistive technology software. UAWG updated Conformance and success criteria to improve the clarity that UAAG applies to mobile and many forms of input and navigation. </td>
<td align="left" valign="top">Partial accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0002.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">MS09: <strong>Subjectivity must be eliminated</strong> <br />
We found some success criteria to be too subjective to be tested with
any reliability. For example, success criterion 2.3.1 (The user can
navigate directly to important elements in rendered content.) contains
two subjective terms that makes it essentially untestable—directly and
important. It is highly debatable as to which navigation methods are
considered as "directly" navigable. It is also impossible to
objectively determine what an important element is. We also found it
dubious that the working group expects a user agent to make such a
subjective decision when humans would have a difficult time making such
decision. Thus, even if a user agent attempts to determine what is
important, it would still be highly debatable as to whether it has done
so successfully. We ask the working group to meticulously remove
subjectivity from UAAG.</td>
<td align="left" valign="top"><p><span class="done">[done]</span> <a href="http://www.w3.org/2014/04/10-ua-minutes.html#item05">UAWG</a> has removed all references to "important elements". </p>
<p><a href="http://www.w3.org/2014/06/12-ua-minutes.html#item02">UAWG</a> has made "directly" more objective by 1) creating a separate glossary definition of "directly" that is linked to "direct commands"; 2) removing duplication between "direct command" and "keyboard command"; 3) adding links to the definition for "directly" in the success criteria. </p></td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0002.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">JO02: Some sentences are rather long: <br />
Consider breaking them up, for improved readability:<br />
eg "UAAG 2.0 encourages configuration requirements rather than
requirements for default settings. This is because a default user agent
setting may be useful for one user but interfere with the needs of
another. "</td>
<td align="left" valign="top"><span class="done">[done]</span> UAWG editors did another pass for readability of long sentences</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">EO17: The tables of contents only have 'Guideline N' as the link. Suggest also linking the guideline shortname because for many readers the numbers do not mean anything and they need the shortname to know the guideline.</td>
<td align="left" valign="top"><span class="done">[done]</span> </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments</strong></td>
<td align="left" valign="top">EO19: Typos: "webpage" instead of "web page". "timeline" vs. "time line"?</td>
<td align="left" valign="top"><span class="done">[done]</span> </td>
<td align="left" valign="top">Accept </td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments- Implementing UAAG 2.0</strong></td>
<td align="left" valign="top">MS05: <strong>Examples in the implementation document do not make distinction of content, browser, assistive technologies, and OS</strong><br />
We recognize the value of personalizing the examples, but these examples
are not implementation examples. They are use case scenarios with no
explanation of what is expected of the browser as oppose to that of the
content, the OS, and the AT. It is understandable that average users do
not understand the roles and responsibilities of content, browsers,
assistive technologies, and OS. But the working group needs to provide
more sufficient context for a technical audience. We believe this
problem is a reflection of the lack of focus in UAAG. Take, for
example, the second example from 1.2.2. (Maria uses a screen reader.
When a table lacks marked up header rows, the user agent gives her the
option to have the first row treated as the table header row.) It is
entirely unclear as to what is expected to be done from the example. It
is possible for the reader to interpret that:
a) the browser is supposed to alter the content without authorization
from the content author to change the structure of the table, or
b) the browser is supposed to alter what it passes through to the
accessibility API, or
c) the AT is supposed to figure out the table header row from the
accessibility API and present it to the user as such, or
d) the AT is supposed to interrogate the HTML code, determine the
header, ignore the information from an accessibility API, and present
the header to the user
Since there are so many ways to interpret the example and the lack of
scope of what a user agent is, it is essentially not implementable in
reality. Microsoft asks the working group to reexamine the fundamental
nature of what a user agent is and rewrite UAAG from top to bottom with a
more precise understanding of user agents and what can be done to make
them more accessible.</td>
<td align="left" valign="top"> <p><span class="done">[done]</span> <a href="http://www.w3.org/2014/05/01-ua-minutes.html#item04">UAWG</a> wrote the examples in Implementing UAAG to be illustrative of common uses by people with disabilities. In order to avoid being excessively prescriptive to the browser, we did not make divisions between platform, OS, browser and assistive technologies, knowing that the field is evolving rapidly, and the accessibility feature that is on the browser on one device, may be on the OS on another. See the UAAG Conformance Applicability Note #7: "Relationship with operating system or platform: The user agent does not need to implement every behavior itself. A required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. All are acceptable, as long as they are enumerated in the conformance claim."</p>
<p>
The UAAG Conformance Applicability Note #1: "Recognized Content Only: UAAG 2.0 success criteria only apply to web content and its behaviors that can be recognized by user agents." UAWG has clarified the definition of "recognize". </p>
<p><a href="http://www.w3.org/2014/05/01-ua-minutes.html#action04">UAWG</a> also edited the example in 1.2.2 to make the browser action more specific. </p>
<p> </p></td>
<td align="left" valign="top">Partial accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"><a href="http://jspellman.github.io/UAAG-LC-Comment/#MS05">Not accepted. See new comments MS05</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments- Implementing UAAG 2.0</strong></td>
<td align="left" valign="top">EO13: The document is called "Implementing UAAG" however it seems to provide very little specific guidance on actually implementing UAAG technically. Instead it provides information on how people with disabilities use the requirements of UAAG. Thus the title seems very misleading -- that the doc will provide something that it does not. It seems it would be better titled "Understanding UAAG".</td>
<td align="left" valign="top"><span class="done">[done]</span> UAWG agreed to change the name to UAAG 2.0 Reference. UAWG was concerned that the name "Understanding UAAG 2.0" was too close to WCAG's "Understanding WCAG", while providing a different structure than WCAG. </td>
<td align="left" valign="top">Partial Accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>General Comments- Implementing UAAG 2.0</strong></td>
<td align="left" valign="top">EO18: Examples of users: In most cases, the disability of the user is specified; however in some it is not, for example, Binh in success criterion 1.3.1 and Maximilian in 1.1.6. Without this, it may not be clear why it is necessary to implement the success criterion for the specified user. Suggestion: include disability for all examples.</td>
<td align="left" valign="top"><span class="done">[done]</span> do another pass of examples looking for missing disabilities.</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>Implementing UAAG - Levels of Conformance</strong></td>
<td align="left" valign="top">EO14: I think it's good that you moved most of the levels info to <a rel="nofollow" href="http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/#intro-conf-levels">Implementing</a>. I suggest the following restructuring of the section for flow and to focus on what most readers will be interested in -- that is, what the levels mean (not how you determined them) and how they can be used. (Follow up to <a rel="nofollow" href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2013Sep/0001.html">sept 2013 comment</a>.</td>
<td align="left" valign="top"><span class="done">[done]</span> Tks for the detailed suggested wording. </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr class="h1">
<td align="left" valign="top"> </td>
<td align="left" valign="top"><h1>Specific Comments on UAAG</h1></td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
</tr>
<tr class="h2">
<td align="left" valign="top"> </td>
<td align="left" valign="top"><h2>Abstract</h2></td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>Abstract</strong></td>
<td align="left" valign="top"><p>EO01: I think the abstract needs editing to be clearer, more direct, and simpler. <strong>Suggested edit:</strong> "UAAG is introduced in the <a rel="nofollow" href="http://www.w3.org/WAI/intro/uaag">User Agent Accessibility Guidelines (UAAG) Overview.</a> </p>
</td>
<td align="left" valign="top"><span class="done">[done]</span> UAWG edited Abstract for clarity, and added the link to an outside page for more introductory material. </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">Editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>Abstract</strong></td>
<td align="left" valign="top"><p>EO02: Last sentence of second paragraph is not clear. I don't really understand what it is for. </p></td>
<td align="left" valign="top"><span class="done">[done]</span> Reworded for clarity. It means UAAG doesn't replace the need for assistive technology. </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>Abstract</strong></td>
<td align="left" valign="top">EO15: "The "User Agent Accessibility Guidelines 2.0" (UAAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative (WAI)." To: "For an introduction to UAAG, see the <a href="<a href="http://www.w3.org/WAI/intro/uaag">http://www.w3.org/WAI/intro/uaag</a>">User Agent Accessibility Guidelines (UAAG) Overview.</a>" or "UAAG is introduced in the <a href="<a href="http://www.w3.org/WAI/intro/uaag">http://www.w3.org/WAI/intro/uaag</a>">User Agent Accessibility Guidelines (UAAG) Overview.</a>" or such -- and include this sentence in the both the Abstract and the Introduction of both UAAG and Implementing UAAG.</td>
<td align="left" valign="top"><span class="done">[done]</span></td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>Abstract</strong></td>
<td align="left" valign="top">EO16: As a general rule, the Abstract of a document should have a short summary of the main point(s) of the document, and as such, any information that is in the Abstract should be in the main document. Both UAAG and Implementing UAAG have info in the Abstract that is not elsewhere. Currently much of the Abstracts seems more like Background and Introduction material, and there is duplication between the two documents. Please consider moving much of the information from both Abstracts into a section of Implementing, and pointing to that from the UAAG intro (based on previous decision to put most of the non-normative info in Implementing so that you can edit it later if warranted). (We hope that the abstract is being rewritten in response to our December 2013 comments and therefore we are not commenting more specifically at this time.)
</td>
<td align="left" valign="top"><span class="done">[done]</span></td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>Abstract - Implementing UAAG</strong></td>
<td align="left" valign="top"><p>EO20: Second paragraph ("This document provides explanation of the intent of UAAG 2.0 success criteria, examples of implementation of the guidelines, best practice recommendations and additional resources for the guideline.") is not clear. Why "success criteria" first, then "guidelines" (plural), then "guideline" (singular)? Is this referring to the Guidelines as a document, or the individual success criteria and guidelines, or other? Does this document have anything at the guideline level or is it all at the SC level? If the latter – and based on above suggestion to address issues in the Abstract, maybe Abstract becomes:</p>
<p>
[[
This document provides supporting information for User Agent Accessibility Guidelines (UAAG) 2.0, a standard for accessible "user agents" (browsers, media players, and applications that retrieve and render Web content). It provides information on the scope of UAAG, conformance with UAAG, relationship of UAAG with other accessibility guidelines, and other general guidance. It explains the intent of each UAAG success criterion, provides examples of how people with disabilities use implementations of the success criterion, and lists related resources.</p>
<p>
For an introduction to UAAG, see the <a href="http://www.w3.org/WAI/intro/uaag">User Agent Accessibility Guidelines (UAAG) Overview</a>.
]]</p>
<p>
(Wording also avoids "best practice recommendations" because it can be a problem in the legal area, according to Gregg V.)</p></td>
<td align="left" valign="top"><span class="done">[done]</span></td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr class="h2">
<td align="left" valign="top"> </td>
<td align="left" valign="top"><h2>Status</h2></td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Status</td>
<td align="left" valign="top">EO03: <strong>Suggested revision:</strong>
Either remove "the" from the acronym expansion, leaving just "World
Wide Web Consortium", or remove the acronym expansion completely. <br />
<strong>Rationale:</strong> First option is more accurate,
second option because the acronym "W3C" is more recognizable than its
expansion (and faster to hear). </td>
<td align="left" valign="top"><span class="done">[done]</span> Removed "the" where it was not required in code provided by Pubrules. </td>
<td align="left" valign="top">Partial</td>
<td align="left" valign="top">Editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr class="h2">
<td align="left" valign="top"> </td>
<td align="left" valign="top"><h2>Introduction</h2></td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Overview</td>
<td align="left" valign="top">JO01: Some commas needed:
"Thus, many UAAG 2.0 requirements use configuration to ensure that a
functionality designed to improve accessibility, for one user, does not
interfere with accessibility for another."</td>
<td align="left" valign="top"><span class="done">[done]</span> "Many UAAG 2.0 requirements
use configuration preferences to ensure that a feature designed to
improve accessibility for one user does not interfere with the needs of
another user. "</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Overview</td>
<td align="left" valign="top">JO03: #3: This sentence isn't idea, and a little difficult to parse:
Firstly the line:
""For example, a feature required by UAAG 2.0 may be ineffective or
cause content to be less accessible, [...]" may not give the best 'first
impression' of UAAG!
To maintain the gist of the sentence and (shine a favourable light on
UAAG, as well as it's supporting documentation etc) how about:
"For example, if some feature required by UAAG 2.0 inadvertently caused
some content to be less accessible, it would be imperative that the user
be able to turn off that feature. Therefore, to avoid overwhelming users
with an abundance of configuration options, UAAG 2.0 includes
requirements that promote clear documentation and ease of configuration."</td>
<td align="left" valign="top"><span class="done">[done]</span> Removed some sentences and collapsed the paragraphs. </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Overview</td>
<td align="left" valign="top">EO04: <strong>Current wording:</strong> ...have control over their environment for accessing the web. <br />
<strong>Suggested revision:</strong> ...have equal control over the environment they use to access the web.<br />
<strong>Rationale:</strong> No one has full "control over their environment," but all should have the same degree of control</td>
<td align="left" valign="top"><span class="done">[done]</span></td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Overview</td>
<td align="left" valign="top">EO05: <strong>Current wording:</strong> Although author preferences are important, UAAG 2.0 includes requirements to override certain author preferences when the user would not otherwise be able to access that content. <br />
<strong>Suggested revision:</strong> Omit<br />
<strong>Rationale:</strong> Seems like a non sequitur. Don't understand why that aspect of UAAG is particularly called out, seems a distraction. </td>
<td align="left" valign="top"><span class="done">[done]</span> removed. Also see JO04. </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Overview</td>
<td align="left" valign="top">EO06: Needs editing. For example "Improving accessibility means considering a wide range of disabilities." needs to be stronger. <br />
These include visual, auditory, physical, speech, cognitive, language, learning, neurological disabilities, and disabilities related to aging." — consider using updated WAI wording: including auditory, cognitive, neurological, physical, speech, and visual disabilities. <br /></td>
<td align="left" valign="top"><span class="done">[done]</span> </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Overview</td>
<td align="left" valign="top">EO07: "The UAWG expects that software that satisfies the requirements of UAAG 2.0 will be more flexible, manageable, extensible, and beneficial for a broad range of users." -- Why is this in the normative guidelines? </td>
<td align="left" valign="top"><span class="done">[done]</span>
It is not in the normative guidelines, but in the Overview. It describes the benefits of using UAAG, and seems appropriate for the Introduction. </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">Question</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Overview</td>
<td align="left" valign="top">JO04: #4: This is an important clause IMO, and isn't clear - and may also be a
red flag for some readers. Remove - 'although author preferences are
important' - it's much clearer as:
"In some cases, UAAG 2.0 includes requirements to override author
preferences when the user would not otherwise be able to access
content." A link to an example may help:
Or even better - remove the section "the user would not otherwise be
able to access content." This may seem a little extreme but as there
just isn't clarification, or a URI nearby this sentence may just cause
confusion.
A way to deal with that would be to just state early on, that "In some
cases, UAAG 2.0 includes requirements to override author preferences." -
as this is clear statement of fact. That text could be a link to a
section with more info on the subject, and/or later on, further down in
the document it's expanded on to give the reader a better sense of
context. As the wording currently is, it's sounds a little apologetic to
me. "Oh, we know that author preferences are important but we are going
to overide them anyway!".
My preference would be to state first that this is possible, and then in
a relevant section - clarify and qualify the statement.</td>
<td align="left" valign="top"><span class="done">[done]</span> removed sentence. See EO05.</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: UAAG Layers of Guidance</td>
<td align="left" valign="top"><p>EH01: #3 Success Criteria - "Each success criterion is assigned a level. The levels are designed to meet the needs of different groups and different situations: A (low, or basic, conformance), AA (recommended conformance), and AAA (@@highest conformance). Additional information on UAAG levels can be found in the <a href="http://www.w3.org/WAI/UA/2014/ED-UAAG20-20140123/#intro-conf-levels">Levels of Conformance</a>section.</p>
<p>@@elsewhere it is called "advanced"</p>
<p>Elsewhere it is called advanced.</p></td>
<td align="left" valign="top"><span class="done">[done]</span> standardized the terms across the documents to: Level A (minimum), AA (recommended), AAA (advanced)</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: UAAG Layers of Guidance</td>
<td align="left" valign="top">JO05: #5: Under "UAAG 2.0 Layers of Guidenace" when listing the principle, put
a line break before the list starts, and then when it ends. It looks
bunched up. Also line breaks after the Princliples section, Guidelines
sections etc.</td>
<td align="left" valign="top"><span class="done">[done]</span> make CSS change</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: UAAG Layers of Guidance</td>
<td align="left" valign="top">EO08: Each success criterion is assigned a level. The levels are designed to meet the needs of different groups and different situations: A (low, or basic, conformance), AA (recommended conformance), and AAA (highest conformance).' uses different terminology than the Levels sections, which say: "A (basic), AA (recommended), and AAA (advanced)" </td>
<td align="left" valign="top"><span class="done">[done]</span> standardized the terms across the documents to: Level A (minimum), AA (recommended), AAA (advanced). See EH01</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: UAAG Layers of Guidance</td>
<td align="left" valign="top">EH09: In the paragraph explaining the principles, what about adding a link to Web Content Accessibility Guidelines 2.0. It would allow the reader to go to WCAG if they want to look at WCAG's principles. <br />
Related text:
<blockquote>Principles 1, 2, and 3 are parallel to Web Content Accessibility Guidelines (WCAG) 2.0. </blockquote></td>
<td align="left" valign="top"><span class="done">[done]</span> Added link to WCAG Overview</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Components</td>
<td align="left" valign="top">JO06: #6: Add the word 'both':
Under "Components of Web Accessibility" "Web accessibility depends on both accessible user agents and accessible
content. "</td>
<td align="left" valign="top"><span class="done">[done]</span> </td>
<td align="left" valign="top">Accept </td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Levels of Conformance</td>
<td align="left" valign="top">JO07: #7: Could you say "The level of accessibility for web content is largely
influenced by the authoring tool used to create it."?
#7 Under "Levels of Conformance"
Remove - "Having too many options may be overwhelming for some users."
and rearrange the sentence order as follows:
"The levels can help user agent developers decide which options to
provide in a basic user interface, and which to provide through
progressive disclosure to advanced users. UAAG 2.0 has many options that
can be managed through preference settings."</td>
<td align="left" valign="top"><span class="done">[done]</span> </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"><a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Levels of Conformance</td>
<td align="left" valign="top">EO10: This section jumps around. The heading is "Levels of Conformance" but only the first section is about conformance. See <a rel="nofollow" href="http://www.w3.org/WAI/EO/wiki/UAAG_review#Levels_of_Conformance_.28Implementing.29">levels comments on Implementing below</a>. Maybe this section should stay "Levels of Conformance" and contain only the following.</td>
<td align="left" valign="top"><span class="done">[done]</span> </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Definition of User Agent</td>
<td align="left" valign="top">OP01: On a higher level, the definition of 'User Agent' is too broad. More
specifically, 'web based user agents' are essentially websites, and
thus should comply by the WCAG guidelines rather than the UAAG. So let
us please keep 'web based user agents' which are essentially web
apps/webs sites out of the definition of a 'User Agent'.</td>
<td align="left" valign="top"><span class="done">[done]</span> See <a href="#MS01">MS01</a></td>
<td align="left" valign="top">Not accepted</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top">Introduction: Definition of User Agent</td>
<td align="left" valign="top"><a name="MS01" id="MS01"></a>MS01: <strong>Definition of “User agent” should not include “web-based user agent”</strong>
<p>We are strongly opposed to the interpretation that web content such
as online translation services, email services, and document authoring
services should be included as user agents. These services, when
consumed via the web, are web content and should consult WCAG 2.0, not
UAAG 2.0 for accessibility guidance. Adding UAAG 2.0 to the mix of
applicable guidance to web content already applicable with WCAG 2.0
makes it confusing for content producers to determine which W3C
accessibility guideline to follow. It also makes the already muddled
UAAG 2.0 even more so by diluting focus from its primary goal of
outlining accessibility guidance for web browsers. Microsoft urges the
working group to revise the definition of user agent accordingly and
to remove all draft language related to the notion that web services
can be considered user agents.</p></td>
<td align="left" valign="top"><p><span class="done">[done]</span> In order to clarify the relationship between UAAG 2.0 and WCAG 2.0 (and ATAG 2.0) UAWG has added 2 new sections to the Guidelines document Introduction: <br />
-Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0 and <br />
-Relationship to the Authoring Tool Accessibility Guidelines (ATAG) 2.0</p>
<p>
For the following reasons, UAWG continues to believe that keeping web-based user agents in the scope of UAAG is reasonable and important: <br />
<br />
- from the perspective of users needing accessibility features (e.g. zoom, media navigation, etc.) it is not always clear whether a user agent is web-based or native, especially as browsers and operating systems converge. <br /><br />
- UAAG does allow web-based user agents to depend on the base (native) user agent in order to meet UAAG success criteria, just as non-web-based user agents can rely on operating system features (e.g. to programmatically communicate with assistive technology) <br /><br />
- the web-based user agent may be best placed to provide UAAG conformant functionality. For example a web-based video player may only be serving small portions of a video to the base browser's video player, so the base browser would not be able to provide effective navigation of the video. Similarly, a web-based user agent can zoom its content and keep its own user interface the same size, saving screen real estate, while the base browser's zoom function may zoom the web-based browser's user interface, leaving less space for the content. </p>
<p>
Instead of de-scoping web-based user agents, UAWG will continue to identify exemptions from specific success criteria where necessary (e.g. due to technical limitations).</p></td>
<td align="left" valign="top">Partial accept</td>
<td align="left" valign="top">substantive</td>
<td align="left" valign="top"> </td>
</tr>
<tr class="h1">
<td align="left" valign="top"> </td>
<td align="left" valign="top">UAAG 2.0 Guidelines</td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top">EO11: <strong>Question:</strong> is there a reason why "normative" is not linked to a definition and "informative" is? Or is it an oversight? </td>
<td align="left" valign="top"><span class="done">[done]</span> It was a coding error. The definition was linked, but it was not working correctly. </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">Question</td>
<td align="left" valign="top"> </td>
</tr>
<tr class="h1">
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><h2>UAAG 2.0 Conformance Applicability Notes</h2></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
</tr>
<tr>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><strong>Recognized Content Only</strong> UAAG 2.0 success criteria only apply to web content and its behaviors that can be recognized by user agents.</td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
</tr>
<tr>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><strong>Optional Settings:</strong>
Throughout UAAG 2.0, all required behaviors may be provided as optional
preference settings unless a success criterion explicitly says
otherwise. For example, if a success criteria requires high contrast
between foreground text and its background, the user agent may also
provide choices with low contrast. A required behavior does not need to
be the default option unless the success criteria explicitly says
otherwise.</td>
<td align="left" valign="top">JO08: #8: UAAG 2.0 Conformance Applicability Notes:
Commas needed:
" UAAG 2.0 success criteria only apply to web content, and its
behaviors, that can be recognized by user agents."
#8: Under "UAAG 2.0 Conformance Applicability Notes:"
Could the Optional Setting text be changed to say that there is a
preference (if this is the case, but I can't see why wouldn't be) for
having a required behavior as a default option (where possible. For example:
"Optional Settings: Throughout UAAG 2.0, all required behaviors may be
provided as optional preference settings unless a success criterion
explicitly says otherwise. [...] While it is preferred to have a
required behavior as a default option, it does not need to be, unless
the success criteria explicitly says otherwise."<br /></td>
<td align="left" valign="top"><span class="done">[done]</span> Additional commas would not be grammatically correct. The Optional setting text was changed as suggested. <br /></td>
<td align="left" valign="top">Partial accept<br /></td>
<td align="left" valign="top">editorial<br /></td>
<td align="left" valign="top">
<a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><p>EH02: #2 Optional Settings - @@Throughout UAAG 2.0, all required behaviors@@ - could be “All behaviors required by UAAG 2.0”…
</p>
<div>
<div> </div>
</div></td>
<td align="left" valign="top"><span class="done">[done]</span></td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>Optional Settings:</strong></td>
<td align="left" valign="top">EH03: #2 @@if a success criteria@@ should be "if a success criterion</td>
<td align="left" valign="top" > <span class="done">[done]</span> </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><strong>RFC 2119 language not used:</strong>
UAAG 2.0 does not use RFC 2119 language (must, may, should) because
these are guidelines and not interoperable specifications. These words
in UAAG 2.0 don't have the same sense as they do in RFC 2119.</td>
<td align="left" valign="top">JO09: #9:
This is a little confusing:
"RFC 2119 language not used: UAAG 2.0 does not use RFC 2119 language
(must, may, should) because these are guidelines and not interoperable
specifications. These words in UAAG 2.0 don't have the same sense as
they do in RFC 2119."
While UAAG says it doesn't use RFC 2119 language, it obviously these
words but with non normative implication. To say they don't have the
same 'sense', could be improved.
How about?
"RFC 2119 language not used: UAAG 2.0 does not use RFC 2119 language
(must, may, should) as it is not an interoperable specification. Note,
even if these terms appear from time to time they do not have any RFC
2119 implication. " or similar.<br /></td>
<td align="left" valign="top"><span class="done">[done]</span> See EH04<br /></td>
<td align="left" valign="top">Accept<br /></td>
<td align="left" valign="top">editorial<br /></td>
<td align="left" valign="top">
<a href="http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Sep/0012.html">Accepted</a></td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>RFC 2119 language not used</strong></td>
<td align="left" valign="top">Suggest a link from "<a rel="nofollow" href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>" to a glossary item</td>
<td align="left" valign="top"><span class="done">[done]</span> definition added </td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"> </td>
<td align="left" valign="top"><strong>RFC 2119 language not used</strong></td>
<td align="left" valign="top">EH04: #3 @@have the same sense@@<br />
If they (must, may, should) have special meaning, do we need to say what the meaning is?</td>
<td align="left" valign="top"><span class="done">[done]</span> changed to "These words in UAAG 2.0 don't have the stricter meaning as they do in RFC 2119."</td>
<td align="left" valign="top">Accept</td>
<td align="left" valign="top">editorial</td>
<td align="left" valign="top"> </td>
</tr>
<tr>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><strong>Simultaneous satisfaction of success criteria:</strong>
Users can access all behaviors required by UAAG 2.0 at the same time
(e.g. when the user resizes the viewport per 1.8.9, content is
reflowed per 1.8.6), except where those behaviors are mutually
exclusive.</td>
<td align="left" valign="top">EH05: @@User can access all behaviors@@<br />
Do you mean “Users must be able to access all behaviors”. Presently this is not clear.</td>
<td align="left" valign="top"><span class="done">[done]</span> not accepted. "The user can" is the stylist phrase UAAG uses. <br /></td>
<td align="left" valign="top">Not Accepted<br /></td>
<td align="left" valign="top">editorial<br /></td>
<td align="left" valign="top"><br /></td>
</tr>
<tr class="h1">
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><h2>PRINCIPLE 1</h2> - Ensure that the user interface and rendered content are <strong>perceivable</strong></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
</tr>
<tr class="h2">
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><h3>Guideline 1.1 - Provide access to alternative content </h3></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><br /></td>
</tr>
<tr>
<td align="left" valign="top"><br /></td>
<td align="left" valign="top"><strong>Summary: </strong>The user
can choose to render any type of alternative content available. (1.1.1).
The user can also choose at least one alternative such as alt text to
be always displayed (1.1.3), but it's recommended that users also be
able to specify a cascade (1.1.5), such as alt text if it's there,
otherwise longdesc, otherwise filename, etc. It's recommended that the
user can configure the caption text and that text or sign language
alternative cannot obscure the video or the controls (1.1.4). The user
can configure the size and position of media alternatives (1.1.6).</td>
<td align="left" valign="top">JO10: Under Guideline 1.1, Summary. Move (1.1.1) so it is before the period.
"Summary: The user can choose to render any type of alternative content
available (1.1.1). "
The summary is a little hard to parse. I'm suggesting some
punctuation/edits as follows:
"Summary: The user can choose to render any type of alternative content
available (1.1.1). The user can also choose, at least one alternative
such as alt text, to be always displayed (1.1.3). It's recommended that