0 open issues were found.
1 pending issues were found.
762
687 closed issues were found.
492, 481, 482, 464, 463, 465, 466, 467, 469, 470, 472, 473, 474, 475, 476, 483, 484, 485, 486, 487, 488, 489, 490, 491, 493, 494, 495, 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506, 507, 509, 510, 511, 512, 513, 514, 515, 516, 525, 526, 527, 528, 529, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 540, 543, 544, 545, 558, 562, 563, 564, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 1306, 807, 580, 581, 582, 583, 584, 585, 586, 587, 588, 590, 598, 599, 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, 646, 647, 648, 649, 651, 652, 653, 658, 1330, 659, 662, 663, 664, 681, 683, 684, 685, 686, 687, 689, 691, 692, 693, 694, 696, 697, 708, 712, 713, 714, 715, 716, 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, 748, 749, 750, 751, 752, 754, 755, 756, 757, 758, 759, 830, 760, 876, 799, 800, 1301, 801, 803, 805, 806, 808, 809, 810, 811, 831, 832, 812, 813, 814, 815, 816, 817, 818, 819, 820, 894, 1062, 837, 829, 835, 836, 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, 877, 878, 879, 880, 881, 882, 883, 884, 885, 886, 887, 888, 889, 890, 891, 892, 893, 895, 896, 897, 898, 899, 900, 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, 939, 940, 941, 942, 944, 945, 946, 947, 949, 950, 951, 952, 953, 954, 955, 956, 958, 959, 960, 961, 962, 963, 965, 966, 967, 968, 969, 970, 971, 972, 973, 974, 976, 977, 978, 979, 981, 982, 983, 984, 987, 988, 989, 990, 991, 993, 994, 995, 996, 997, 998, 999, 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011, 1012, 1013, 1014, 1311, 1020, 1021, 1022, 1023, 1024, 1026, 1027, 1028, 1029, 1030, 1031, 1032, 1033, 1034, 1035, 1036, 1037, 1038, 1039, 1040, 1041, 1042, 1043, 1044, 1045, 1046, 1047, 1048, 1049, 1051, 1052, 1053, 1054, 1056, 1057, 1058, 1059, 1060, 1061, 1063, 1064, 1065, 1066, 1067, 1068, 1069, 1070, 1071, 1085, 1332, 1096, 1097, 1098, 1141, 1142, 1143, 1144, 1145, 1148, 1149, 1150, 1151, 1152, 1153, 1154, 1155, 1156, 1157, 1158, 1159, 1160, 1161, 1162, 1163, 1164, 1165, 1166, 1167, 1168, 1169, 1170, 1171, 1172, 1173, 1174, 1175, 1176, 1177, 1178, 1179, 1180, 1181, 1182, 1183, 1184, 1185, 1186, 1187, 1188, 1189, 1191, 1192, 1193, 1194, 1195, 1196, 1197, 1198, 1199, 1200, 1201, 1202, 1203, 1204, 1205, 1206, 1207, 1208, 1209, 1210, 1211, 1212, 1213, 1214, 1215, 1216, 1217, 1218, 1219, 1220, 1221, 1222, 1223, 1224, 1225, 1226, 1227, 1228, 1229, 1230, 1231, 1232, 1233, 1234, 1235, 1236, 1237, 1238, 1239, 1240, 1241, 1242, 1243, 1244, 1245, 1246, 1247, 1248, 1249, 1250, 1251, 1252, 1253, 1254, 1255, 1256, 1257, 1258, 1259, 1261, 1262, 1263, 1264, 1265, 1266, 1267, 1268, 1269, 1270, 1271, 1272, 1273, 1274, 1275, 1277, 1278, 1279, 1280, 1281, 1282, 1283, 1284, 1285, 1286, 1287, 1288, 1289, 1290, 1291, 1292, 1293, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1302, 1303, 1304, 1305, 1310, 1307, 1309, 1312, 1313, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 1323, 1324, 1325, 1328, 1329, 1331, 1370, 1371, 1372, 1446, 1408, 1409, 1410, 1411, 1412, 1413, 1414, 1423, 1427, 1437, 1442, 1449, 1450, 1470, 1471, 1488, 1489, 1490, 1491, 1492, 1493, 1494, 1495, 1496, 1497, 1498, 1499, 1500, 1501, 1502, 1503, 1504, 1505, 1506, 1507, 1508, 1509, 1510, 1511, 1517, 1524, 1531, 1536, 1562, 1657, 1665
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
These requirement seems to deal with collections of web resources (units). I think that this should be stated that you are creating some type of conformance for a collection of resources. It would make it much clearer. I think this should also be in the conformance section.
If a resource does not meet the requirements, it just doesn\'t meet the requirements.
Proposed Change:
1. Move this requirement to conformance section
2. Clearly state you want people to be able to make conformance claims on collections of resources.
We have revised the conformance section significantly and have clarified how claims for collections of versions can be made:
4.) Alternate Versions: If the Web page does not meet all of the success criteria for a specified level, then a mechanism to obtain an alternate version that meets all of the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria for the specified level of conformance. The alternate version does not need to be matched page for page with the original (e.g. the alternative to a page may consist of multiple pages). If multiple language versions are available, then conforming versions are required for each language offered.
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Whereas guideline 2.2 is framed in terms of "time limits" on reading and interaction. criterion 2.2.1 instead uses the term "time-out". Neither "time limit" nor "time-out" is defined. This difference in terminology raises the question of whether there is meant to be a distinction between the two concepts. I don't think there is, or ought to be, such a distinction.
Proposed Change:
Use the term "time limits" in 2.2.1, in the same sense as in the text of guideline 2.2 itself. More generally, use "time limit" wherever "time-out" appears in WCAG 2.0. If appropriate, add a glossary entry to clarify the meaning of the term - I think the text of guideline 2.2 is a clear and precise formulation of what is meant.
Time-out is a specific type of time limit. Time-out is the correct term for SC 2.2.1. Time-out is a commonly understood term on the Web and we are not using it in a special way, so we don't think it needs a definition.
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
In the definition of "Web unit":
"identified by a single Uniform Resource Identifier (such as URLs)"
This is not only grammatically wrong but rather sloppy language for a specification.
Proposed Change:
"identified by a single Uniform Resource Identifier (URI)"
Consider whether to add a note stating that a URI is either a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). Is this still correct?
We changed "identified by a single Uniform Resource Identifier (such as URLs)" to "identified by a single Uniform Resource Identifier (URI)."
Item Number: Conformance claims
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The main principle which distinguished level 1 from level 2 success criteria in the November 2005 working draft, namely that level 1 criteria may not, whereas level 2 criteria may impose constraints on expression and presentation of material, has been abandoned in the Last Call draft. No substitute principle has taken its place. All that the conformance section now states is that level 1 criteria constitute the minimum, and level 2 requirements offer an enhanced level of accessibility. Level 3 is distinguished in so far as these criteria may not be applicable to all Web content.
The lack of a principled distinction between level 1 and level 2 is a significant weakness of the guidelines as currently drafted, for several reasons. First, it invites fragmentation of the standard by failing to offer any defensible ground for the allocation of success criteria to conformance levels. In contrast, confidence in the integrity of the WCAG 1.0 conformance scheme, in so far as it worked, is bulstered by the fact that there was a coherent underlying rationale determining the assignment of priorities to checkpoints; one was not asked simply to trust the judgment of the working group in this respect.
Secondly, the WCAG 2.0 levels impose de facto priorities upon success criteria. The difference between WCAG 1.0 "priorities" and WCAG 2.0 "levels" is in name only. Level A conformance, as in WCAG 1.0, still requires satisfaction of all level 1 items, and correspondingly at level 2 and even at level 3, where a 50% minimum is arbitrarily imposed. Developers must, therefore, despite statements in the guidelines to the contrary, treat level 1 items as more important than level 2 items, and level 2 items as more important than those at level 3. Yet, unlike WCAG 1.0, there is no rationale, based on impact or any other concept, that determines and justifies these distinctions among priorities (now called "levels"). Implementors, policy makers and other audiences have no reason to believe that the allocation of levels to success criteria is anything better than the outcome of compromise.
This shortcoming of the guidelines needs to be remedied in two steps. First, the working group should agree upon one or more clear, pertinent and applicable criteria to distinguish level 1 from level 2 items. Secondly, the whole document should be reviewed in light of these criteria, re-allocating success criteria to levels as needed to bring the guidelines into accord with the chosen principles.
Alternative proposals are provided below. These are not intended to be
exhaustive of the possibilities; other solutions may, and should, also be considered.
Proposed Change:
Option 1. Reinstate the principle that level 1 success criteria enable user agents and other tools to adapt the content to meet a wide range of access requirements, without imposing constraints on the expression or presentation of the content. Level 2 criteria make the content directly accessible by regulating expression and presentation as needed to achieve a high degree of accessibility.
Option 2: Establish "impact", as in WCAG 1.0, as the main distinction between level 1 and level 2 criteria, while acknowledging that this does not apply to requirements primarily aimed at aiding cognition. For success criteria primarily related to cognitive disabilities, establish a requirement that level 1 criteria do not impose constraints on the expression, whether linguistically, graphically, auditorily etc., of the content. This leads to the following:
a. At level 1, success criteria eliminate barriers that would otherwise make it impossible, due to a sensory or physical disability, to access the content. At level 2, success criteria overcome barriers that would otherwise make it very difficult, due to a sensory or physical disability, to access the content. Level 3 criteria further facilitate access (as in WCAG 1.0 priority 3).
b. Level 1 criteria substantially enhance the effectiveness with which people with cognitive disabilities can access the content, without imposing constraints on the expression, whether in language, sound or images, of the information and functionality provided by the content. Level 2 criteria further facilitate cognition by requiring content to be expressed in ways that improve its accessibility to people with a variety of cognitive disabilities. Level 3 criteria are the same as level 2, but place requirements on expression that cannot be applied to all types of content.
Option 3: Establish a metric of implementation difficulty that is applicable across technologies and will remain stable over time. This would roughly correspond to the amount of effort required of an author to implement the success criteria. Level 1 criteria would demand minimal effort while substantially overcoming barriers to access, level 2 more effort, and level 3 still further. The measure of "difficulty", "effort" or whatever, would provide the basis for making this distinction more precise. I doubt whether such an idea can be worked out in practice, and I along with other proponents of enhanced accessibility would object to its introduction into the guidelines
- benefit to people with disabilities, rather than impact on authors, should be the primary means of distinguishing among conformance levels. Also, such an approach would promote the idea that accessibility is a burden rather than an opportunity, clearly an undesirable result.
Option 4: Divide the success criteria in WCAG 2.0 into two categories: (a) "general": criteria applicable to all types of Web content; and (b) "special": criteria only applicable to some types of Web content. This distinction is already used, albeit roughly, to separate out certain of the criteria currently classified as at level 3. Under this proposal, define the three conformance levels as follows:
Level A conformance means that half (50%) of the general success criteria are satisfied.
Level AA conformance means that all of the general success criteria are satisfied.
Level AAA conformance means that all of the general success criteria, and all of the special success criteria applicable to the type of content involved, are satisfied.
The "special" success criteria would have to be defined and grouped into categories to make clear which should be applied to which kinds of content, and how the different types of content could be distinguished. Note also that additional aids to cognition - controlled vocabularies, symbol systems, etc., could be itnroduced as "special" criteria in the sense indicated in this proposal. They could also be introduced at level 3 under other proposals outlined above.
Variations on the above proposals can of course easily be created.
Whatever proposal is chosen, whether one of the above or not, the success criteria must all be reviewed and, as necessary, reclassified in accordance with it.
The description of conformance levels in WCAG 2 has been rewritten to clarify these issues:
The word "levels" does not mean that some success criteria are more important than others. Each success criterion in WCAG 2.0 is essential to some users, and the levels build upon each other. However, even content that conforms at AAA (triple-A) may not be fully accessible to every person with a disability.
*In general, Level A success criteria achieve accessibility by supporting assistive technology while putting the fewest possible limits on presentation. Thus people with a wide range of disabilities using a wide range of assistive technologies, from voice input and eye-tracking devices to screen readers and screen magnifiers, are able to access content in different ways. In other words, Level A success criteria support the ability of both mainstream and specialized user agents to adapt content to formats that meet their users' needs.
*The success criteria in Level AA provide additional support for assistive technology. At the same time, they also support direct access to content by the many people who use conventional user agents without assistive technology. In general, Level AA success criteria place more limits on visual presentation and other aspects of content than the success criteria in Level A.
*Level AAA success criteria increase both direct access and access through assistive technology. They place tighter limits on both presentation and content.
Item Number: Related Documents
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Conformance: Aggregated Content.
If content contains authored units that do not themselves carry any conformance claims, and those authored units are modified or substituted as a result of an aggregation process, then the conformance status of those authored units is unknown at any point in time unless individual assessments are carried out. Such assessments may be impractical, for example on sites that collect comments from the public, maintain e-mail archives, etc.
As the guidelines are currently drafted, the conformance of any Web unit containing such authored units depends in turn on the conformance of those authored units, which may vary over time. In order to avoid making false conformance claims, the operator of such a Web site would, presumably, have to exclude such Web units from the scope of any conformance claim, in accordance with the scoping provisions of the conformance section. I think this consequence needs to be clarified and stated explicitly.
Alternatively, the scoping provisions could be modified to allow individual authored units to be excluded from the ambit of a claim, but in that case it is by no means clear how the "authored units" could be precisely identified and specified in the claim.
Proposed Change:
Clarify that if it is unknown whether an authored unit participating in aggregation conforms to WCAG 2.0, or which level of conformance is achieved, then it is likewise unknown what, if any, level of conformance is attained by Web units in which it appears. Implementors should be advised to exclude Web units containing such "unknown" authored units from the scope of any conformance claim in accordance with the "scoping" provisions of the conformance section of WCAG 2.0.
Note that by controlling what may appear in authored units participating in the aggregation process, through technical or other means, it may be possible to ensure that a given level of conformance is always satisfied. Under these circumstances (where the conformance of resulting Web units is guaranteed), conformance claims with respect to such aggregated content may reliably be made.
We have made conformance claims less regulatory and more descriptive, that is, a conformance claim describes what is conformant to the guidelines. We think it is more appropriate for policy makers to determine appropriate exceptions.
We have provided a way to make a statement about parts of a page that do conform if the whole page doesn't.
We have clarified the situation by removing all exceptions and adding the following at the end of the conformance section:
Note: If pages can not conform (for example, conformance test pages or example pages) they would not be included in the conformance claim.
Statement of partial conformance
Sometimes, Web pages are created that will later have additional content added to them. For example, an email program, a blog, or an article that allows users to add comments to the bottom. Another example would be a company or individual who compiles a page from multiple sources. Sometimes, the content from the other sources is automatically inserted into the page over time.
In both of these cases, it is not possible to know at the time of original posting what the content of the pages will be. Two options are available:
1. A conformance claim is made based on best knowledge. If a page of this type is monitored and kept conformant (non-conforming content is immediately removed or made conforming) then a conformance claim can be made since, except for error periods, the page is conformant. No conformance claim should be made if it is not possible to monitor or correct non-conforming content.
2. A "statement of partial conformance" is made. A statement that the page does not conform, but could conform if certain parts were removed can be made. The form of that statement would be, "This page would conform to WCAG 2.0 at level X if the following parts from uncontrolled sources were removed."
1. This "statement of partial conformance" cannot be used for content that is under the author's control.
2. The "following parts" of the page that would need to be removed would be described in terms that users can understand. (e.g. they can't be described as "all parts that we do not have control of" unless they are clearly marked as such.)
Item Number: Conformance claims
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
While many accessibility criteria can hardly be formalised to be automatically checked by a validator, some of them can.
Previous attempts have been made to formalise some of WCAG 1.0, such as the W3C "Web Content Accessibility Checking Service" [http://www.w3.org/2000/07/eval43/] using Schematron [http://www.w3.org/2000/07/eval43/wai.xml] or the more advanced Petr Nalevka's "Relaxed validator" [http://badame.vse.cz/validator/] using Relax NG with embedded Schematron [http://cvs.sourceforge.net/viewcvs.py/relaxed/relaxed/conf/schema/rng/modules/wcag.rng?view=markup].
Proposed Change:
Propose some schemas for checking some of the accessibility rules in (at least) HTML documents (using e.g. XML Schema, Relax NG, Schematron) checking for the criteria that can be formalised. Relax NG + Schematron is imho a good candidate.
This is a recommendation for a method for checking content for conformance, not a success criterion for conformance. The Working Group is not requiring that authors use any particular technique or tools for determining conformance. We believe this comment is best directed to the Evaluation and Repair Tools Working Group.
Item Number: Success Criterion 4.2.1
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
4.2.1 also suggests that the accessible version be the primary version, with a link to the inaccessible version. In reality that is never the case, nor would you likely be able convince a client/developer to use an HTML version of their splash page in favour of a fancy Flash version
Proposed Change:
Ideally there should be reciprocol links between the two versions.
We have moved discussion of alternate versions of content to the Conformance section of the Guidelines.
"Alternate Versions: If the Web page does not meet all of the success criteria for a specified level, then a mechanism to obtain an alternate version that meets all of the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria for the specified level of conformance. The alternate version does not need to be matched page for page with the original (e.g. the alternative to a page may consist of multiple pages). If multiple language versions are available, then conforming versions are required for each language offered."
We have also added an advisory technique titled, "Providing reciprocal links between conforming and non-conforming versions."
Item Number: Success Criterion 4.2.1
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Wording of 4.2.1 is easily misinterpreted.
Proposed Change:
"Where content is presented using a technology that is not in the baseline, or is in the baseline but does not meet level 1 success criteria, provide reciprocol links between that version and another version of that same content, with equivalent functionality, that does meet level 1 success criteria."
We have moved discussion of alternate versions of content to the Conformance section of the Guidelines.
Alternate Versions: If the Web page does not meet all of the success criteria for a specified level, then a mechanism to obtain an alternate version that meets all of the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria for the specified level of conformance. The alternate version does not need to be matched page for page with the original (e.g. the alternative to a page may consist of multiple pages). If multiple language versions are available, then conforming versions are required for each language offered.
We have also added an advisory technique titled, "Providing reciprocal links between conforming and non-conforming versions."
Item Number: Make all functionality operable via a keyboard interface
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
A few years back I tried to pay my Sprint account online and found that even though I could submit a payment form via an image, the payment was not accepted because the x and y coordinates which are automatically submitted with the image (and are 0 in the case of a keyboard click) were both 0. This was bad programming on their part, but the point is:
If an element has focus where a mouse click would take an action that takes the mouse location into account, then using the arrow keys at that point (or some other keyboard means) should allow the user to set the mouse position that will be used upon keyboard simulated clicking (such as using the spacebar) of the element.
This example may be too specific for this document, but I thought I'd mention it as a concrete case that really troubled me.
Csaba Gabor from Vienna
Proposed Change:
Thank you for your note. You will be happy to know that Guideline 2.1 and SC 2.1.1 of WCAG 2.0 require that all functionality of content be operable from the keyboard interface (unless the underlying function requires input that depends on the path of the user's movement and not just the endpoints - which yours doesn't). So the Web page you describe would not pass WCAG 2.0 even at the basic level of conformance.
Comment (Including rationale for any proposed change):
There is currently no item number relevant to this comment. Technique G96 seems to be the only place within the WCAG 2.0 documents that mentions anything about "relative positioning", or more specifically use of relative measures. Using relative measures is particularly important for low vision users who use a browser function to blow up the text size. It is also important for those using small screens like PDAs.
Proposed Change:
This requirement seems to fit best under WCAG principle 4, regarding robust. Perhaps a new guideline 4.1.3, at level 2. something like "Ensure that content can be resized without losing its symmetry" Then in the techniques describing the use of relative measures for sizing block level items, text, images, etc.
Although resizing is primarily a user agent function, we have added new success criteria to address the author's responsibility for supporting text resizing:
Level AA: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality.
Level AAA: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally.
Item Number: Make text content readable and understandable.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Guideline 3.1 is concerned with the need to make text readable and understandable. In general WCAG 2.0 contains very few provisions for improving the accessibility of web content for people with cognitive disabilities or learning difficulties. There is the level 3 SC 3.1.5, which is concerned with the reading level of text, however it is a fallacy to assume all cognitive disabilities somehow relate to a persons ability to read.
WCAG 1.0 contained the Priority 1 Checkpoint 14.1 (Use the Clearest and simplest language appropriate for a site's content). It also contained the Priority 2 Checkpoint 12.3 (Divide large blocks of information into more manageable groups where natural and appropriate). Combined these two checkpoints communicated the desirability of preparing content that could be accessed by people with a range of cognitive and intellectual abilities and suggestions for how this could be achieved. Unfortunately, WCAG 2.0 does not appear to contain a similar commitment or guidance to these issues.
Proposed Change:
Guideline 3.1 should contain two new Level 2 success criteria, which read:
1. "When web units contain text, the clearest and simplest language appropriate for the users of the content is used and large blocks of information are presented using appropriate headings and subheading."
2. "When forms are presented, the controls in similar areas of a form should be grouped together and appropriately identified."
The working group was unable to come up with a testable equivalent of WCAG1 14.1. However, we have added an advisory technique to guideline 3.1 and SC 3.1.5 that reads, "Using the clearest and simplest language appropriate for the content."
We have also added a new Success Criterion to GL 3.1, "Pages are organized into sub-sections with titles", to address some of the properties covered by Checkpoint 12.3.
We have added language to the Introduction to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and calls out the need for more research in this area. WAI is exploring ways in which to support and encourage work in this important area.
We have added some best practices for cognitive, learning, and language disabilities as advisory techniques. We have not been able to propose many additional success criteria that meet WCAG's testability requirements.
Item Number: Success Criterion 4.1.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The "Understanding WCAG 2.0" comments relating to SC 4.1.1 indicate poorly coded content may not be correctly rendered by assistive technologies. This accurate comment was presumably one of the guiding principles behind the WCAG 1.0 Checkpoint 3.2, "Create documents that validate to published formal grammars."
Although there is a view WCAG 2.0 needs to be technologically neutral, I believe we should be mindful of the fact that most web pages today use (x)html and this is likely to continue to be the case for the foreseeable future. Over the years a suite of recognised standards (html, css, mathml, etc) have emerged. Many assistive technologies (and other devices) use these standards, and associated document type declarations, and an increasing number of developers know that it is desirable to produce code that complies with them.
It seems to me, the weasel words used in SC 4.1.1 are a tortured and misguided attempt to avoid saying websites should use valid code. Why? Surely, the W3C is one organization that should be wholeheartedly committed to the notion of promoting clearly defined standards. Instead, we seem to have abandoned the guideline that required the use of valid code in favour of, what? I was interested to notice that the "Understanding WCAG 2.0" Techniques for this SC contain three techniques, but details are only provided for the one that relates to "Validating web units". The last suggested technique is, "Fully conforming to specification". No details at all appear to be provided about what these specifications are, or who will determine them.
Proposed Change:
I believe SC 4.1.1 should remain a level 1 SC but should be rewritten to read, "Web Units or authored components validate to formal grammars published by the W3C."
We have modified the success criterion to clarify that content can be parsed successfully using the rules of the specification for the technology in use.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Item Number: Success Criterion 2.4.4
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Although the wording of SC 2.4.4 is convoluted, it is presumably a replacement for WCAG 1.0, Checkpoint 13.1 "Clearly identify the target of each link [Priority 2]". However 13.1 also required the link text to meaningful enough to make sense when read out of context, either on their own or as a sequence of links, and this does not appear to be the case with SC 2.4.4.
In my experience, many screen reader users extensively use the screen-reader facility that enables them to obtain a list of links on a page. This is often the preferred technique when looking for information on a site or undertaking a task, and in virtually all situations it is only effective when the link text indicates the link destination. While I believe it is possible with some screen readers to select an option that provides context from the surrounding text I have never seen this done. However, many times I have seen screen reader users become frustrated with links that contain only the words "more", "next" or "click here".
I believe it is very important for link text to provide a clear indication of the link destination. Also, the link text should make sense without the need to rely on surrounding contextual information or a title attribute within the link element.
Proposed Change:
I believe 2.4.4 should remain a level 2 SC, but should be rewritten to read, "The target or destination of each link should be clearly indicated by the link text."
WCAG 1.0, Checkpoint 13.1 is the equivalent of SC 2.4.8, since SC 2.4.4 permits the use of programmatically determined context. SC 2.4.8 is at level AAA because of the potential usability problems introduced by requiring that the link text alone be sufficient. For instance, in a table of links, repeating the table header information in each cell makes the table much more difficult to use.
The basic requirement that assistive technology be able to determine the purpose of the link is covered by SC 2.4.4. This success criterion has been moved to level A.
Item Number: Success Criterion 1.4.3
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The spread of the requirement to have sufficient difference between foreground and background colours over two Success Criterion is an effective way of recognising the fact that the higher the contrast ratio the more likely the information will be accessible to a greater number of people with impaired colour vision.
However, I believe both the SC relating to this issue should be increased.
Proposed Change:
Make SC 1.4.3 a Level 2 Success Criteria
The working group discussed this topic for a long time and after much discussion decided that SC 1.4.3 (formerly 1.4.1) should be at level AA and SC 1.4.5 (formerly 1.4.3) should be at level AAA. It was felt that all of the information in the text would already be available through the alternate texts (short alternate text and long description) if needed and that restricting text contrast for the default presentaion to this extent was more restrictive than desired for a level A success criterion.
Item Number: Success Criterion 1.4.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Many people have difficulties differentiating between the foreground (text) and background colours used on websites. Also, as people get older their ability to perceive colours and differentiate between colours seems to diminish.
I believe that this is a significant accessibility issue and so should be required if a site is to achieve a minimum level of accessibility.
Proposed Change:
Make 1.4.1 a Level 1 Success Criteria
The working group discussed this topic for a long time and after much discussion decided that SC 1.4.3 (formerly 1.4.1) should be at level AA and SC 1.4.4 (formerly 1.4.3) should be at level AAA. It was felt that all of the information in the text would already be available through the alternate texts (short alternate text and long description) if needed and that restricting text contrast for the default presentation to this extent was more restrictive than desired for a level A success criterion.
Item Number: Success Criterion 1.3.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
It appears that SC 1.3.1 encompasses many separate guidelines that were specified in WCAG 1.0, including the requirement to associate data table cells with the appropriate row and column headings and requirements relating to the labelling and grouping of form controls. I presume part of the reason for combining such a diverse range of accessibility needs in single success criteria is the desire to have criteria that are "technology-independent".
In my experience, a lage proportion of the problems assistive technology users now experience when using web sites result from the sites failing comply with the WCAG 1.0 guidelines that are now nominally covered by SC 1.3.1. Nearly all web content is currently presented using (x)html and this is likely to continue to be the case for the foreseeable future. However WCAG 2.0, which is the normative document, provides web developers with no practical guidance or clues in how to avoid these problems.
The link "How to meet 1.3.1" leads to information in the "Understanding WCAG 2.0" document, which describes techniques for addressing the criterion. The "Understanding" document contains links to eleven HTML techniques, which are presented in yet another document, "Techniques for WCAG 2.0".
Frankly, I don't imagine many developers when faced with the prospect of preparing a data table will bother to troll through three documents in order to see why it is important to associate data cells with row and column headers in a non-visual way. On a related point, why don’t the "Understanding WCAG 2.0" HTML Techniques include the need to use TH for tables with single levels of row and column headers?
I am concerned that the failure to provide guidance in relation to crucial html issues in the WCAG 2.0 document will lead to a decline in awareness on the part of developers regarding their importance and this will contribute to a fall in the overall accessibility of websites and the web as a whole.
I believe the Working Group should get over their hang up with developing some sort of technology neutral standard and recognise that the way to bring the greatest accessibility gains to the greatest proportion of web users is by providing practical advice in how to improve the accessibility of (x)html sites.
Proposed Change:
In my view, WCAG 2.0 Guideline 1.3 should include success criteria for the specific issues that are addressed in the following WCAG 1.0 Checkpoints: 3.1, 3.5, 3.6, 5.1, 5.2, 5.5 and 12.4.
Since this is unlikely to happen, I would like to urge the Working Group to consider providing HTML example for each of the issues covered by the checkpoints above in the core WCAG 2.0 document so that SC 1.3.1 is able to provide the majority of web developers with a clear indication of how to meet this criterion.
If the normative guidelines include the HTML-specific success criteria, then tables, forms, headings, etc. could only conform to WCAG 2.0 if they are implemented in HTML. Tables, forms, headings, etc. implemented in any other technology, such as PDF, could not conform to WCAG 2.0. It is expected that many HTML developers will simply go directly to the HTML Techniques instead of starting with the guidelines document.
With regard to your specific recommendations on addressing WCAG 1.0 checkpoints 3.5, 3.6, 5.1, 5.2, 5.5 and 12.4, these checkpoints are addressed in the following WCAG 2.0 techniques:
- 3.5; H42: Using h1-h6 to identify headings http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H42
- 3.6; H48: Using ol, ul and dl for lists http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H48
- 5.1; H51: Using table markup to present tabular informationhttp://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H51
5.2; H43: Using id and headers attributes to associate data cells with header cells in data tables http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H43 AND H63: Using the scope attribute to associate header cells and data cells in data tables http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H63
- 5.5; H73: Using the summary attribute of the table element to give an overview of data tables http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H73
- 12.4; H44: Using label elements to associate text labels with form controls http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H44
With regard to the comment about why the Understanding WCAG 2.0 HTML
Techniques don't include the need to use TH for tables with single levels of row and column headers, this requirement is covered in technique H51: Using table markup to present tabular information
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H51
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The conformance section is not sufficiently precise in stating what must be included in a baseline. Specifically, a baseline must specify a list of technologies, including minimum versions, where applicable, thereof, that are required to be supported in order for the content to be rendered to, and operated by, the user.
Proposed Change:
In the "required components of a conformance claim" section, explain clearly that, where applicable (i.e., where there exist multiple versions of a technology), the minimum version required to be supported and enabled in user agents must be stated as part of the baseline. More explicitly, the baseline must name each technology together with the minimum required version, where applicable.
The following sentence was added to the end of the section titled "Rules for Supported Technologies":
"When citing technologies as supported, the version(s) must be specified."
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
"If individual authored units do not carry a conformance claim, then the claim must be based on the Web unit with the authored units in place." This is expressed in terms of claims rather than in terms of conformance. It should be more accurately stated thus:
"If individual authored units do not carry conformance claims, then the conformance of any Web units in which they occur is determined as the level of conformance, if any, attained by those Web units with all aggregated content in place".
Proposed Change:
See wording proposed above.
We have completely revised the conformance section. Issues related to aggregation are now discussed in the section "Statement of partial conformance" at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#conformance-partial .
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Sc 1.1.1: "If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, is the above meant to apply to auditory content, e.g., sound efects or background sounds used only for aesthetic purposes and which is incidental to the meaning and functionality of the Web unit? In other words, can a sound be "pure decoration", or is the provision restricted to visual material? My own view is that it should apply irrespective of the modality of the "decoration", namely to auditory content as well as visual.
Proposed Change:
Perhaps add a parenthetical such as "pure decoration (whether auditory or visual)".
The 1.1.1 success criteria on decorative non-text content does not specify that it applies only to visual content. On the other hand the working group was unable to identify ways to mark audio so that AT could ignore it. Did you have something in mind?
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The term "parsed unambiguously" is ambiguous. Parsing requires a set of rules and without those rules the parsing result may be meaningless. For example, an HTML file may be parsed using the rule "by line". It may also be parsed using the rule "by sentence and word". This parsing will produce an unambiguous tree structure but has no effect on accessibility. I believe the intent of the SC is to include the set of rules (e.g. DTD or schema) that has an effect on accessibility.
Proposed Change:
Include text that specifies the set of rules needed to parse the document. Example: "Web units or authored components can be parsed unambiguously using the specification that affects accessibility...". In the techniques document you can specify the appropriate rules such as in HTML use one of the standard DTDs.
We have reworded SC 4.1.1 as follows:
4.1.1 Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications. (Level A)
Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quote are not complete.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Guideline 1.2 does not require, at any conformance level, audio descriptions of live video; only prerecorded video is covered. Audio description of live video is possible, at least in some circumstances. It can indeed be accomplished at a high level of quality, as in live plays where describers have access to scripts in advance. In other situations, such a degree of quality and accuracy may not be attainable, but descriptions could still be attempted. Are there situations in which it would be technically and practically infeasible to provide audio descriptions of live video? If so, this item could be introduced at level 3, otherwise it is a candidate for level 2.
Proposed Change:
Add a success criterion at an appropriate level requiring audio descriptions of live video.
A criterion similar to this proposal was included in previous drafts of WCAG 2.0. However, the working group decided to remove it since this is almost impossible to do unless the live multimedia is scripted. The working group did not feel that live scripted events were applicable to a wide enough range of web content to be included at the success criterion level, but has included an advisory technique (details to be completed in a future draft) about providing audio descriptions for live multimedia.
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Sc 1.3.1 refers to "information and relationships", whereas guideline 1.3 is expressed in terms of "information and structure". If there is supposed to be a subtle difference between these terms, it needs to be defined and explained. Otherwise, the same wording should be used in both the guideline and the success criterion. I don't think there is, or ought to be, any difference in meaning.
Proposed Change:
Change sc 1.3.1 to read "information and structure".
Guideline 1.3 has been reworded to avoid this confusion. The new wording is "Create content that can be presented in different ways (for example spoken aloud, simpler layout, etc.) without losing information or structure."
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Terminology used in related technical specifications should be consistent, unless there are compelling reasons to the contrary. There are no strong reasons why basic terminology in WCAG 2.0 should differ from ATAG, UAAG and indeed WCAG 1.0.
Proposed Change:
Change "principles", "guidelines" and "success criteria", respectively, to "guidelines", "checkpoints" and "provisions" throughout WCAG 2.0 and supporting documentation.
The elements in WCAG 2.0 differ from those in the other documents. Using the same terms would be misleading. For example what you suggest we list as checkpoints are guidelines in this document. The success criteria would be the closest thing to checkpoints but they would be under checkpoints with the labeling you propose, so the things you must check off would not be the checkpoints but what was under them. Also, we have a checklist that is success criteria. To label the guidelines as checkpoints but have different things be in the checklist would be confusing.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The expression "conveyed through presentation" is not defined, and therefore open to divergent interpretations. If, for example, an implementor decided that "presentation" could be construed as meaning "auditory presentation provided by a speech-enabled user agent", and it turned out that very few aspects of the structure of the content were conveyed in an auditory presentation, then it could be concluded, contrary to the purpose of the guidelines, that almost none of the structure need be programmatically determinable. I can think of two alternative ways in which the concept of "conveyed through presentation" could be more precisely defined.
1. Any aspect of the information or structure that is evident from the presentation of the content, in any modality, must be able to be programmatically determined.
2. Any aspect of the information or structure for which the author provides presentational hints to the user agent, must be able to be programmatically determined. Presentational hints may include style parameters, visual formatting (layout, font changes, etc.), audio formatting (parameters to control a speech synthesizer) and other aspects of the content designed to influence its presentation in one or more sensory modalities. I think the second proposal is the more practicable solution as it doesn't leave authors wondering what might be apparent in a presentational context with which they are unfamiliar, that needs to be made programmatically determinable.
Proposed Change:
Rewrite the success criterion, add a note to it, or rewrite the definition of "presentation" to clarify the requirement in accordance with the problem raised and the solutions suggested above, or indeed any other solution that addresses the lack of clarity in the current text.
We have updated the definition of "presentation" to "rendering of the content in a form to be perceived by users." We have also added a definition for "relationships."
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
This criterion is specific to aspects of visual presentation. Suppose however that the content is written in VoiceXML or a comparable format designed to control auditory presentation. Surely the same requirement should apply, for the benefit for example of users who are deaf.
Proposed Change:
Generalize this criterion so that it is not modality-specific, i.e., not limited to visual presentation.
SC 1.3.3 (formerly 1.3.5) is intended to address issues where the ability to understand and operate content depends on the 2-dimensional spatial presentation which is only an issue for blind and visually-impaired users. We can reconsider if a specific example is provided that would be an issue for deaf users.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Blinking is not a "time limit" on reading or interaction. Therefore, sc 2.2.2 does not belong under this guideline.
Proposed Change:
Move 2.2.2 to guideline 2.3, generalizing the wording of guideline 2.3 if necessary. Alternatively, move this criterion to its own guideline if photosensitivity is not the main rationale and if you don't want to expand guideline 2.3 to cover the issues addressed by this criterion.
Blinking does not fall within the frequency range that causes seizures and is therefore not appropriate under guideline 2.3. That's why the working group added the note referring to guideline 2.3 to this success criteria. Blinking is a timeout issue though if users are unable to read blinking text or images of text or to comprehend blinking images before they change.
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Sc 2.3.1 refers to "content", but sc 2.3.2 refers instead to "Web units". Since any content conforming to the guidelines consists of one or more Web units, the word "content" should refer to all Web units within the scope of the conformance.
The main point here is this: terminology should be consistently used. If there is a technical distinction to be drawn between "content" (2.3.1) and "Web units" (2.3.2), it needs to be explained, or better, expressed directly in the text of the criteria.
Proposed Change:
Change "Web units do not contain any components that flash" to "Content does not flash", or "The content does not flash".
Thanks. We changed 2.3.2 from "Web units do not contain any components that…" to "Content does not contain anything that flashes…"
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Should the sentence begin with "Content" or with "The content" (i.e., the content subject to WCAG 2.0 conformance)?
Proposed Change:
Change "Content" to "The content" if appropriate, making sure that it is consistent with wording used elsewhere (i.e., make the change consistently).
When the word "the" is used before a word it means that the writer is referring to the instance of this word that occurred previously. If we begin a success criterion with "the content" it would mean that we were referring to the the content in the previous sentence. This is not always true. In fact, in different places, there is a different use of the word content that preceeds it. Therefore "the content" is used before content only if the word content has already been introduced in the same sentence (or paragraph).
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Are there "processes" which are not "tasks" for purposes of this criterion? I can't think of anything that would qualify. If I perform an interaction in a user interface, surely I am performing, or undertaking, a task and the result of my doing so will be the result of the task performed. If this is right, then make the change proposed below.
Proposed Change:
Change "process or task" to "task" or "task performed by the user".
We agree that WCAG should be consistent in our use of terms. However, we think that "process" is more appropriate than "task" in this case.
Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):
How does 2.4.8 differ from 2.4.4? How can the purpose of a link be programmatically determined?
Proposed Change:
Rewrite this sc to clarify what is required and how it differs from 2.4.4, or rewrite 2.4.4 to cover the same issues, or delete 2.4.8.
We have changed SC 2.4.4 to make it clearer that it may be necessary for the user to request context information to understand the purpose of the link at level A. At level AAA, the purpose of the link can be understood from the link independent of its context. We have also changed the language to clarify that the text describing the purpose, and not the purpose itself, is what can be programmatically determined
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Under item 2, consider using "task" rather than "process", especially if my comment on "tasks and processes" is accepted. It is important to use the same word for the same purpose consistently throughout the document.
Proposed Change:
"next step in the task" rather than "in the process".
The working group agrees that WCAG should be consistent in our use of terms. However, we think that "process" is more appropriate than "task" in this case.
Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):
Should "context-sensitive help" be defined in terms of "the task, or the step in the task, currently being performed"? This would require it to be specific to the over-all task while allowing individual steps in a task to have their own help items.
If it is better to think in terms of tasks, maybe context-sensitive help should be defined accordingly.
Proposed Change:
The current wording of the definition of "context-sensitive help" neither requires nor prohibits the suggestion here. We think it is better for designers to have the flexibility to determine the most appropriate context-sensitive help for their application.