-
Notifications
You must be signed in to change notification settings - Fork 266
/
guide-to-wcag2-src.xml
798 lines (797 loc) · 64.1 KB
/
guide-to-wcag2-src.xml
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE spec
SYSTEM "xmlspec.dtd">
<spec status="int-review" w3c-doctype="review" role="editors-copy" xmlns:xi="http://www.w3.org/2001/XInclude">
<header>
<title>Understanding <abbr expansion="Web Content Accessibiity Guidelines">WCAG</abbr> 2.0</title>
<subtitle>A guide to understanding and implementing Web Content Accessibility Guidelines 2.0</subtitle>
<version/>
<w3c-designation>UNDERSTANDING-WCAG20</w3c-designation>
<w3c-doctype>Editors' Draft</w3c-doctype>
<pubdate>
<day>28</day>
<month>October</month>
<year>2016</year>
</pubdate>
<publoc>
<loc href="http://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20160913/">http://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20160913/</loc>
<!--<loc href="http://www.w3.org/WAI/GL/2016/WD-UNDERSTANDING-WCAG20-20160719/">http://www.w3.org/WAI/GL/2016/WD-UNDERSTANDING-WCAG20-20160719/</loc>-->
</publoc>
<altlocs>
<loc href="complete.html">Single file version</loc>
<loc href="complete-diff.html">Single file diff-marked version showing revisions since 17 March 2015</loc>
<loc href="/WAI/WCAG20/versions/understanding/">Alternate Versions of Understanding WCAG 2.0</loc>
</altlocs>
<latestloc>
<loc href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/">http://www.w3.org/TR/UNDERSTANDING-WCAG20/</loc>
<!--<loc href="http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/">http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/</loc>-->
</latestloc>
<prevlocs>
<loc href="http://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20160317/">http://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20160317/</loc>
<!-- <loc href="http://www.w3.org/WAI/GL/2016/WD-UNDERSTANDING-WCAG20-20160105/">http://www.w3.org/WAI/GL/2016/WD-UNDERSTANDING-WCAG20-20160105/</loc>-->
</prevlocs>
<authlist>
<author role="current">
<name>Michael Cooper</name>
<affiliation>W3C</affiliation>
</author>
<author role="current">
<name>Andrew Kirkpatrick</name>
<affiliation>Adobe Systems Inc.</affiliation>
</author>
<author role="current">
<name>Joshue O Connor</name>
<affiliation>InterAccess</affiliation>
</author>
<author role="past">
<name>Loretta Guarino Reid</name>
<affiliation>(until May 2013 while at Google, Inc.)</affiliation>
</author>
<author role="past">
<name>Gregg Vanderheiden</name>
<affiliation>(until May 2013 while at Trace R&D Center, University of
Wisconsin-Madison)</affiliation>
</author>
<author role="past">
<name>Ben Caldwell</name>
<affiliation>(until September 2010 while at Trace R&D Center, University of
Wisconsin-Madison)</affiliation>
</author>
<author role="past">
<name>Wendy Chisholm</name>
<affiliation>(until July 2006 while at W3C)</affiliation>
</author>
<author role="past">
<name>John Slatin</name>
<affiliation>(until June 2006 while at Accessibility Institute, University of Texas at
Austin)</affiliation>
</author>
</authlist>
<status>
<p>
<emph>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <loc href="http://www.w3.org/TR/">W3C technical reports index</loc> at <loc href="http://www.w3.org/TR/">http://www.w3.org/TR/</loc>.</emph>
</p>
<p>This is a <phrase role="final">Working Group Note</phrase>
<phrase role="ext-review">Public Editors' Draft of</phrase><phrase role="int-review">Editors' Draft of</phrase> "Understanding WCAG 2.0". The <loc href="http://www.w3.org/WAI/GL/">Web Content Accessibility Guidelines Working Group</loc> considers this document to be important for understanding the success criteria in the <loc href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/">Web Content Accessibility Guidelines (WCAG) 2.0 Recommendation</loc>. Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.0).</p>
<p>Understanding WCAG 2.0 was previously published on 11 December 2008 as a Working Group Note and updated 14 October 2010, 3 January 2012, 5 September 2013, 3 March 2014, 8 April 2014, 16 September 2014, 26 February 2015, and 17 March 2016. This new version updates the support information provided for WCAG 2.0. Note that WCAG 2.0 itself remains unchanged, only the informative support materials have been updated. The only change in this version is to <loc href="conformance.html#uc-partial-third-head">add explanation about partial conformance claims due to third-party content</loc>.</p>
<p><phrase role="ext-review">The purpose of this draft is to collect public feedback on proposed changes since the <loc href="http://www.w3.org/TR/2015/NOTE-UNDERSTANDING-WCAG20-20150226/">Understanding WCAG 2.0 Working Group Note of 26 February 2015</loc>. The Working Group intends to publish an updated Note once feedback from this review has been incorporated. <emph role="bold">The existing Understanding document remains in place as a W3C Note</emph> while this separate draft update is under review and the WCAG Working Group addresses comments.</phrase> The changes are highlighted in the <loc href="complete-diff">diff-marked version</loc>.</p>
<p>
<phrase role="ext-review">Comments on this draft are due <emph role="bold">on or before 29 January 2016</emph>.</phrase> The Working Group requests that any comments be made using the options documented in <loc href="http://www.w3.org/WAI/WCAG20/comments/">Instructions for Commenting on WCAG 2.0 Documents</loc>. If this is not possible, comments can also be sent to <loc href="mailto:[email protected]">[email protected]</loc>. The <loc href="http://lists.w3.org/Archives/Public/public-comments-wcag20/">archives for the public comments list</loc> are publicly available. <phrase role="ext-review">Because this is a public review of changes to the Working Group Notes, only comments on changes made since the last Notes will be processed during this review; other comments will be saved and treated as comments on the updated Notes once published. </phrase><phrase role="final">Comments received on this document may be addressed in future versions of this document, or in another manner. </phrase><!--The Working Group does not plan to make formal responses to comments.--> Archives of the <loc href="http://lists.w3.org/Archives/Public/w3c-wai-gl/">WCAG WG mailing list discussions</loc> are also publicly available, and future work undertaken by the Working Group may address comments received on this document.</p>
<p>This document has been produced as part of the W3C <loc href="http://www.w3.org/WAI/">Web Accessibility Initiative</loc> (WAI). The goals of the WCAG Working Group are discussed in the <loc href="http://www.w3.org/WAI/GL/charter">WCAG Working Group charter</loc>. The WCAG Working Group is part of the <loc href="http://www.w3.org/WAI/Technical/Activity">WAI Technical Activity</loc>.</p>
<p> Publication as a <phrase role="final">Working Group Note</phrase>
<phrase role="ext-review">Public Editors' Draft</phrase><phrase role="int-review">Editors' Draft</phrase> does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. </p>
<p>This document was produced by a group operating under the <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</loc>. W3C maintains a <loc role="disclosures"
href="http://www.w3.org/2004/01/pp-impl/35422/status">public list of any patent disclosures</loc> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</loc> must disclose the information in accordance with <loc href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</loc>. </p>
<p>This document is governed by the <loc id="w3c_process_revision" href="http://www.w3.org/2015/Process-20150901/">1 September 2015 W3C Process Document</loc>. </p>
</status>
<abstract>
<p>This document, "Understanding WCAG 2.0," is an essential guide to understanding and using <loc href="http://www.w3.org/TR/WCAG20/">Web Content Accessibility Guidelines (WCAG) 2.0</loc>
<bibref ref="WCAG20"/>. It is part of a series of documents that support WCAG 2.0. Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.0). See <loc href="http://www.w3.org/WAI/intro/wcag.php">Web Content Accessibility Guidelines (WCAG) Overview</loc> for an introduction to WCAG, supporting technical documents, and educational material.</p>
<p>WCAG 2.0 establishes a set of Success Criteria to define conformance to the WCAG 2.0 Guidelines. A Success Criterion is a testable statement that will be either true or false when applied to specific Web content. "Understanding WCAG 2.0" provides detailed information about each Success Criterion, including its intent, the key terms that are used in the Success Criterion, and how the Success Criteria in WCAG 2.0 help people with different types of disabilities. This document also provides examples of Web content that meet the success criterion using various Web technologies (for instance, HTML, CSS, XML), and common examples of Web content that does not meet the success criterion. </p>
<p>This document indicates specific techniques to meet each Success Criterion. Details for how to implement each technique are available in <loc href="http://www.w3.org/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc>, but "Understanding WCAG 2.0" provides the information about the relationship of each technique to the Success Criteria. Techniques are categorized by the level of support they provide for the Success Criteria. "Sufficient techniques" are <emph>sufficient</emph> to meet a particular Success Criterion (either by themselves or in combination with other techniques), while other techniques are advisory and therefore optional. None of the techniques are <emph>required</emph> to meet WCAG 2.0, although some may be the only known method if a particular technology is used. "Advisory techniques" are not sufficient to meet the Success Criteria on their own (because they are not testable or provide incomplete support) but it is encouraged that authors follow them when possible to provide enhanced accessibility. </p>
<p>In addition to techniques for addressing the success criteria, "Common Failures" are also documented. These "Common Failures" are authoring practices that are known to cause Web content to fail to conform to WCAG 2.0. Authors must avoid those practices in order to meet the WCAG 2.0 Success Criteria.</p>
<p>This document is part of a series of documents published by the W3C Web Accessibility Initiative (WAI) to support WCAG 2.0. This document was published as a Working Group Note at the same time WCAG 2.0 was published as a W3C Recommendation. Unlike WCAG 2.0, is expected that the information in Understanding WCAG 2.0 will be updated from time to time. See <loc href="http://www.w3.org/WAI/intro/wcag.php">Web Content Accessibility Guidelines (WCAG) Overview</loc> for an introduction to WCAG, supporting technical documents, and educational material.</p>
</abstract>
<langusage>
<language id="en-US"/>
</langusage>
<revisiondesc>
<p>
<loc href="/WAI/GL/WCAG20/change-history.html">History of Changes to WCAG 2.0 Working Drafts</loc>
</p>
</revisiondesc>
</header>
<front>
<div1 id="intro">
<head>Introduction to Understanding WCAG 2.0</head>
<div2 role="suppressed" id="introduction">
<head>Intro</head>
<p>Understanding WCAG 2.0 is an essential guide to understanding and using "Web Content Accessibility Guidelines 2.0" <bibref ref="WCAG20"/> Although the normative definition and requirements for WCAG 2.0 can all be found in the WCAG 2.0 document itself, the concepts and provisions may be new to some people. Understanding WCAG 2.0 provides a non-normative extended commentary on each guideline and each Success Criterion to help readers better understand the intent and how the guidelines and Success Criteria work together. It also provides examples of techniques or combinations of techniques that the Working Group has identified as being sufficient to meet each Success Criterion. Links are then provided to write-ups for each of the techniques.</p>
<p>This is not an introductory document. It is a detailed technical description of the guidelines and their Success Criteria. See <loc href="http://www.w3.org/WAI/intro/wcag.php">Web Content Accessibility Guidelines (WCAG) Overview</loc> for an introduction to WCAG, supporting technical documents, and educational material.
</p>
<p>Understanding WCAG 2.0 is organized by guideline. There is an <emph>Understanding Guideline X.X</emph> section for each guideline. The intent and any advisory techniques that are related to the guideline but not specifically related to any of its Success Criteria are listed there as well.</p>
<p>The <emph>Understanding Guidelines X.X</emph> section is then followed by a <emph>Understanding Success Criterion X.X.X</emph> section for each Success Criterion of that guideline. These sections each contain:</p>
<ulist>
<item>
<p>The Success Criterion as it appears in WCAG 2.0</p>
</item>
<item>
<p>Intent of the Success Criterion</p>
</item>
<item>
<p>Benefits (how the Success Criterion helps people with disabilities)</p>
</item>
<item>
<p>Examples</p>
</item>
<item>
<p>
Related Resources
</p>
</item>
<item>
<p>Techniques or combinations of techniques that are sufficient to meet the guidelines</p>
</item>
<item>
<p>Common failures of this Success Criterion</p>
</item>
<item>
<p>Additional advisory techniques that go beyond what is required to meet the Success Criterion but can be used to make some or all types of content more accessible. Use of advisory techniques does not impact the level of conformance claimed.
</p>
</item>
<item>
<p>Key terms for this Success Criterion (taken from the WCAG 2.0 Glossary)</p>
</item>
</ulist>
<p>Links are provided from each Guideline in WCAG 2.0 directly to each <emph>Understanding Guideline X.X</emph> in this document. Similarly, there is a link from each Success Criterion in WCAG 2.0 to the <emph>Understanding Success Criterion X.X.X</emph> section in this document. </p>
<p>For information about individual techniques, follow the links throughout this document to the techniques of interest in the <loc href="/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc> document.</p>
<p>For links to information on different disabilities and assistive technologies see <loc href="https://en.wikipedia.org/wiki/Disability">Disabilities on Wikipedia</loc>.
</p>
<div3 id="fourprincs" role="normal">
<head>Understanding the Four Principles of Accessibility</head>
<p>The guidelines and Success Criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:</p>
<olist>
<item>
<p> Perceivable - Information and user interface components must be presentable to users in ways they can perceive.</p>
<ulist>
<item>
<p>This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)</p>
</item>
</ulist>
</item>
<item>
<p>Operable - User interface components and navigation must be operable.</p>
<ulist>
<item>
<p>This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform) </p>
</item>
</ulist>
</item>
<item>
<p>Understandable - Information and the operation of user interface must be understandable.</p>
<ulist>
<item>
<p>This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)</p>
</item>
</ulist>
</item>
<item>
<p>Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.</p>
<ulist>
<item>
<p>This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)</p>
</item>
</ulist>
</item>
</olist>
<p>If any of these are not true, users with disabilities will not be able to use the Web. </p>
<p>Under each of the principles are guidelines and Success Criteria that help to address these principles for people with disabilities. There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG 2.0, we only include those guidelines that address problems particular to people with disabilities. This includes issues that block access or interfere with access to the Web more severely for people with disabilities.</p>
</div3>
<div3 id="layers" role="normal">
<head>Layers of Guidance</head>
<div4 id="layers-guidelines" role="normal">
<head>The Guidelines</head>
<p>Under each principle there is a list of guidelines that address the principle. There are a total of 12 guidelines. A convenient list of just the guidelines can be found in the <loc href="contents"
linktype="guideline">WCAG 2.0 table of contents</loc>. One of the key objectives of the guidelines is to ensure that content is directly accessible to as many people as possible, and capable of being re-presented in different forms to match different peoples' sensory, physical and cognitive abilities.</p>
</div4>
<div4 id="layers-sc" role="normal">
<head>Success Criteria</head>
<p>Under each guideline, there are Success Criteria that describe specifically what must be achieved in order to <loc href="conformancedef"
linktype="guideline">conform</loc> to this standard. They are similar to the "checkpoints" in WCAG 1.0. Each Success Criterion is written as a statement that will be either true or false when specific Web content is tested against it. The Success Criteria are written to be technology neutral.</p>
<p>All WCAG 2.0 Success Criteria are written as testable criteria for objectively determining if content satisfies the Success Criteria. While some of the testing can be automated using software evaluation programs, others require human testers for part or all of the test.</p>
<p>Although content may satisfy the Success Criteria, the content may not always be usable by people with a wide variety of disabilities. Professional reviews utilizing recognized qualitative heuristics are important in achieving accessibility for some audiences. In addition, usability testing is recommended. Usability testing aims to determine how well people can use the content for its intended purpose.</p>
<p>The content should be tested by those who understand how people with different types of disabilities use the Web. It is recommended that users with disabilities be included in test groups when performing human testing.
</p>
<p>Each Success Criterion for a guideline has a link to the section of the How to Meet document that provides:</p>
<ulist>
<item>
<p>sufficient techniques for meeting the Success Criterion,</p>
</item>
<item>
<p>optional advisory techniques, and</p>
</item>
<item>
<p>descriptions of the intent of the Success Criteria, including benefits, and examples.</p>
</item>
</ulist>
</div4>
<div4 id="layers-techs" role="normal">
<head>Sufficient Techniques, Advisory Techniques, and Failures</head>
<p>The next section, <specref ref="understanding-techniques"/>, provides important information about the techniques.</p>
</div4>
</div3>
</div2>
</div1>
<div1 id="understanding-techniques">
<head>Understanding Techniques for WCAG Success Criteria</head>
<div2 id="ut" role="suppressed">
<head>Understanding Techniques for WCAG Success Criteria (suppressed)</head>
<p>WCAG 2.0 guidelines and success criteria are designed to be broadly applicable to current and future web technologies, including dynamic applications, mobile, digital television, etc. They are stable and do not change.</p>
<p>Specific guidance for authors and evaluators on meeting the WCAG success criteria is provided in techniques, which include code examples, resources, and tests. W3C's <loc href="/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc> document is updated periodically, about <phrase>twice per</phrase> year, to cover more current best practices and changes in technologies and tools.</p>
<p>The three types of guidance in <loc href="/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc> are explained below:</p>
<ulist>
<item>
<p>Sufficient techniques</p>
</item>
<item>
<p>Advisory techniques</p>
</item>
<item>
<p>Failures</p>
</item>
</ulist>
<p>Also explained below:</p>
<ulist>
<item>
<p>General and technology-specific techniques - which can be sufficient or advisory</p>
</item>
<item>
<p>Other techniques - beyond what is in W3C's published document</p>
</item>
<item>
<p>Technique tests</p>
</item>
<item>
<p>User agent and assistive technology support</p>
</item>
<item>
<p>Using the techniques - with important considerations</p>
</item>
</ulist>
<p>
<loc href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance">Understanding Conformance</loc> provides related information, including on <loc href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance#uc-accessibility-support-head">understanding accessibility support</loc>.</p>
<div3 id="understanding-techniques-informative" role="normal">
<head>Techniques are Informative</head>
<p>
<emph role="strong">Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard—not the techniques.</emph>
</p>
<note>
<p>W3C cautions against requiring W3C's sufficient techniques. The only thing that should be required is meeting the WCAG 2.0 success criteria. To learn more, see:</p>
<ulist>
<item>
<p>
<loc href="http://www.w3.org/WAI/WCAG20/wcag2faq.html#techsnot">What would be the negative consequences of allowing <emph>only</emph> W3C's published techniques to be used for conformance to WCAG 2.0?</loc> in the WCAG 2 FAQ</p>
</item>
<!--
<item>
<p>
<loc href="http://www.w3.org/2013/02/stdref">Normative References to W3C Standards</loc>
<span class="quiet">[@@ Ian asks that we not point to this for now.]</span>
</p>
</item>
-->
</ulist>
<p>
<loc href="/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc> uses the words "must" and "should" only to clarify guidance within the techniques, not to convey requirements for WCAG.</p>
</note>
</div3>
<div3 id="understanding-techniques-sufficient" role="normal">
<head>Sufficient Techniques</head>
<p>
<emph>Sufficient techniques</emph> are reliable ways to meet the success criteria.</p>
<ulist>
<item>
<p>From an author's perspective: If you use the sufficient techniques for a given criterion correctly and it is <loc href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head">accessibility-supported</loc> for your users, you can be confident that you met the success criterion.</p>
</item>
<item>
<p>From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is <loc href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head">accessibility-supported</loc> for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in <loc href="#ut-understanding-techniques-tests-head">Testing Techniques</loc> below.)</p>
</item>
</ulist>
<p>There may be other ways to meet success criteria besides the sufficient techniques in W3C's <loc href="/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc> document, as explained in <loc href="#ut-understanding-techniques-othertechs-head">Other Techniques</loc> below. <emph>(See also <loc href="#ut-understanding-techniques-informative-head">Techniques are Informative</loc> above.)</emph>
</p>
<div4 id="understanding-techniques-sufficient-lists-and" role="normal">
<head>Numbered Lists, "AND"</head>
<p> The W3C-documented sufficient techniques are provided in a numbered list where each list item provides a technique or combination of techniques that can be used to meet the success criterion. Where there are multiple techniques on a numbered list item connected by "AND" then all of the techniques must be used to be sufficient. For example, <loc href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/complete#content-structure-separation-programmatic-techniques-head">Sufficient Techniques for 1.3.1</loc> has: "G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)".</p>
</div4>
</div3>
<div3 id="understanding-techniques-advisory" role="normal">
<head>Advisory Techniques</head>
<p>
<emph>Advisory techniques</emph> are suggested ways to improve accessibility. They are often very helpful to some users, and may be the only way that some users can access some types of content.</p>
<p>Advisory techniques are not designated as sufficient techniques for various reasons such as:</p>
<ulist>
<item>
<p>they may not be sufficient to meet the full requirements of the success criteria;</p>
</item>
<item>
<p>they may be based on technology that is not yet stable;</p>
</item>
<item>
<p>they may not be <loc href="http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head">accessibility supported</loc> in many cases (for example, assistive technologies do not work with them yet);</p>
</item>
<item>
<p>they may not be testable;</p>
</item>
<item>
<p>in some circumstances they may not be applicable or practical, and may even decrease accessibility for some users while increasing it for others;</p>
</item>
<item>
<p>they may not address the success criterion itself, and instead provide related accessibility benefits.</p>
</item>
</ulist>
<p>Authors are encouraged to apply all of the techniques where appropriate to best address the widest range of users' needs.</p>
</div3>
<div3 id="understanding-techniques-failures" role="normal">
<head>Failures</head>
<p>
<emph>Failures</emph> are things that cause accessibility barriers and fail specific success criteria. The documented <emph>failures</emph> are useful for:</p>
<ulist>
<item>
<p>Authors to know what to avoid,</p>
</item>
<item>
<p>Evaluators to use for checking if content does not meet WCAG success criteria.</p>
</item>
</ulist>
<p>Content that has a <emph>failure</emph> does not meet WCAG success criteria, unless an alternate version is provided without the failure.</p>
<p>If anyone identifies a situation where a documented failure is not correct, please <loc href="http://www.w3.org/WAI/WCAG20/comments/">report the situation as a WCAG comment</loc> so that it can be corrected or deleted as appropriate.</p>
</div3>
<div3 id="understanding-techniques-general-tech-specific" role="normal">
<head> General and Technology-specific Techniques</head>
<p>
<emph>General techniques</emph> describe basic practices that apply to all technologies. <emph>Technology-specific techniques</emph> apply to a specific technology.</p>
<p>Some success criteria do not have technology-specific techniques and are covered only with general techniques. Therefore, both the general techniques and the relevant technology-specific techniques should be considered.</p>
<p>Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.0 success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.</p>
</div3>
<div3 id="understanding-techniques-othertechs" role="normal">
<head>Other Techniques</head>
<p>In addition to the techniques in W3C's <loc href="/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc> document, <emph role="strong">there are other ways to meet WCAG success criteria</emph>. W3C's techniques are not comprehensive and may not cover newer technologies and situations.</p>
<p>
<emph role="strong">Web content does not have to use W3C's published techniques in order to conform to WCAG 2.0.</emph>
<emph>(See also <loc href="#ut-understanding-techniques-informative-head">Techniques are Informative</loc> above.)</emph>
</p>
<p>Content authors can develop different techniques. For example, an author could develop a technique for HTML5, <loc href="http://www.w3.org/WAI/intro/aria">WAI-ARIA</loc>, or other new technology. Other organizations may develop sets of techniques to meet WCAG 2.0 success criteria.</p>
<p>Any techniques can be sufficient if:</p>
<ulist>
<item>
<p>they satisfy the success criterion, and</p>
</item>
<item>
<p> all of the <loc href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html">WCAG 2.0 conformance requirements</loc> are met.</p>
</item>
</ulist>
<div4 id="understanding-techniques-submitting" role="normal">
<head>Submitting Techniques</head>
<p>The WCAG Working Group encourages people to submit new techniques so that they can be considered for inclusion in updates of the <loc href="/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc> document. Please submit techniques for consideration using the <loc href="http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/">Techniques Submission Form</loc>.</p>
</div4>
</div3>
<div3 id="understanding-techniques-tests" role="normal">
<head>Testing Techniques</head>
<p> Each technique has tests that help:</p>
<ulist>
<item>
<p> authors verify that they implemented the technique properly, and</p>
</item>
<item>
<p>evaluators determine if web content meets the technique.</p>
</item>
</ulist>
<p>The tests are only for a technique, they are not tests for conformance to WCAG success criteria.</p>
<ulist>
<item>
<p>Failing a technique test does not necessarily mean failing WCAG, because the techniques are discrete (that is, they address one specific point) and they are not required.</p>
</item>
<item>
<p>Content can meet WCAG success criteria in different ways other than W3C's published sufficient techniques.</p>
</item>
<item>
<p>Content that passes the sufficient techniques for a specific technology does not necessarily meet all WCAG success criteria. Some success criteria have only general techniques, not technology-specific techniques.</p>
</item>
<item>
<p>The content must be <loc href="http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head">accessibility supported</loc> for the content's users. Some sufficient techniques require browser, assistive technology, or other support that some users might not have.</p>
</item>
</ulist>
<p>Thus while the techniques are useful for evaluating content, evaluations must go beyond just checking the sufficient technique tests in order to evaluate how content conforms to WCAG success criteria.</p>
<p>
<emph>Failures</emph> are particularly useful for evaluations because they do indicate non-conformance (unless an alternate version is provided without the failure).</p>
</div3>
<div3 id="understanding-techniques-support" role="normal">
<head>User Agent and Assistive Technology Support Notes</head>
<p>Some techniques require that web content users have specific browsers or assistive technologies in order for the technique to be <loc href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head">accessibility-supported</loc>. The <emph role="strong">User Agent and Assistive Technology Support Notes</emph> sections of individual techniques include some information to help determine accessibility support.</p>
<div4 id="understanding-techniques-support-change" role="normal">
<head>Support Notes Change Over Time</head>
<p>As time passes, the versions of user agents (browsers, etc.) or assistive technologies listed may not be the current versions. The Working Group may not update most of these notes as new versions are released. Authors should test techniques with the user agents and assistive technologies currently available to their users. See also <loc href="http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head">Understanding Accessibility Support</loc>.</p>
</div4>
</div3>
<div3 id="understanding-techniques-using" role="normal">
<head>Using the Techniques</head>
<p>
<loc href="/TR/WCAG20-TECHS/">Techniques for WCAG 2.0</loc> is not intended to be used as a stand-alone document. Instead, it is expected that content authors will usually use <loc href="http://www.w3.org/WAI/WCAG20/quickref/">How to Meet WCAG 2.0: A customizable quick reference</loc> to read the WCAG success criteria, and follow links from there to specific topics in Understanding WCAG 2.0 and to specific techniques.</p>
<div4 id="understanding-techniques-using-alternatives" role="normal">
<head>Alternatives must meet success criteria</head>
<p>Some techniques describe how to provide alternate ways for users to get content. For example, <loc href="http://www.w3.org/TR/WCAG20-HTML-TECHS/G73">G73: Providing a long description in another location...</loc> mentions a transcript as an alternative for an audio file. Some alternatives must also conform to WCAG. For example, the transcript itself must meet all relevant success criteria. </p>
</div4>
<div4 id="understanding-techniques-using-examples" role="normal">
<head>Example Code</head>
<p>The code examples in the techniques are intended to demonstrate only the specific point discussed in the technique. They might not demonstrate best practice for other aspects of accessibility, usability, or coding not related to the technique. They are not intended to be copied and used as the basis for developing web content.</p>
<p>Many techniques point to "working examples" that are more robust and may be appropriate for copying and integrating into web content.</p>
</div4>
</div3>
</div2>
</div1>
</front>
<body>
<xi:include href="understanding/text-equiv.xml"/>
<xi:include href="understanding/media-equiv.xml"/>
<xi:include href="understanding/content-structure-separation.xml"/>
<xi:include href="understanding/visual-audio-contrast.xml"/>
<xi:include href="understanding/keyboard-operation.xml"/>
<xi:include href="understanding/time-limits.xml"/>
<xi:include href="understanding/seizure.xml"/>
<xi:include href="understanding/navigation-mechanisms.xml"/>
<xi:include href="understanding/meaning.xml"/>
<xi:include href="understanding/consistent-behavior.xml"/>
<xi:include href="understanding/minimize-error.xml"/>
<xi:include href="understanding/ensure-compat.xml"/>
<xi:include href="understanding/conformance.xml"/>
</body>
<back>
<inform-div1 id="conformance-referencing">
<head>How to refer to WCAG 2.0 from other documents</head>
<p>The following examples show how to reference WCAG 2.0 in various situations. For additional guidance, see <loc href="http://www.w3.org/WAI/intro/linking.html">Referencing and Linking to WAI Guidelines and Technical Documents</loc>.</p>
<p>
Please note that the
following language for referencing WCAG 2.0 can be inserted into your own
documents.
</p>
<div2 role="normal" id="conformance-referencing-information">
<head>Information references</head>
<p>When referencing WCAG 2.0 in an informational fashion, the following format can be used.</p>
<p>
<emph>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year (http://www.w3.org/TR/200X/REC-WCAG20-20081211/, Latest version at http://www.w3.org/TR/WCAG20/)</emph>
</p>
</div2>
<div2 role="normal" id="conformance-referencing-should">
<head>When referring to WCAG 2.0 from another standard with a "should" statement</head>
<p>When referencing WCAG 2.0 from within a <emph role="bold">should</emph> statement in a standard (or advisory statement in a regulation), then the full WCAG 2.0 should be referenced. This would mean that all three levels of WCAG 2.0 should be considered but that none are required. The format for referencing WCAG 2.0 from a "should" statement therefore, is:</p>
<p>
<emph>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)</emph>
</p>
</div2>
<div2 role="normal" id="conformance-referencing-must">
<head>When referring to WCAG 2.0 from another standard with a "shall or must" statement</head>
<p>When citing WCAG 2.0 as part of a requirement (e.g., a <emph role="bold">shall or must
</emph> statement in a standard or regulation), the reference must include the specific parts of WCAG 2.0 that are intended to be required. When referencing WCAG 2.0 in this manner, the following rules apply:
</p>
<olist>
<item>
<p>Conformance at any level of WCAG 2.0 requires that all of the Level A Success Criteria be met. References to WCAG 2.0 conformance cannot be for any subset of Level A.
</p>
</item>
<item>
<p>Beyond Level A, a "shall or must" reference may include any subset of provisions in Levels AA and AAA. For example, "<emph>all of Level A and [some specific list of Success Criteria in Level AA and Level AAA]</emph>" be met.
</p>
</item>
<item>
<p>If Level AA conformance to WCAG 2.0 is specified, then all Level A and all Level AA Success Criteria must be met.</p>
</item>
<item>
<p>If Level AAA conformance to WCAG 2.0 is specified, then all Level A, all Level AA, and all Level AAA Success Criteria must be met.</p>
<note>
<p>It is not recommended that Level AAA conformance ever be required for entire sites as a general policy because it is not possible to satisfy all Level AAA Success Criteria for some content.
</p>
<p>The sets of Success Criteria defined in WCAG are interdependent and individual Success Criteria rely on each other's definitions in ways which may not be immediately obvious to the reader. Any set of Success Criteria must include all of the Level A provisions.</p>
</note>
</item>
</olist>
</div2>
<div2 role="normal" id="conformance-referencing-examples">
<head>Examples</head>
<p>
<emph role="bold">To cite only the Level A Success Criteria (Single-A conformance):</emph>
</p>
<p>
<emph>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)</emph>
</p>
<p>
<emph role="bold">To cite the Levels A and AA Success Criteria (Double-A conformance):</emph>
</p>
<p>
<emph>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A & Level AA Success Criteria. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)</emph>
</p>
<p>
<emph role="bold">To cite Level A Success Criteria and selected Success Criteria from Level AA and Level AAA: </emph>
</p>
<p>
<emph>Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)</emph>
</p>
<p>
<emph role="bold">Example of use of a WCAG reference in a "shall or must" statement.</emph>
</p>
<p>All Web content on publicly available Web sites shall conform to Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level A Success Criteria plus Success Criteria 1.2.4, 2.4.5-6, 3.1.2 (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)</p>
</div2>
<div2 role="normal" id="conformance-referencing-support">
<head>Referring to content from WCAG support documents</head>
<p>Techniques, which are listed in Understanding WCAG 2.0 and described in other supporting documents, are not part of the normative WCAG 2.0 Recommendation and should not be cited using the citation for the WCAG 2.0 Recommendation itself. References to techniques in support documents should be cited separately.</p>
<p>Techniques can be cited based on the individual Technique document or on the master WCAG 2.0 Techniques document. For example, the technique "Using alt attributes on img elements" could be cited as</p>
<p role="indent">
<emph>"Using alt attributes on img elements," W3C World Wide Web Consortium Note. (URI: {URI of technique}) </emph>
</p>
<p role="indent">or</p>
<p role="indent">
<emph>W3C World Wide Web Consortium (200x): WCAG2.0 HTML Techniques (URI: {URI of HTML Techniques})</emph>
</p>
<p role="indent">
<emph role="bold">Techniques are not designed to be referenced as "required"</emph> from any standard or regulation.Standards and regulations should not make any specific technique mandatory, though they may choose to recommend techniques.</p>
</div2>
</inform-div1>
<inform-div1 id="accessibility-support-documenting">
<head>Documenting Accessibility Support for Uses of a Web Technology</head>
<p>The documentation of accessibility support for uses of a Web technology provides the information needed to determine whether it is possible to satisfy the WCAG 2.0 Success Criteria for a particular environment. </p>
<p>Accessibility Support documentation for uses of a Web technology includes the following information: </p>
<ulist>
<item>
<p> The version or versions of the technology </p>
</item>
<item>
<p> For each user agent or plug-in that supports this version of the technology:</p>
<ulist>
<item>
<p> The version of the user agent or plug-in, including the operating system or platform </p>
</item>
<item>
<p> Ways of using the technology that are supported by the user agent; ideally, there are ways to meet all of the success criteria, but exceptions should be noted. </p>
</item>
<item>
<p> Known limitations of the user agent support for uses of the technology to meet Success Criteria
</p>
</item>
</ulist>
</item>
<item>
<p> For each assistive technology that supports the Web technology:</p>
<ulist>
<item>
<p> The version of the assistive technology, including the operating system or platform </p>
</item>
</ulist>
</item>
<item>
<p> For each host user agent that is supported by this version of the assistive technology:</p>
<ulist>
<item>
<p> Ways of using the technology supported by the assistive technology for this user agent </p>
</item>
<item>
<p> Known limitations in the support of uses of the technology to meet success criteria when using the assistive technology with this user agent </p>
</item>
</ulist>
</item>
</ulist>
<p>Target environments are defined by the user agents and assistive technologies available to its users. Documentation of accessibility support involves detailed understanding of the ways to use functionality of a technology to meet success criteria, and also of user agents and assistive technology. Because of this, vendors and developers of Web technologies and user agents are encouraged to provide this information about the accessibility support of their products. Similarly, developers and vendors of assistive technology are encouraged to provide this information about the ways to use Web technologies that are supported by their products. Authors should need to document the accessibility supported ways to use a technology only when there is not reliable documentation available from vendors or testing groups for those uses. </p>
<p>For a controlled environment, such as a corporate workplace, the user agents and assistive technologies available may be a specific set of versions of user agents on a specific set of platforms. To determine whether uses of a Web technology are accessibility supported in a target environment, an author checks that the user agents and assistive technologies available are in the set of supported user agents and assistive technologies listed for those uses in the Accessibility Support documentation. </p>
<p>For a target environment like the Internet, authors may need to consider a much larger set of user agents, including older versions, and on a wider variety of platforms. </p>
<p>Environments that use different natural languages are different target environments. For example, the accessibility-supported ways of using technologies for an English language environment may differ from those for an Arabic language environment, since there may be different user agents and assistive technologies that support these languages.</p>
<p>The documentation includes version-specific information about all the assistive technologies and all the user agents and the ways that they interact with one another. If support in these user agents is similar, it will be straightforward for an author to decide if a documented way of using a technology is accessibility supported. If the uses supported are different in different versions, authors can only rely on the uses that are supported in the versions available to their users in determining accessibility support. </p>
<p>If a way of using a technology is not relied upon for conformance, the absence of accessibility support for that use does not prevent conformance of the Web page. So if the unsupported use does not occur in the content, or if there is a conforming version of that content available, the Web page still conforms. For instance, lack of accessibility support for interactive controls in a Web technology would not prevent uses of the Web technology for non-interactive content that are accessibility supported. </p>
</inform-div1>
<inform-div1 id="understanding-metadata">
<head>Understanding Metadata</head>
<p>This section discusses metadata techniques that can be employed to satisfy WCAG 2.0 Success Criteria. For more information about metadata see resources below. </p>
<p>At its most basic level, metadata is essentially 'data about data' and is used to both describe and find resources. </p>
<p>Metadata is a powerful tool that can be used for describing Web pages and accessible components of Web pages as well as associating alternate versions of Web content to each other. These descriptions in turn allows users to locate specific information they need or prefer. </p>
<p>In conjunction with WCAG, metadata can play a number of roles including: </p>
<olist>
<item>
<p> Metadata can be used to associate conforming alternate versions of Web pages with Web pages which do not conform, in order to allow users to find the conforming alternate version when they land on a non-conforming page that they cannot use. </p>
</item>
<item>
<p> Metadata can be used to locate and also to describe alternate pages where there are multiple versions of a page which have been developed, especially where the alternate pages are optimized for individuals with different disabilities. The user can use the metadata both to locate the alternate versions and to identify characteristics of the versions, so that they can find the one that best meets their needs. </p>
</item>
<item>
<p>In addition to being used for whole pages (as in #1 and #2 above), metadata can be used to describe alternate versions of subcomponents of a page. Again, the metadata can be used to find alternate versions of a Web page component as well as to get descriptions of the alternate versions ( if there are several) in order to determine which one would best meet the user's needs. </p>
</item>
</olist>
<div2 role="normal" id="understanding-metadata-resources">
<head>Metadata Resources</head>
<p>Metadata descriptions often provide values from defined, agreed vocabularies such as the resource's subject matter or its date of publication, and are machine readable - software that understands the metadata scheme in use can do useful tasks not feasible otherwise. Typically, an object having metadata may have one or more such metadata descriptions. </p>
<p>Well-known specifications (schemas) for metadata include: </p>
<ulist>
<item>
<p>
<loc href="http://www.loc.gov/standards/mets/">Metadata Encoding and Transmission Standard (METS) scheme</loc>
</p>
</item>
<item>
<p>
<loc href="http://dublincore.org">Dublin Core Metadata Initiative (DCMI) terms for cross-disciplinary resources</loc>
</p>
</item>
<item>
<p>
<loc href="http://www.ieee.org/index.html">IEEE Standards</loc>
</p>
</item>
<!-- BBC: Commented out Dec. 2008 (broken linkserver non-responsive) item>
<p>
<loc href="http://jtc1sc36.org/Workgroups/Work%20Group%20Seven">ISO/IEC JTC1 Individualized Adaptability and Accessibility for Learning, Education and Training 24751</loc> otherwise known as the Access For All (AfA) Metadata </p>
</item-->
</ulist>
<p>There are some tools available to provide resource descriptions, or they can be provided manually. The more easily the metadata can be created and collected at point of creation of a resource or at point of publication, the more efficient the process and the more likely it is to take place. </p>
<p>Some examples include: </p>
<ulist>
<item>
<p>
<loc href="http://www.ukoln.ac.uk/metadata/dcdot/">DC-dot</loc>
</p>
</item>
</ulist>
<p>Accessibility metadata implementations include: </p>
<ulist>
<item>
<p>
<loc href="http://barrierfree.ca/tile/">The Inclusive Learning Exchange (TILE)</loc>
</p>
</item>
</ulist>
</div2>
<!--div2 role="normal">
<head>Metadata Techniques for WCAG 2.0</head>
<p>A [compilation of the metadata techniques for WCAG 2.0] is included in the techniques document </p>
</div2-->
</inform-div1>
<inform-div1 id="acknowledgements">
<head>Acknowledgements</head>
<p>This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and currently under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.</p>
<p>Additional information about participation in the Web Content Accessibility Guidelines Working Group (WCAG WG) can be found on the <loc href="http://www.w3.org/WAI/GL/">Working Group home page</loc>.
</p>
<div2 id="ack_participants-active" role="normal">
<head>Participants of the WCAG WG active in the development of this document:</head>
<ulist>
<item>
<p>Paul Adam (Deque)</p>
</item>
<item>
<p>Kathleen Anderson</p>
</item>
<item>
<p>Jon Avila (SSB Bart Group)</p>
</item>
<item>
<p>Bruce Bailey (U.S. Access Board) </p>
</item>
<item>
<p>Laura Carlson</p>
</item>
<item>
<p>Louis Cheng (Google)</p>
</item>
<item>
<p>Michael Cooper (W3C)</p>
</item>
<item>
<p>Wayne Dick</p>
</item>
<item>
<p>Eric Eggert (W3C)</p>
</item>
<item>
<p>Michael Elledge</p>
</item>
<item>
<p>Detlev Fischer</p>
</item>
<item>
<p>John Foliot (Deque)</p>
</item>
<item>
<p>Loretta Guarino Reid (Google)</p>
</item>
<item>
<p>Jon Gunderson</p>
</item>
<item>
<p>Katie Haritos-Shea</p>
</item>
<item>
<p>Marc Johlic (IBM)</p>
</item>
<item>
<p>Barry Johnson (Deque)</p>
</item>
<item>
<p>Andrew Kirkpatrick (Adobe)</p>
</item>
<item>
<p>David MacDonald</p>
</item>
<item>
<p>Erich Manser (IBM)</p>
</item>
<item>
<p>James Nurthen (Oracle)</p>
</item>
<item>
<p>Joshue O Connor</p>
</item>
<item>
<p>Jan Richards</p>
</item>
<item>
<p>Alan Smith</p>
</item>
<item>
<p>Adam Solomon</p>
</item>
<item>
<p>Makoto Ueki</p>
</item>
<item>
<p>Gregg Vanderheiden</p>
</item>
<item>
<p>Kathleen Wahlbin</p>
</item>
<item>
<p>Can Wang (Zhejiang University)</p>
</item>
<item>
<p>Jason White (Educational Testing Service)</p>
</item>
<item>
<p>Kenny Zhang (W3C)</p>
</item>
</ulist>
</div2>
<div2 id="ack_participants-previous" role="normal">
<head>Other previously active WCAG WG participants and other contributors to WCAG 2.0 or supporting resources</head>
<p>Shadi Abou-Zahra, Jim Allan, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries Arditi, Jon Avila, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick Boland, Denis Boudreau, Patrice Bourlon, Judy Brewer, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Ben Caldwell, Alastair Campbell, Laura Carlson, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, Darcy Clarke, James Coltham, Vivienne Conway, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Wayne Dick, Iyad Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Karl Groves, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn Houtepen, Carlos Iglesias, Jonas Jacek, Ian Jacobs, Phill Jenkins, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito Kidachi, Ken Kipness, John Kirkwood, Jason Kiss, Johannes Koch, Marja-Riitta Koivunen, Maureen Kraft, Preety Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, Greg Lowney, N Maffeo, Mark Magennis, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, Liam McGee, Jens Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Mary Jo Mueller, Charles F. Munat, Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Sailesh Panchang, Devarshi Pant, Nigel Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, Lisa Seeman, Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, Neil Soiffer, Jeanne Spellman, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Léonie Watson, Gian Wild, David Wooley, Wu Wei, Leona Zumbo.</p>
</div2>
</inform-div1>
<inform-div1 id="references">
<head>References</head>
<blist>
<bibl id="ANSI-HFES-100-1988"
key="ANSI-HFES-100-1988">ANSI/HFS 100-1988, American National Standard for Human Factors Engineering of Visual Display Terminal Workstations, Section 6, pp. 17-20.</bibl>
<bibl id="ARDITI" key="ARDITI">Arditi, A. (2002). Effective color contrast: designing for people with partial sight and color deficiencies. New York, Arlene R. Gordon Research Institute, Lighthouse International.</bibl>
<bibl id="ARDITI-FAYE"
key="ARDITI-FAYE">Arditi, A. and Faye, E. (2004). Monocular and binocular letter contrast sensitivity and letter acuity in a diverse ophthalmologic practice. Supplement to Optometry and Vision Science, 81 (12S), 287.</bibl>
<bibl id="ARDITI-KNOBLAUCH-1994"
key="ARDITI-KNOBLAUCH">Arditi, A. and Knoblauch, K. (1994). Choosing effective display colors for the partially-sighted. Society for Information Display International Symposium Digest of Technical Papers, 25, 32-35.</bibl>
<bibl id="ARDITI-KNOBLAUCH-1996"
key="ARDITI-KNOBLAUCH-1996">Arditi, A. and Knoblauch, K. (1996). Effective color contrast and low vision. In B. Rosenthal and R. Cole (Eds.) Functional Assessment of Low Vision. St. Louis, Mosby, 129-135.</bibl>
<bibl id="CAPTCHA" key="CAPTCHA">The CAPTCHA Project, Carnegie Mellon University. The project is online at <loc href="http://www.captcha.net">http://www.captcha.net</loc>.</bibl>
<!-- <bibl id="EPFND" key="EPFND"> Experts Issue Recommendations to Protect Public from Seizures Induced by TV / Videogames. A copy of the standard is available at <loc href="http://www.epilepsyfoundation.org/aboutus/pressroom/pr20050919.cfm">http://www.epilepsyfoundation.org/aboutus/pressroom/pr20050919.cfm</loc>.</bibl> -->
<bibl id="GITTINGS-FOZARD"
key="GITTINGS-FOZARD">Gittings, NS and Fozard, JL (1986). Age related changes in visual acuity. Experimental Gerontology, 21(4-5), 423-433.</bibl>
<bibl id="HARDING-BINNIE">Harding G. F. A. and Binnie, C.D., Independent Analysis of the ITC Photosensitive Epilepsy Calibration Test Tape. 2002.</bibl>
<bibl id="HEARING-AID-INT"
key="HEARING-AID-INT">Levitt, H., Kozma-Spytek, L., & Harkins, J. (2005). In-the-ear measurements of interference in hearing aids from digital wireless telephones. Seminars in Hearing, 26(2), 87.</bibl>
<bibl id="IEC-4WD">IEC/4WD 61966-2-1: Colour Measurement and Management in Multimedia Systems and Equipment - Part 2.1: Default Colour Space - sRGB. May 5, 1998.</bibl>
<bibl id="ISO-9241-3">ISO 9241-3, Ergonomic requirements for office work with visual display terminals (VDTs) - Part 3: Visual display requirements. Amendment 1.</bibl>
<bibl id="I18N-CHAR-ENC"
key="I18N-CHAR-ENC">
"Tutorial: Character sets & encodings in XHTML, HTML and CSS," R. Ishida, ed., This tutorial is available at <loc href="http://www.w3.org/International/tutorials/tutorial-char-enc/">http://www.w3.org/International/tutorials/tutorial-char-enc/</loc>.
</bibl>
<bibl id="KNOBLAUCH"
key="KNOBLAUCH">Knoblauch, K., Arditi, A. and Szlyk, J. (1991). Effects of chromatic and luminance contrast on reading. Journal of the Optical Society of America A, 8, 428-439.</bibl>
<bibl id="LAALS" key="LAALS">Bakke, M. H., Levitt, H., Ross, M., & Erickson, F. (1999). <loc href="http://search.naric.com/research/rehab/download.cfm?ID=101662">Large area assistive listening systems (ALS): Review and recommendations (PDF)</loc> (Final Report. NARIC Accession Number: O16430). Jackson Heights, NY: Lexington School for the Deaf/Center for the Deaf Rehabilitation Research Engineering Center on Hearing Enhancement.
</bibl>
<bibl id="sRGB">"A Standard Default Color Space for the Internet - sRGB," M. Stokes, M. Anderson, S. Chandrasekar, R. Motta, eds., Version 1.10, November 5, 1996. A copy of this paper is available at <loc href="http://www.w3.org/Graphics/Color/sRGB.html">http://www.w3.org/Graphics/Color/sRGB.html</loc>.</bibl>
<bibl id="UNESCO" key="UNESCO">International Standard Classification of Education, 1997. A copy of the standard is available at <loc href="http://www.unesco.org/education/information/nfsunesco/doc/isced_1997.htm">http://www.unesco.org/education/information/nfsunesco/doc/isced_1997.htm</loc>.</bibl>
<bibl id="WCAG20" key="WCAG20">"Web Content Accessibility Guidelines 2.0," B. Caldwell, M Cooper, L Guarino Reid, and G. Vanderheiden, eds., W3 Recommendation 12 December 2008, <loc href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/">http://www.w3.org/TR/2008/REC-WCAG20-20081211</loc>. The latest version of WCAG 2.0 is available at <loc href="http://www.w3.org/TR/WCAG20/">http://www.w3.org/TR/WCAG20/</loc>.
</bibl>
</blist>
</inform-div1>
</back>
</spec>