0 open issues were found.
1 pending issues were found.
762
908 closed issues were found.
555, 492, 481, 482, 464, 463, 465, 466, 467, 468, 469, 470, 472, 473, 474, 475, 476, 477, 483, 484, 485, 486, 487, 488, 489, 490, 491, 493, 494, 495, 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506, 507, 523, 509, 510, 511, 512, 513, 514, 515, 516, 517, 519, 521, 522, 524, 525, 526, 527, 528, 529, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 540, 542, 543, 544, 545, 553, 554, 556, 557, 558, 559, 560, 561, 562, 563, 564, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 575, 1306, 577, 578, 807, 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, 646, 647, 648, 649, 821, 651, 652, 653, 654, 655, 656, 658, 1330, 659, 660, 662, 663, 664, 701, 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, 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, 748, 749, 750, 751, 752, 754, 755, 756, 757, 758, 759, 830, 782, 760, 876, 763, 764, 765, 766, 767, 768, 769, 770, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 783, 784, 785, 786, 787, 788, 789, 790, 791, 792, 793, 794, 795, 796, 797, 798, 799, 800, 1301, 801, 803, 805, 806, 808, 1525, 809, 810, 811, 831, 832, 812, 813, 814, 815, 816, 817, 818, 819, 820, 894, 1062, 833, 837, 829, 834, 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, 937, 938, 939, 940, 941, 942, 944, 945, 946, 947, 948, 949, 950, 951, 952, 953, 954, 955, 956, 958, 959, 960, 961, 962, 963, 964, 965, 966, 967, 968, 969, 970, 971, 972, 973, 974, 975, 976, 977, 978, 979, 980, 981, 982, 983, 984, 985, 986, 987, 988, 989, 990, 991, 992, 993, 994, 995, 996, 997, 998, 999, 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011, 1012, 1013, 1014, 1311, 1016, 1017, 1018, 1019, 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, 1050, 1051, 1052, 1053, 1054, 1056, 1057, 1058, 1059, 1060, 1061, 1063, 1064, 1065, 1066, 1067, 1068, 1069, 1070, 1071, 1072, 1073, 1074, 1075, 1077, 1078, 1079, 1080, 1081, 1082, 1083, 1085, 1086, 1087, 1088, 1089, 1091, 1092, 1093, 1332, 1095, 1096, 1097, 1098, 1099, 1100, 1101, 1102, 1103, 1104, 1105, 1106, 1107, 1108, 1109, 1110, 1111, 1112, 1113, 1114, 1115, 1116, 1117, 1118, 1119, 1120, 1121, 1122, 1123, 1124, 1125, 1126, 1127, 1128, 1129, 1130, 1131, 1132, 1133, 1135, 1136, 1137, 1138, 1139, 1141, 1142, 1143, 1144, 1145, 1146, 1147, 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, 1260, 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, 1308, 1309, 1312, 1313, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1331, 1370, 1371, 1372, 1446, 1375, 1376, 1377, 1378, 1379, 1380, 1381, 1382, 1383, 1384, 1385, 1386, 1387, 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 1401, 1402, 1403, 1404, 1405, 1406, 1407, 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, 1518, 1519, 1524, 1531, 1535, 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: (none selected) Applicability
Comment Type: GE
Comment (including rationale for proposed change):
I believe the title "Techniques for WCAG 2.0" is misleading. As the document is about failures to correctly address accessibility, I believe the document should be retitled.
Proposed Change:
Retitle "Techniques for WCAG 2.0" as "Failures in Technique for WCAG 2.0".
We have added the subtitle "Techniques and Failures for WEb Content Accessibility Guidelines 2.0".
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.
Item Number: H51: Using table markup to present tabular information...
Part of Item: Description
Comment Type: ED
Comment (Including rationale for any proposed change):
Using the HTML table element... - "table" not marked as "code".
...the HTML pre element... - "pre" not marked as "code".
Proposed Change:
Mark the two words as "code".
Thanks. The missing code elements have been added as proposed.
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
Item Number: H63: Using the scope attribute to associate header cells and data cells in data tables...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):
Technique H63 says it is referenced from SC 1.3.4.
It is actually referenced from SC 1.3.1
Proposed Change:
Change reference to SC 1.3.1.
Thanks. The reference has been updated as proposed.
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.
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Principle 3 refers to "controls" ("content and controls"). Are "controls" the same as "user interface components within the content" mentioned in guideline 2? I think they are, or should be, the same and accordingly that the same terminology should be used.
Proposed Change:
Change "content and controls" in Principle 3 to "content and user interface components" or, perhaps better, "content (including any user interface components it contains)".
We are trying to avoid parentheticals in the princples so Principle 3 has been updated to read, "Principle 3: Understandable - Information and operation of user interface must be understandable by the user. "
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
The content (i.e., everything within the scope of conformance), can and in many instances will consist of multiple Web units.
Proposed Change:
Change "the Web unit" to "every Web unit", or "every Web unit within the content".
Success Criterion 3.1.1 has been changed to read, "The default human language of each Web page within the content can be programmatically determined."
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
The same as 3.1.1.
Proposed Change:
Change "the Web unit" to "Every Web unit" (or whatever language is chosen to clarify this).
"Web unit" is not needed here because the requirement applies to any type of content for which a claim would be made. Success Criterion 3.1.2 has been revised to read, "The human language of each passage or phrase in the content can be programmatically determined."
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
This criterion is unnecessarily and arbitrarily restricted to form controls and fields (of forms). This restriction is undesirable.
Proposed Change:
Rewrite the sc in terms of user interface components rather than forms and fields. For example, it could be expressed in terms of changing or setting the state of a user interface component, where state would be defined to include any kind of value that the component can accept as input. Of course, there are other, simpler ways of generalizing this to user interface components.
We agree, and have updated the wording of SC 3.2.2 (formerly 3.2.3). It now reads, "Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. "
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
The mention of "tab order" is somewhat technology-specific and should be generalized in terms of changes of focus.
Proposed Change:
Rewrite the exception about tab order in terms of a change of focus to the next component in a sequence, or in other language that is suitably general.
We have removed the mention of tab order from SC 3.2.2, so your proposal has been overtaken by events and is no longer applicable.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
It isn't clear what "or other primary resources" means other than a set of Web units.
Proposed Change:
Delete "or other primary resources", or define what a "primary resource" is. The former is preferable as there are enough terms already - "Web unit", "authored unit", and "authored component". Alternatively, replace "or other primary resources" with "or authored components", as this seems the most relevant term.
Thanks for catching this editing error. We have removed the phrase, "or other primary resources" from this criterion.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
As proposed by Charles McCathieNevile in commenting on the November 2005 working draft, the term "textual interface" should be used instead of "keyboard interface". Some software interfaces do not accept keystroke input directly, but instead receive character input; they are not "keyboard interfaces" as defined in the glossary.
Proposed Change:
Substitute "textual interface" for "keyboard interface", and define "textual interface" as an interface used by software to receive characters or keystroke input. Under this definition, keystroke input is included; thus compatibility with a keyboard interface would satisfy the success criterion, as would compatibility with any software mechanism capable of receiving character input, whether from a keyboard or any other kind of input device.
This was discussed on January 12 teleconference and it was decided then to keep the current phrasing. The rationale is as follows:
The term keyboard interface here is use to refer to the API that the user agent uses to get its keystrokes from. The keystrokes include up and down arrows, function keys, and other keystrokes that are not text. The reason we use the phrase is to cover keyboard emulators (such as mouse or pen keyboards) and devices that don't have native keyboards (pda's) but accept them as accessories (via their keyboard interface). This language also matches a number of other accessibility standards and is better for harmonization.
Note also that definition of Keyboard Interface now reads:
keyboard interface
interface used by software to obtain keystroke input
Note 1: Allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
Example: A touch screen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech to text applications with "keyboard emulation" functionality.
Note 2: Operation of the application (or parts of the application) through a keyboard operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface - not through its keyboard interface.
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
This is related to user-entered or contributed content. It was brought to discussion on May 4th WCAG con call already with no conclusion. Due to the fact that you can violate WCAG with an ASCII smily face (1.1.1) or change of language without proper tag, or use of jargon, any user input can potentially violate WCAG. If the user input resurface, even as input confirmation, the web unit would automatically fail WCAG. All seach engines would fail because it cannot stop users from typing in an ASCII smily in the search box. The subsequent search result screen of finding x number, even if it is 0, of hits with the smily would fail. This is the same with foreign languages and jargon. All websites containing logon screen would fail because user can type in a smily face into the user id box, whether such user id exist or not. The system returns to confirm the id. The web unit of the confirmation just failed WCAG. All webmails would fail because incoming mails could come from a plain text mail client or contain inaccessible mail content of all sorts. Webmail cannot alter the content of incoming email without violation of privacy, at the minimum. No webmail can claim conformity. All photosites would fail because user can always put in empty or inproper alt tag of photos that they submit. All blogs would fail because user input is essential. Product user reviews, such as those in Amazon or Cnet, would fail.
The list can go on and extend to all web applications. As soon as a user agent accepts user input that are not restricted (anything other than dropdown list or radio button), they cannot conform. In fact, comment area of WCAG 2.0 last call fails because you cannot stop me from typing in jargon, foreign language, or ascii art. I'm making this violation at the botton of the mail just to make a point. Scoping out user-entered content is extremely difficult for many sites, especially when user-entered content is pervasive. How would a blog, web mail, evite, business application scope out user-entered content? Such information is essentially on every web unit.
怎么过关
wie Sie den Test führen können
:)
Proposed Change:
Add a paragraph in the comformance area that user-contributed content is automatically scoped out.
We have rewritten the conformance section to clarify that WCAG is descriptive rather than prescriptive. That is, it doesn't say what should be accessible. Rather, it is a measure of accessibility. The conformance section has been rewritten to reflect this.
A way to specify partial conformance was also added. See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#conformance-partial
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.
Item Number: H1: Adding the dir attribute to a block level element to change its directionality...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):
Says H1 is referenced from 1.3.1 but it's not. It is referenced from 1.3.3.
Proposed Change:
H1 could fall under both 1.3.1 and 1.3.3. Fix applicability so it falls under the appropriate SC.
Thank you for catching this error. After reviewing comments from the Internationalization Working Group, we believe the direction of text is only an accessibility issue when it affects the proper sequencing of mixed-direction text, so we have deleted this technique.
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
I think you should make a VERY clear statement regarding the recommended use of CSS methods (DIVs and such) over tables when it comes to page layouts. There are many discussions over this matter....
Proposed Change:
While WCAG 2.0 does not forbid the use of layout tables, the working group does discourage their use. The working group does not provide techniques about how to use layout tables, but has added an advisory technique to SC 1.3.1 titled, "Using CSS rather than tables for page layout" to describe this issue in greater detail.
Part of Item: Intent
Comment Type: TE
Comment (Including rationale for any proposed change):
The term "programmatically associated" is used but not defined.
Proposed Change:
Provide a definition of "programmatically associated" within Appendix A: Glossary.
We have reworded SC 2.4.4 to clarify its intent and to remove the term "programmatically associated". It now reads:
2.4.4 The purpose of each link can be determined from the link text and its programmatically determined link context.
where "Programmatically determined link context" is defined as:
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#pdlinkcontextdef
programmatically determined link context
1. Additional information that can be programmatically determined from relationships with a link; and
2. can be extracted, combined with the link text, and presented to users in different modalities.
Example 1: Screen readers provide commands to read the current sentence when focus is on a link.
Example 2: Examples of information that can be extracted, combined with link text, and presented to users in different modalities include text that is in the same sentence, paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The success criterion refers to "Text or diagrams". From the definiton of "text" in Appendix A:Glossary, it appears that images of text are not included. This can result in web authors using images of text (with a foreground/background luminosity ratio of less than 5:1) to circumvent this Success criterion.
Proposed Change:
Include an explicit reference to the inclusion of images of text in terms of this success criterion.
The Working Group agrees with this issue and has revised SC 1.4.3 (formerly 1.4.1) and 1.4.5 (formerly 1.4.3) as follows:
SC 1.4.3 Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 3:1.
SC 1.4.5 Text (and images of text) have a contrast ratio of at least 7:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 5:1.
We also added an advisory technique "Using unicode text and style sheets instead of images of text"
Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):
To what extent is this implicit in the definition of "programmatically determined" and all of the criteria requiring that aspects of the content must be able to be "programmatically determined"?
Does programmatic determination impose a stronger requirement than sc 4.1.1 in so far as it demands the use of representations supported by user agents? It is unclear how one could satisfy 1.3 if the user agents can't unambiguously parse the content in the first place.
Proposed Change:
There is often overlap but not necessarily always overlap. For example, two browsers might parse a document differently using repair techniques. A particular item might be programmatically determinable but be located in two different places on the page in the two renderings. It doesn’t affect the meaning, but the inability to parse the markup can break AT where it doesn’t break other browsers.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
This guideline doesn't require the use of technologies, for example markup languages, in accordance with the semantics defined in specifications. Assistive technologies such as braille translators, as well as content transformation tools, rely upon the assumption that elements and attributes of markup languages are used to convey the meanings prescribed in specifications. To the extent that content departs from this requirement, programmatic determination of structural and other aspects of content is precluded, being reduced instead to a probabilistic matter requiring heuristics to be introduced by the software developer. Although the definition of "programmatically determined" refers to support by user agents, it doesn't explicitly refer to standards governing the technologies used in the content.
Proposed Change:
Add a requirement under this guideline to the effect that, for each technology in the baseline that is defined in a specification, every feature of the technology is used in conformity with the meaning and purpose prescribed in the specification. Even better, require it to be used in accordance with the meaning, purpose and syntax prescribed in the specification. Alternatively, if the above is too strong a requirement, restrict it at level 1 to every feature used to enable the structure, purpose or meaning of the content to be programmatically determined. That is, if the feature is used to enable programmatic determination for purposes of meeting the guidelines, then it must be used in accordance with the syntax and semantics defined in the specification governing the technology. This falls short of a requirement of full syntactic and semantic correctness, but the stronger requirement could be added at level 2 or level 3.
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.
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
This criterion refers to the possibility of other versions of the content being available from the same URI. However, if the content consists of multiple Web units, there is no single URI from which the content as a whole is available, since each Web unit included in the content (i.e., within the scope of conformance) has its own URI.
Proposed Change:
Change "the content" to "each Web unit in the content", since the requirement applies at the level of the individual Web unit rather than to the content as a single entity. Equivalent language may be employed to achieve this; the above is just a suggestion.
We have moved discussion of alternate versions of content to the Conformance section of the Guidelines, and we have clarified by adding a note that addresses your concern. The revised conformance criterion reads:
"Alternate Versions: If a Web page within the scope of a claim does not meet all of the required WCAG 2.0 success criteria at the level claimed, then a mechanism to obtain an alternate version that meets the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria at the level claimed.
Note: 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)."
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
See my comment on sc 4.2.1, which applies here too.
Proposed Change:
We have moved discussion of alternate versions of content to the Conformance section of the Guidelines, and we have clarified by adding a note that addresses your concern. The revised conformance criterion reads:
"Alternate Versions: If a Web page within the scope of a claim does not meet all of the required WCAG 2.0 success criteria at the level claimed, then a mechanism to obtain an alternate version that meets the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria at the level claimed.
Note: 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)."
Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):
Should there be a criterion corresponding to 4.2.1 and 4.2.3 introduced at level 3, requiring that at least one version of (each Web unit in the) content satisfy at least 50% of the applicable level 3 success criteria? Alternatively, is it sufficient that all versions of the content together meet 50% of the relevant success criteria in order to constitute level 3 conformance?
Proposed Change:
We have changed the definition of Level AAA conformance so that all Level AAA Success Criteria that apply to the content types used must be satisfied. And we have changed the handling of alternate versions so that the former SC 4.2.1 and 4.2.3 are addressed in the Alternate Version conformance criterion, applies to all levels.
Part of Item: Intent
Comment Type: ED
Comment (Including rationale for any proposed change):
In the GL list Wendy posted the following explaination that i think would be good to add to the intent section to explain. John suggested an edit which is also included.
Proposed Change:
WCAG 1.0 says "If you can't avoid building stairs, build an elevator." It doesn't say anything about making the elevator easy to find or get to. SC 4.2.1 of WCAG 2.0 says, "If you can't avoid building stairs, provide an elevator at the main entrance, along with the stairs."
Thank you for reminding us to include this important distinction. The idea that "If you can't avoid building stairs, build an elevator." was in WCAG 1.0. WCAG 2.0 wants to ensure that making the elevator easy to find (or get to) is also important. SC 4.2.1 of WCAG 2.0 has been updated to include, "The idea behind this success criterion is; "If you can't avoid building stairs, provide an elevator that is just as easily found."
Part of Item: Techniques
Comment Type: GE
Comment (Including rationale for any proposed change):
Refer to paragraphs under Advisory Techniques for Guideline x.x starting with "Specific techniques for ..." and ending with "more accessible to more people."
Comment:
The fact that there are two categories is already stated in the introductory content at the start of the doc. The paragraph that follows this heading is unnecessarily repetitive.
Proposed Change:
Consider replacing with headings like:
- Advisory Techniques for Guideline x.x (general, not criteria specific)
- Advisory Techniques for Guideline x.x (criteria specific)
(If there are none under either category, a single word following the heading saying, “None�, is sufficient). The recommendation made is consistent with other headings like: Technology-Specific Techniques
The intent is that users jump to these "Understanding Guideline x.x" modules directly from the guidelines. As a result, they will not have read the introduction. Thus the redundancy in this paragraph with text that is in the introduction.
We think retitling " Advisory Techniques for Guideline X.X" is a good idea and have retitled it to " Advisory Techniques for Guideline X.X (not success criteria specific)"
Regarding just putting "none" we don't want people to think there are no advisory techniques, and since this doc may be broken into separate docs for each success criteria, we want to keep directions as to where to look for the other advisory techniques.
Name: Liz Danaher
Email: liz.danaher@dwpdevelopment.net
Affiliation:
Document: TD
Item Number: (none selected)
Part of Item: Related Techniques
Comment Type: TE
Comment (Including rationale for any proposed change):
Hi,
I hope you can help clarify something for me. I work on a UK government website and we\'ve recently been checking the site to ensure our colours comply with W3C checkpoint 2.2. We found your suggested algorithms here:
http://www.w3.org/TR/AERT#color-contrast
and subsequently found that some of our colours fail the algorithms for brightness and contrast. However, on checking your own site I also found that the w3.org homepage fails in some areas too.
eg. white text on biege background, brightness = 90 (fail), contrast = 306 (fail)
white text on blue background, brightness = 128 (ok), contrast = 362 (fail)
So I was just wondering, were you thinking of adding any caveats to the checkpoint 2.2, to reassure developers that if their font is above a certain size and/or weight then the algorithms may change. I do realise that you say it's only a "suggested algorithm" anyway, but I'm afraid our bosses are saying we must comply with it, and although our text is also bold and large like yours, we're facing having to redesign the whole colour scheme of our site.
I'd be very grateful if you could provide me with any more advice that you have on this subject so I can work out whether my colours are actually passable or not.
Thanks very much in advance!
Yours,
Liz Danaher
Proposed Change:
(EMPTY)
The color contrast measure that you cite in your comments is different than the color contrast specified in the current WCAG 2.0. If you look at How to meet 1.4.1, there are tools listed in the resource section that will evaluate content using the new success criteria.
Despite the changes to the algorithm, your comment is still is valid and some of the text on the w3.org home page would fail the WCAG 2.0 contrast criteria. Our hope is that these pages will be updated once the new contrast requirements become a recommendation.
Part of Item: Tests
Comment Type: QU
Comment (Including rationale for any proposed change):
Typo: "#1 and #2 are true"
There is only 1 check.
Proposed Change:
#1 is true
The technique has been updated as proposed.
Item Number: H34: Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text dire...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):
Says H34 is referenced from SC 1.3.1 but it is not. It is referenced from SC 1.3.3
Proposed Change:
H34 could fall under both 1.3.1 and 1.3.3.
Add link to H34 on 1.3.1 or remove from \"applicability\". Add 1.3.3 to applicability or remove link to H34 from 1.3.3.
The technique has been updated to reference SC 1.3.2 (formerly 1.3.3).
Item Number: Important New Terms Used in WCAG 2.0
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Very simple really; WCAG guidelines language is too technical and very hard to follow, never mind tweaking a web page to adhere to these standards, if you want universality you should write in a accessible language.
Proposed Change:
use common understandable language for 2.0!
We understand that the language is technical in places. We have tried to make it as easy to read as possible while still being technology independent and accurate. It is very hard. We have made some changes again in response to last call comments. Suggestions are always welcome.
Item Number: (none selected)
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Currently the introduction identifies cognitive limitations as one of the disabilities that WCAG 2 addresses. Unlike WCAG 1.0, WCAG 2 gives only scant recognition to the needs of people with disabilities.
Proposed Change:
Either improve WCAG 2.0 or remove the suggestion that the needs of people with cognitive limitations (or difficulties) will be met.
We have added language to the Introduction, the Conformance section, and the Quick Reference to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and to call 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, and we have proposed 3 new success criteria in this area.
Item Number: (none selected)
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
The language used in the Last Call version of WCAG 2 is considerably more readable and understandable than that used in the previous draft. However, the desire for technological neutrality means that WCAG 2 provides very little practical guidance in how to improve the accessibility of websites. The supporting documents do contain specific examples and techniques, but in reality most site developers are very busy and not particularly interested in accessibility and so there is little chance of them searching out this information.
For example, I wonder how many people are likely to realise the need to use header elements appropriately is covered by 1.3.1, "Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies."
Proposed Change:
Since at this time most people use HTML, it would be useful to include specific HTML-related example of how to implement the guidelines in the core document. With reference to the example above, include the following (which is out of WCAG 1) “User header elements to convey document structure. For example, in HTML, use H2 to indicate a subsection of H1.
In an effort to make it clear what is normative and what is informative, we have kept all examples out of the guidelines themselves. We expect many texts to be developed that would do a better job of teaching the guidelines. We have had to focus our efforts on creating a clean and concise version of the guidelines. We have tried to put links to "how to meet" next to each guideline to make it easier without putting all the informative information directly into the guidelines.
We'd also like to bring your attention to the draft "WCAG 2.0 Quick Reference" document. The WCAG 2.0 Quick Reference is a summary of all WCAG 2.0 requirements (success criteria) and techniques sufficient to meet them. http://www.w3.org/WAI/WCAG20/quickref/
Item Number: Important New Terms Used in WCAG 2.0
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
The number of guidelines that use the term "programmatically determined" concerns me. At best the glossary definition of "programmatically determined"Â? is perfunctory and the term looks to me like an example of "weasel words". A simple change to the meaning of "programmatically determined" could have a profound impact on the meaning of some important guidelines. How and who will be responsible for redefining words?
Proposed Change:
Avoid wherever possible the use of specialist terms that have the potential to qualify or distort the meaning of guidelines.
Provide a clear, unambiguous and understandable definition for all specialist terms.
Terms like "programmatically determined" are defined in the glossary, which is normative. The definitions cannot be changed without submitting updated drafts to W3C process, which requires review by the WCAG WG, the general public and the W3C.
Much effort was put into the definition of programmatically determined. We have examined it again and tried to make it easier to understand by adding some examples to the definition. The current definition, at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#programmaticallydetermineddef , is :
programmatically determined
determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities
Example: Determined in a mark-up language from elements and attributes that are accessed directly by commonly available assistive technology.
Example: Determined from technology-specific data structures in a non-mark-up language and exposed to assistive technology via an accessibility API that is supported by commonly available assitive technology.
Item Number: Conformance levels and the baseline
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
I feel the proposed system of Success Criteria is potentially confusing and misleading. The document states the proposed grouping of success criteria differs in important ways to the approach taken with WCAG 1.0 since in WCAG 1.0 each checkpoint was assigned a "priority"Â? according to its impact on accessibility. While I had some concerns of the allocation of specific levels of priority to checkpoints in WCAG 1.0, I felt the overall priority approach was effective since it was easy to understand and provided clear guidance to website owners and developers
To me the use of phrases like "achieve a minimum level of accessibility" for Level 1 SC and "achieve an enhanced level of accessibility"Â? for Level 2 SC do in effect communicate levels of impact on accessibility. As such they do not seem to be much different to the old "priority" approach.
In practice, web developers and regulatory organizations used the WCAG 1.0 Priority levels as a measure for determining levels of accessibility, and they are likely to continue to do so with WCAG 2.0.
On a related point, the Note, "For each success criterion, ..."Â? is clumsily written. I am not sure what this note is intended to communicate, but I presume it is not supposed to suggest the Working Group will be the body that will determine whether a success criterion has been met. Also, if it is possible to meet a success criterion without passing the tests for all the suggested techniques, or for that matter any of the suggested techniques, then surely some people will wonder why they should consider the suggested techniques at all.
Proposed Change:
Following the principle of "when it is not broke don't fix it"Â?, I suggest the Working Group consider retaining the "priority"Â? approach, while of course making any necessary adjustments to the priority levels of some criteria.
The note referred to earlier should be either re-written or removed.
Regarding your first point: The Levels in WCAG 2.0 differ from WCAG 1.0 as described. They were changed because it was determined that the description of the "priority levels" in WCAG 1.0 were inaccurate - so we could not use them in WCAG 2.0. The levels in WCAG 2.0 can however be seen as a type of priority or importance rating - and we expect that people will use them in that manner.
Regarding the note: The WCAG Working Group does decide what it feels are sufficient techniques for meeting the success criterion. We do not assert that they are necessarily the only techniques - and hence we state that explicitly. Thus authors are not required to use only these techniques. They are useful to authors however, in that authors can be more sure that the techniques do meet the success criteria and they have an easier time justifying this to any third parties.
Item Number: Technology assumptions and the
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
The introduction of the “baseline� could result in some web content providers believing that it is acceptable to provide content that will be inaccessible to some people with disabilities. It appears that under WCAG 2.0, a site developer or some higher authority (eg Government regulator) can set a baseline using W3C and non-W3C technologies so long as there are “assumed� accessible user agents that support them.
WCAG 2.0 allows develops to "assume"Â? a technology will be supported and provides no guidance on what this assumption should be based on. In addition, there is no definition of what constitutes an "accessible user agent"Â?. Are the early versions of PDF and Flash plug-ins accessible user agents? Or, only more recent versions? And, who decides whether a current or future user agent is accessible or not?
The guidelines provide examples of assistive technologies, but there appears to be no requirement for a nominated baseline technology to be supported by a significant proportion of assistive technologies that are in current use.
With WCAG 2.0 it appears that it will be up to the person with a disability to obtain (purchase) the technology, which the site proprietor deems appropriate, in order to access a site, rather than the responsibility of the site proprietor to ensure their content is accessible to users of a wide range of assistive technologies. Such a requirement is unreasonable, especially given the high unemployment rate among people with disabilities, and it is also not in accord with "beneficial"Â? approaches to disability such as those adopted in disability discrimination legislation. Such approaches recognise that everyone has a responsibility to make society more universally accessible.
Finally, I am concerned the introduction of the proposed "baseline"Â? concept will place a greater burden on organizations who are responsible for promoting and ensuring best practice in the area of website accessibility, in many different countries.
Proposed Change:
In my view the whole baseline concept needs to be revisited. However, since this is unlikely I would like to suggest the Working Group considers the following.
1. Avoid the use of the words "assume" and "assumed"Â?. If they are used, provide a clear indication of what can and cannot be assumed.
2. Define what is meant by an accessible user agent (as distinct from a user agent).
3. Include a requirement for all technologies used on a site to be supported by a wide range of assistive devices that are at least one generation older than the version in current release. (Clearly there will be a need to indicate what is a "wide range" and the number is likely to be different for different technologies - eg for screen readers perhaps it might be four programs whereas for magnifiers it might just be two.)
The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section " Accessibility Support of Web Technologies", at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .
Item Number: (none selected)
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
There doesn't seem to be a place to comment on the Baseline Document, so I'll post it here:
http://www.w3.org/WAI/WCAG20/baseline/
The potential for many baselines is possible, and each baseline will have an overall level of accessibility associated with it. For example, a baseline that includes only HTML 4, is going to be more universally accessible than a baseline that includes HTML 4, Flash, Java, and Javascript. For clients or developers using the latter baseline, we would essentially tell them that if their content made full use of the Flash, Java, and Javascript accessibility features, they can comply at Level 2 (hypothetically speaking). But, for a client who creates the same site that uses the first baseline (HTML 4 only), and has gone to the trouble of creating alternatives for their Flash, Java, and Javascript content, will have created a more accessible site than the site that uses second baseline and does not have any alternative formats. What motivation would there be for the developer of the site using the first baseline, if they can just place all the technologies in the baseline, and forget about creating more accessible alternative content.
Proposed Change:
The solution to this may be associating some base accessibility value with a variety of standard baselines, baselines which remain non-normative, and evolve as technologies evolve.
The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section " Accessibility Support of Web Technologies", at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .
Item Number: Technology assumptions and the
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
For the section prior to ...assumptions and the baseline... which isn't included in the items that can be commented on.
References are made to Level 1 2 3, then Note 1 that follows refers to Triple-A conformance. Prior to this though, there has been no mention of A, AA, AAA confomance rankings. Novices to the guidelines may not make the connection if it is not described explicitely. Not until much further down the page is the association made.
Proposed Change:
Perhaps a note explaining the association, or a reference to an anchor further down the page would be appropriate here.
We have completely rewritten the introduction and the conformance section, and conformance levels are now defined before they are used.
Item Number: Technology assumptions and the
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
There is a relatively easy possibility of Level AAA compliance by virtue of ommision. By default, the vast majority of sites will meet 50% of the level 3 guidelines without trying. The following are arguably not relevant on most Web sites.
---------------------
Irrelevant for most sites
1.2.5 (w/ no MM)
1.2.6 (w/ no MM)
1.2.7 (w/ no MM)
1.4.3 (use standard B/W)
1.4.4 (with no audio content)
2.1.2 (with no time dependence)
2.2.4 (no timed events)
2.2.5 (no auto updated content)
2.2.6 (no timeout)
2.3.2 (use no flashing components)
2.4.6 (don\'t use tab to create inconsitent tab ordering
3.1.6 (write in an alphabetic language)
3.2.5 (use no auto redirects)
4.2.4 (use only baseline technologies)
---------------------------
Potentially 13 L3 met by omission
So without any extra effort, a site without any of the above technologies would meet enough level 3 criteria to comply, even though none of the guidelines are relevant.
Things that could be done relevant to the content of the majority of sites
Relevant to most sites
2.4.5 (use descriptive titles, headings, and labels)
2.4.7 (use breadcrumb links to navigate, and identify location within a hierarchy)
2.4.8 (use meaningfult link text)
2.5.4 (describe expected input for form fields)
3.1.3 (provide a glossary)
3.1.4 (expand all abbreviations)
3.1.5 (Use low level language)
---------------------------
Potentially 7 L3 relevant to most sites.
Proposed Change:
Perhspa 75% of level 3 items would be more appropriate, or maybe 50%, which includes at least 4 or 5 items (or maybe all) from the second list of more common level 3 items.
We have changed the definition of Level AAA conformance so that all Level AAA Success Criteria that apply to the content types used must be satisfied.
Item Number: Conformance claims
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Re: Conformance notes.
http://www.w3.org/TR/2006/WD-WCAG20-20060427/conformance.html#conformance-claims
The Note suggests that the default version of the content displayed (i.e. Web unit that is returned when no negotiation is conducted) is the one that must comply. This would mean that myself for example, as a fully able user with no content negotiation enabled, would be forced to view the most accessible version of a content unit, despite, perhaps, a less accessible, more interactive, "flashy" version being more appropropriate for my needs.
Proposed Change:
I think the second statement (in parentheses) "...one of the negotiated forms must comply" makes more sense as the default here, with perhaps the added note that "...the most accessible version is easily accessed should the primary version not be accessible". A common example is the Flash splash page that includes a link to an accessible HTML version of the same content. In the initial statement it suggested that as a developer I would have to default to the HTML version of the page, with a link to the Flash version instead. Developers and their clients will not agree to this, but they will agree to a link that leads to a more accessible version..
We have removed discussion of content negotiation and moved requirements related to alternate versions to the Conformance section of the Guidelines. The revised conformance criteriaon now reads:
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.
Item Number: Success Criterion 1.2.2
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Guideline 1.2
Guidelines 1.2.2 and 1.2.3 are not mutually exclusive. Perhaps it should be, if an audio description is provided, compliance is at level 2. If a transcript is provided instead, compliance is at level 1.
1.2.2 "Audio descriptions of video, or... are provided for prerecorded multimedia."
1.2.3 "Audio descriptions of video are provided for prerecorded multimedia.
Proposed Change:
Drop "Audio descriptions of video" from 1.2.2. Audio description are relatively difficult to implement, while text transcripts are quite easy. Leave the transcript at level 1, which is attainable by everyone, and keep audio descriptions to level 2.
SC 1.2.2 and 1.2.3 are indeed not mutually exclusive. If they were, we couldn't have them both as success criteria. However, making the change you suggest would remove options for authors at level A. In some cases it is easier and/or more effective to provide the full text alternative. In other cases it is easier and/or more effective to provide the audio equivalents. The current wording allows the author to chose at level A, but does require them to use audio description at level AA. Audio description would of course satisfy both level A and AA if it were provided. Therefore removing Audio Description from level A would make it harder for authors, not easier since it removes an option.
Item Number: Success Criterion 1.2.7
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Guidelines 1.2.2 and 1.2.7 are not mutually exclusive.
1.2.2 "... a full multimedia text alternative including any interaction, are provided for prerecorded multimedia."
1.2.7 "For prerecorded multimedia, a full multimedia text alternative including any interaction is provided
Proposed Change:
Drop 1.2.7 in favour 1.2.1 at level 1, with Audio descriptions removed in favor of keeping them with 1.2.3 at level 2.
Correct. SC 1.2.2 and 1.2.7 are not mutually exclusive. If they were we could not require both. The option is provided at Level A. At level AA Audio descriptions are required (which would also satisfy level A). At level AAA the text description is required, which would be in addition to the audio description required in level AA. The working group did not want to require SC 1.2.7 at level A but did want to have it as an option there and as a level AAA success criterion if it was not provided at level A.
Item Number: Success Criterion 1.4.1
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Guideline 1.4
Luminosity Contrast Ratio in its current form appears to be a less than perfect measure of contrast. For example black text on a white background is more readable than white text on a black background, yet both have the same ratio. In the future as the algorithms for measuring contrast become better, the suggested 5:1 ratio in 1.4.1, may no longer be valid.
Proposed Change:
A general statement should be made in the guideline, something like ...use foreground and background colours that provide sufficient contrast...", and move LCR and the suggested ratio to the techniques document, where it can be adjusted as measure of contrast become better defined.
The change you propose would make the success criteria untestable. All success criteria need to be testable to qualify. So we need to provide specific description of what 'sufficient contrast' is.
Item Number: Success Criterion 1.4.3
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
As suggested for 1.4.1, Luminosity Contrast Ratio in its current form appears to be a less than perfect measure of contrast. For example black text on a white background is more readable than white text on a black background, yet both have the same ratio. In the future as the algorithms for measuring contrast become better, the suggested 10:1 ratio in 1.4.1, may no longer be valid.
Proposed Change:
A general statement should be made in the guideline, something like ...use foreground and background colours that provide *high* contrast...", and move LCR and the suggested ratio to the techniques document, where it can be adjusted as measure of contrast become better defined.
The change you propose would make the success criteria untestable. All success criteria need to be testable to qualify. So we need to provide specific description of what 'sufficient contrast' is.
It is not always true that black text on a white background is more readable. For older people and people with impaired vision white on black is generally more readable because there is less light scatter (for media opacities) and fewer problems with adaptation levels.
Item Number: Success Criterion 2.2.1 <-- this appears to be a typo
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
I'm not sure about the distinction between 2.1.1 and 2.1.2. Does it mean if there is required time dependant content, such as a reaction time test, the web unit can not comply at level 3. This could potentially be an issues, albeit unlikely, if a site were pursuing Level 2 or 3 conformance, but had a time dependant test, for example.
Proposed Change:
In such a case I would expect an accessibility statement or statement of scope to exclude the timed test, thus rendering the guideline irrelevant to a claim of Level 2 or 3 compliance. 2.1.2 sounds like it may not be enforcable. Perhaps remove it.
It is the specific intent that timed content such as timed tests not be able to conform to this success criterion. The goal is to encourage the development of other non-time-based forms instead.
Item Number: Success Criterion 3.1.5
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
Though for public content, guideline 3.1.5 would apply, for non-public content, such as an online course aimed at a professional audience, there should be no requirement that it be "lower secondary" .
How will evaluators measure language level. Perhaps using a FOG index for English. How would they assess across languages, where a FOG index is not valid? Would lower secondary be too high when an audience is from a third word country, where reading levels tend to be much lower? There has to be some acknowledgement of the audience reading the content. I thought I had suggested in a previous review of a WCAG 2 draft, that audience be worked into the baseline, though I can't find the specific reference at the moment. I understand that would complicate things significantly. If not included in the baseline, there does need to be some way to define the acceptable level of language for the intended audience.
With regard to including the audience in a measure of readability, see:
http://en.wikipedia.org/wiki/Readability
Proposed Change:
It might read something like "Where information is aimed at a non specific audience, for which reading level is unknown....use lower secondary..."
Even specific target audiences may contain people who can understand the subject matter but have disabilities that make it difficult to deal with complex text. While reducing the complexity of the text will help all such people, the success criterion only requires additional supplementary material that will assist some of those users.
We agree that all computerized readability programs have limitations, but they can be helpful in providing an easy check for whether the language used is clearly above or below the lower secondary level.
The working group has no solution to problems of differing literacy levels, except as this is reflected in the definition of lower secondary level for different cultures. Low literacy levels as a result of lack of education, rather than cognitive disabilities, is outside the charter of the working group.
Item Number: How to Meet Success Criterion 3.1.5
Part of Item: Intent
Comment Type: GE
Comment (Including rationale for any proposed change):
The statement "help people with reading disability" in the intent section of the How to meet 3.1.5 section is incorrect. The ability to comprehend high level language is not related to reading disability. Reading disability is strictly associated at a more general level with lessened ability to mentally convert visual textual information, into verbal auditory information (phonemic awareness). There is no concept of sematic disability associated with reading disability. By definition, a person with a reading disability does not have a sematic processing disability, with normal or above normal intelligence. There are several references throughout the HowTo document that refer to reading disability as an inability to understand. These statements need to be removed. They are not true (see: howto 3.1.6). Reading disability does not affect a person's ability to understand.
Proposed Change:
Remove references to to simplified language being an accomodation for those with a reading disability.
We have revised the descriptions of the benefits of different success criteria for people with cognitive disabilities by using descriptions that are based on functional limitations.
Item Number: Success Criterion 3.1.6
Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):
Is guideline 3.1.6 relevant to alphabetic langauges. I was unable to determine the meaning of this guideline as it applies to English, or other alphabetic languages. If it is relevant to alphabetic languages, examples should be provided, or it should be stated that it applies to syllabic, or orthographic languages.
Proposed Change:
Guideline 3.1.6 is indeed relevant to alphabetic languagues. Examples have been added to the "Intent of this success criterion" section of "How to Meet 3.1.6" to illustrate this. The revised section reads as follows:
"For example, in the English language heteronyms are words that are spelled the same but have different pronunciations and meanings, such as the words desert (abandon) and desert (arid region). Additionally, in some languages certain characters can be pronounced in different ways. In Japanese, for example, there are characters like Han characters(Kanji) which have multiple pronunciations. Screen readers may speak the characters incorrectly without the information on pronunciation. When read incorrectly, the content will not make sense to users."
Item Number: Success Criterion 4.1.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
In guideline 4.1.1 does "parsed unambiguosly" mean "well formed" or "valid"? The techniques seem to suggest that markup must be valid, though you would be hard pressed to find invalid code that disrupts any relatively recent screen reader's ability to read a Web unit. It takes severely broken markup to affect accessibility, or specific types of errors (such as broken table structures). While I am all for valid markup, it is *not* a requirement for accessibility in most cases, particularly at level 1. I can see this requirement at level 2 perhaps.
Proposed Change:
What would be appropriate here to have a well formed requirement at level 1, and valid at level 2. And still this really has to do with compatibility with future technologies, rather than affects on accessibility using current technologies.
We have reworded SC 4.1.1 to require that content can be parsed without error.
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 4.2.1
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Guideline 4.2.1
This guideline does not read like a guideline (same with 4.2.3), is not immediately clear what it means without reviewing the HowTo, and can be interpreted in different ways (i.e. ...may [also] be, or ...may [instead] be...). I interpret it first as meaning I can include a link from the accessible version to the innaccessible version. In fact it should be the opposite that is true (and I'm sure based on the howto that is what was intended), including a link from the innaccessible version to the accessible one.
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, and we have clarified by adding the following conformance requirement
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 updated the understanding document to clarify situations when different sufficient techniques would apply.
Item Number: G18: Ensuring that luminosity contrast of at least 5:1 exists between text ...
Part of Item: Tests
Comment Type: ED
Comment (Including rationale for any proposed change):
Procedure step #4 does not exist.
Proposed Change:
Renumber the steps or change the step number.
The procedure section has been updated to include the correct number of steps.
Item Number: G17: Ensuring that luminosity contrast of at least 10:1 exists between text...
Part of Item: Tests
Comment Type: ED
Comment (Including rationale for any proposed change):
Expected results - there is no point #4
Proposed Change:
Add other points or change number.
The procedure section has been updated to include the correct number of steps.
Part of Item: Related Resources
Comment Type: TE
Comment (including rationale for proposed change):
Should consider adding the following reference in the related resources area.
http://www.w3.org/TR/turingtest/
Proposed Change:
Should consider adding the following reference in the related resources area.
http://www.w3.org/TR/turingtest/
The working Group agrees and has added http://www.w3.org/TR/turingtest/ to the Related Resources section of "How to Meet SC 1.1.1".
Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):
2.4.4 Each link is programmatically associated with text from which its purpose can be determined. (Level 2)
“The intent of this success criterion is to help users understand the purpose of each link in the content�
The intent of the criterion is not met by the use of technique H33.
Critisisms of Technique H33
“User agents will display a tool tip when the mouse hovers above an anchor element containing a title attribute.�
1. Current User agents do not provide access to title attribute content via the keyboard [1]
a. Will result in content not being accessible by non-mouse users who do not use screen reading software.
b. Contradicts the intent of Guideline 2.1 Make all functionality operable via a keyboard interface.
c. Contradicts the intent of Guideline 4.2 Ensure that content is accessible or provide an accessible alternative, because the technique does not include advice that an accessible alternative version of the content within the title attribute be provided.
2. The “tool tip� in some commonly used user agents disapears after a short period of time (approximately 5 seconds) [1]
a. Will result in difficulty accessing title attribute content for those users who can use a mouse, but have fine motor skill impairment.
b. May result in reading difficulties of title attribute content for users with cognitive/learning impairment.
c. Contradicts the intent of Guideline 2.2 Allow users to control time limits on their reading or interaction.
3. Presentation of title attribute content cannot be resized or colours changed via the user agent or by the content author.
a. The foreground and background colours of the “tool tip� cannot be modified by the user via the user agent.
b. The size of the text within a “tool tip� cannot be modifed by a user via the user agent.
c. Contradicts the intent of Guideline 1.3 Ensure that information and structure can be separated from presentation
4. The placement and location of the “tool tip� cannot be modified by users.
a. This results in some screen magnifier users being unable to access meaningful portions of the title attribute content, because the “tool tip� cannot be fully displyed within the view port [2].
Assistive technology issues
Three pieces of assistive technology are cited in the “User Agent and Assistive Technology Support Notes� [4]. Two of those cited do not provide a practical or functionally equivalent method for users to access the information within the title attribute of links.
JAWS 7.0
“JAWS 7.0 will speak either the link text or the title attribute for a link depending upon a JAWS setting. This setting can be changed temporarily or permanently within JAWS.�
Discussion
JAWS does not provide a practical or functionally equivalent method for users to hear the content of a link’s title attribute
If a user has JAWS set to read “Title text� for links they cannot access the “screen text� without changing the JAWS verbosity settings (This process involves a minimum of 7 keystrokes / keystroke combinations and in 5 out of 7 tests caused JAWS to start reading again from the top of the page, thus losing focus on the link that had a potential “title text�.).
So in Example 2 (
Table 1) of technique H33 a JAWS user with verbosity set to “use title� for links would hear
“link opens in new window�
, but would not hear
“Subscribe to email notifications about breaking news�
, nor would they be given any indication that this additional information was available and could not access the information without going through these steps:
In order for a user to change the verbosity setting for links a user must:
“press INSERT V to open the Adjust JAWS Verbosity dialog box. Select an option with the arrow keys and then press SPACEBAR or use the Execute button to cycle through the available settings. Press ENTER to accept your changes and close the dialog box. “ [3]
Conversely if the user had the default “screen text� settings they would not hear the information \"link opens in new window\" nor would they be given any indication that this additional information was available.
Table 1 H33: Supplementing link text with the title attribute - Example 2
<a href=\"http://www.newsorg.com.com/subscribe.html\" target=\"_blank\" title=\"link opens in new window\"> Subscribe to email notifications about breaking news</a>
Homepage Reader 3.04
“Home Page Reader 3.04 will speak the title attribute of any element with focus when the control-shift-F1 keys are pressed simultaneously.�
· This is not a documented feature of HPR 3.04. The documentation in reference to this states that the URL of the page will be read out (no mention of the title attribute).
· The title attribute content is read out, but after the URL of the current page is read.
· The user has no way to know that there is supplementary information available unless he/she activates the key combination. It is totally impractical to expect users to query each link to find supplementary information.
References
1. Display of the TITLE attribute in some common browsers - http://www.sf.id.au/WE05/#slide7
2. Screen Magnifier users - http://www.sf.id.au/WE05/#slide12
3. JAWS 6 documentation - JAWS 6.20 documentation [EXE file, 1.57 MB]
4. Technique H33 - Supplementing link text with the title attribute http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H33
Proposed Change:
Remove technique H33
We have added the information you provided to the list of user agent notes for this technique. The working group would like to see better user agent support for the title attribute, but feels that this should reamain a sufficient technique while efforts to improve user agent and assistive technology support are made. It has been made an advisory technique for SC 2.4.8, since the link text itself must be sufficiently descriptive without depending upon the title attribute content to meet that criterion.
Because title attributes should only be used for supplementary information, we have added a sentence to the Intent section "If the supplementary information provided through the title attribute is something the user should know before following the link, such as a warning, then it should be provided in the link text rather than in the title attribute." We also included a Failure Example where the title attribute contains non-supplementary information about the link.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
1.3.2 (color alone) is not sufficiently disambiguated from 1.3.4 (variations in presentations in text). Two of four examples, and only Common Failure, in UNDERSTANDING should be associated with 1.3.4. The implication is that 1.3.4 should be Level 1.
Proposed Change:
Promote 1.3.4 to Level 1. It may then be possible to demote 1.3.2 to Level 2 or 3.
I am also commenting on UNDERSTANDING and TECHNIQUES but with the assumption that 1.3.2 and 1.3.4 are correct as-is.
SC 1.3.4 has been folded into SC 1.3.1, in order to clarify that text variations are one of many types of design that must be semantically identified. SC 1.3.2 is thus more clearly specifically about the non-semantic aspect of the visual design specific to color.
SC 1.3.2 was previously a Level AA success criterion. The Working Group decided between January 17th and February 24th, 2006, to elevate it to Level A because of the desire to require a visual differentiator for color blind users. If SC 1.3.2 is moved to Level AA and SC 1.3.4 is moved to Level A, then all that would be required is for the color change to be programmatically determinable.
To clarify situation, we have created a new sufficient technique for SC 1.3.2 situation A: "Using semantic markup whenever color cues are used" (and reference H49).
Part of Item: Techniques
Comment Type: ED
Comment (including rationale for proposed change):
The following Examples are currently associated with 1.3.2:
Situation A: If the color of particular words is used to indicate information.
Ensuring that color encoded information is also available in text.
Including a text cue whenever color cues are used
The above are too broad for 1.3.2 and should be associated only with 1.3.4.
Proposed Change:
Move the above to 1.3.4.
Add example of using colored text that is also bold and italic as a way to satisfy 1.3.2.
We have added a technique to Situation A in "How to meet 1.3.2" that reads, "Ensuring that when text color is used to convey information, the text style is visually differentiated without color."
Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):
G14 is associated with 1.3.2. As written, it is too restrictive and is more applicable to 1.3.4. Unfortunately, that does not leave a technique for 1.3.2.
I have also commented that 1.3.4 may be rated at too low a level. This comment assumes that 1.3.2 and 1.3.4 remain unchanged.
Proposed Change:
Associate G14 with 1.3.4.
Just one idea: Add a technique for 1.3.2 where red H3 headings are underlined and green H3 headings are italicized.
We have added a technique to Situation A in "How to meet 1.3.2" that reads, "Ensuring that when text color is used to convey information, the text style is visually differentiated without color."
Part of Item: Intent
Comment Type: TE
Comment (including rationale for proposed change):
May want to add advisory technique to skip over non-baseline content.
Proposed Change:
Add the optional/advisory techniques to skip over non-baseline content.
We have added an advisory technique "Providing a mechanism to skip non-accessibility-supported content" to Conformance Requirement 6.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
Guideline 2.4 is concerned with providing mechanisms to help users find content, orientate themselves within it and navigate through it. Nearly all text-based information on the web is currently presented using (x)html, and WCAG 1.0 required the appropriate use of header elements to convey the structure of these documents. That is, the H1 header element should be used for the main heading of the page. Subsequent headers (H2, H3 etc) should be used to identify and present different sections and sub-sections of content on the page.
Many users of assistive technologies rely on appropriate header elements to skim through information and easily locate the different sections of a page. The Last Call draft puts the requirement to use headers appropriately under SC 1.3.1. I am concerned that if there is no specific SC relating to this issue, we will increasingly see a range of different CSS classes being used to identify (and control the presentation of) headings or heaven forbid, a return to the font element. Such a situation will greatly compromise the ability of screen reader users to find content and navigate through documents.
Proposed Change:
Given the importance of well-structured headers for screen reader users, I believe Guideline 2.4 should contain an additional Level 1 Success Criteria that reads, "Each heading and subheading is presented using appropriate header elements that reflect the structure of the document and can be reliably interpreted by users agents including assistive technologies."
Appropriate use of headers is covered under SC 1.3.1. In particular, "Failure of SC 1.3.1 and 1.3.4 due to using CSS to create variations in presentation of text that conveys information without also using the appropriate markup or text" prohibit CSS classes or font usage without appropriate heading markup. However, because of the importance of headings to navigation, we have added discussion to How To Meet 2.4, drawing attention to SC 1.3.1 and the role of headings in navigation.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 2.4 is concerned with providing mechanisms to help users find content and orientate themselves and navigate through it. However, I am concerned that there does not appear to be a success criteria relating to the need to title frames whereas WCAG 1.0 had a Priority 1 issue relating to this.
Although the use of frames has diminished and modern screen readers are much better at handling frames, a significant number of sites still contain frames. Many people, who depend on screen readers, continue to use older version of their technologies, often for financial reasons, and have problems orientating themselves in framed sites and navigating through these sites.
Proposed Change:
I suggest Guideline 2.4 should contain a new Level 2 Success Criteria that reads, \"When a web unit contains frame elements, each frame has an appropriate title to facilitate frame identification and navigation.\"
We have included a sufficient technique about providing titles for frames to Success Criterion 4.1.2 titled "Using the title attribute of the frame element."
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 1.4 is concerned with making it easy to distinguish foreground information from the background. Many people with impaired vision, including a significant proportion of the older population, often find it hard to read the default text size. The use of absolute values for font sizes can make it very difficult for people with impaired vision to increase the size of the text on the screen. Sometime these people have the knowledge and opportunity to change the default computer settings but this is often not the case.
Proposed Change:
I suggest Guideline 1.4 should contain a new level 2 Success Criteria that requires the use of relative rather than absolute values to control the size of all text including headings.
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.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 4.1 is concerned with ensuring compatibility with current and future user agents including assistive technologies. However, within WCAG 2.0 there does not appear to be any requirement to avoid the use of deprecated W3C technologies. Also there is no explicit indication that layout tables should not use structural markup for the purpose of visual formatting. It appears that many of the issues relating to the use of tables are intended to be covered by SC 1.3.1, however the HTML techniques relating to this SC in the \"Understanding WCAG 2.0\" document make no reference to the inappropriate use of table markup.
Proposed Change:
I suggest Guideline 4.1 contain a Level 1 Success Criteria which reads, \"When a table is used for layout, it does not use structural markup for the purpose of visual formatting.\"
I suggest Guideline 4.1 contain a Level 2 Success Criteria which reads, \"Deprecated features of W3C technologies are not used.\"
The Working Group agrees that misuse of layout tables should be a failure. However 1.3.1 is the proper place for this and this is covered by two HTML failures under 1.3.1 titled "Failure of SC 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables" and "Failure of SC 1.3.1 due to using structural markup in a way that does not represent relationships in the content".
RE Deprecated W3C technologies: [The Working Group assumes this refers to deprecated features rather than deprecated technologies.] Not all deprecated features are accessibility issues or problems for assistive technologies. A blanket prohibition is therefore not felt to be appropriate. If we receive information about any such issues that we don't already know about, we will create failure techniques for them."
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
Guideline 4.2 relates to the need to ensure content is accessible or provide an accessible alternative. I am concerned that overall, WCAG 2.0 does not sufficiently recognise the needs of people with cognitive disabilities or limitations and this guideline in particular does not appear to specifically address these needs.
In my country (and I imagine in most others) people with cognitive disabilities and learning disorders represent the largest proportion of the population with disabilities. In its current state, WCAG 2.0 could leave a site developer, who is keen to improve the accessibility of a site for people with cognitive disabilities, with the incorrect impression that all they need to do is ensure the content is at an appropriate reading level.
WCAG 2.0 should not avoid addressing the needs of people with cognitive disabilities with the vague excuse that it is not immediately possible because today\'s technologies and user agents do not adequately support content negotiation.
Proposed Change:
I strongly urge the Working Group to provide more comprehensive guidance in how to improve the accessibility of web sites for people with cognitive disabilities and learning disorders in WCAG 2.0.
I suggest Guideline 4.2 (and the associated documents) should specify different ways of improving the accessibility of content for people with cognitive disabilities and learning disorders. Also, the Guideline should clearly indicate appropriate ways of providing accessible alternative content.
The former Guideline 4.2 (which has been incorporated into the Conformance section) permits multiple versions of content, so that specialized presentations for people with cognitive, learning, and language disabilities can be provided.
We have added language to the Introduction, the Conformance section, and the Quick Reference to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and to call 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, and we have proposed 3 new success criteria in this area.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Success Criteria 2.4.1 is a Level 1 criteria concerned with provide mechanisms that will allow users to by pass blocks of content that are repeated on different web pages, eg navigation menus. The HTML techniques relating to this SC in the Understanding WCAG 2.0 document include the use of skip links, but there does not appear to be a requirement to make the skip links visible.
Skip links allow the user to bypass sections of the page. However, skip links that are not visible offer no benefit to sighted users of the web who rely on switching devices.
A user who is dependent on a switching device, such as a pressure switch in a headrest or a \'suck –puff\' straw, often has to physically activate the device many times as they tab though many navigation links on their way to the page content. The inclusion of a visible \"skip to content\" link at the top of the page would allow them to jump directly to the content.
Proposed Change:
I suggest the Working Group explicitly require skip links to be present and to be visible.
This issue has been discussed by the working group many times. Providing skip links that are visible is one instance that satisfies SC 2.4.1 (A mechanism is available to bypass blocks of content that are repeated on multiple web pages), but is not required. Providing visible skip navigation links was considered a difficult requirement for all content at Level A because of the potential for visual clutter making content harder to understand. However, the Working Group recognizes the importance of visible skip navigation for switch users, those using techniques that generate keyboard strokes slowly and others, and have changed the Example 2 in G1 to reflect this. A note has been added which says "NOTE: When possible, a visible link is preferred over a hidden link. Visible links are necessary for those navigating with a keyboard including switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted collegues, keyboard only users and those navigating using voice recognition software."
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 2.5 states, \"Help users avoid mistakes and make it easy to correct mistakes that do occur.\" The Level 1 and Level 2 Success Criteria for this Guideline all appear to be concerned helping people recover from mistakes. The only SC that relates to avoiding mistakes in the first place is a Level 3 criterion.
Proposed Change:
I suggest the Working Group consider including more information on how mistakes can be avoided. At the least, Success Criteria 2.5.4 should be a Level 2 criterion.
We have created a Level AA success criterion intended to help users avoid errors: "Labels or instructions are provided when content requires user input".
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
I have two main concerns with 3.1.5:
First, the nominated Success Criterion is Level 3, which suggests that it is only necessary to \"achieve additional accessibility enhancements\" and does not need to apply to all Web resources (without any indication of the resources it should apply to).
Second, 3.1.5 concentrates solely on a persons reading ability, which is only one of the factors that can influence how well different people with cognitive disabilities or learning difficulties are able to understand a document. For example, what about people who can read well but have considerable difficulty negotiating a complex text-type or comprehending what is written? Or, the additional burden fully justified text and the use of long line lengths can place on many people with reading difficulties?
Proposed Change:
I suggest SC 3.1.5 be a Level 2 criterion at the minimum.
The working group agrees that writing as clearly and simply as possible is highly desirable, but could not find a way to test whether this had been achieved.
The description of conformance levels in WCAG 2 has been rewritten to clarify the levels ( see http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ) :
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.
Because of the tighter limits that this success criterion places on content, we feel it is appropriate at level AAA.
We have added new success criteria addressing scalability of text:
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.
In addition, we have added advisory techniques to improve the legibility of text:
- Avoiding justified text
- Providing sufficient inter-line and inter-column spacing
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
Actually this comment relates to the "Conformance" overview, which isn't selectable from the menu on the comments web form.
It is a concern that organizations will retain the mindset that AA conformance is enough to claim "reasonable effort" in descrimination cases, even if their environment supports easy implementation of level 3 success criteria. The change of approach from "priorities" to "levels" should be emphasised, especially that even AAA conformance does not imply that a site is accessible.
Proposed Change:
Emphasise the paragraph beginning "This method of grouping success criteris differs...", especially the last sentence.
We clarified the meanings of the conformance levels to make WCAG 2.0's use of conformance level clearer. See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels .
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
Typo.
Proposed Change:
Last sentence of "Choosing baseline technologies" should read "...users may have..." not "...users many have...".
This section has been rewritten and the error no longer occurs.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
It is not at all clear how one would provide a regular expression to scope a claim that would apply to a whole site except one or two
diretories, e.g. the whole of http://www.example.com/ except /videos/
Proposed Change:
Add examples for less straight forward conformance scope regular expressions.
An example of both a boolean and a regular expression conformance claim has been added (see http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/Overview.html#uc-239-head ):
Example 4: (using boolean logic) On 6 July 2008, http://example.com/ AND NOT (http://example.com/archive/ OR http://example.com/publications/archive/) conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Double-A (AA) conformance. The documented set of accessibility-supported content technologies used for this claim is ISA- AsCTset#1-2008 at http://ISA.example.gov/AsCTsets/AS2-2008.
Example 5: (using a regular expression) On 12 August 2008, http://www.example.com/(marketing|sales|contact)/.* conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Double-A (AA) conformance. The technologies that this content "relies upon" is: XHTML 1.0 Transitional. The technologies that this content "uses but does not rely upon" are CSS 1.0 and JavaScript 1.2.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Even after reading the \"Understanding...\" document, the difference between SCs 2.4.8 and 2.4.4 is very subtle and needs to be a lot clearer.
N.B. any link where the link text alone indicates its purpose will already meet SC 2.4.4.
Proposed Change:
Reword, along the lines of:
2.4.8 The purpose of each link can be programmatically determined from extra information related to the link.
We have reworded both SC 2.4.8 and SC 2.4.4 to clarify the differences. They now read:
2.4.4 The purpose of each link can be determined from the link text and its programmatically determined link context.
2.4.8 The purpose of each link can be identified from the link text.
where "Programmatically determined link context" is defined as:
1. Additional information that can be programmatically determined from relationships with a link; and
2.can be extracted, combined with the link text, and presented to users in different modalities.
Example 1: Screen readers provide commands to read the current sentence when focus is on a link.
Example 2: Examples of information that can be extracted, combined with link text, and presented to users in different modalities include text that is in the same sentence, paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
The success criteria, stripped of the supporting documentattion, are amazingly concise - well done to all concerned.
Proposed Change:
(none)
Thank you. We appreciate you taking the time to fill out the comment form to include this feedback.
Part of Item: Examples
Comment Type: TE
Comment (including rationale for proposed change):
"breadcrumb trail" is no more an obvious term than many others in the glossary.
Proposed Change:
Add glossary entry for "breadcrumb trail".
We agree that the term needs explaining. The glossary only includes terms that are used in the guidelines. However, the term breadcrumb trail is in a link to a technique titled "Providing a Breadcrumb Trail". Clicking on this link takes you to the technique description that begins with a description of exactly what a breadcrumb trail is and includes several examples.
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
I know this has been brought up before. I am in agreement that validity needs to be a requirement at level 2.
Proposed Change:
Put \"Create documents that validate to published formal grammars\" in as a level 2 requirement.
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.
Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):
The relationship with the main WCAG document should be bi-directional, and the document should be able to "stand alone",especially if (as I was) you're working from a printed copy of the document.
Proposed Change:
Add relevant SC text to the start of each of the "Failure" sections.
Good idea. We have changed the title "Technique referenced from" to "Failure relates to" and put the following links under that title
* SC X.X.X
* How to Meet SC X.X.X
Part of Item: Related Techniques
Comment Type: GE
Comment (including rationale for proposed change):
To aid navigation of hardcopy versions of the document, removing the need to keep refering to the table of contents.
Proposed Change:
Add the relevant section numbers to the internal link texts in "Related Techniques".
We have changed references to "Related Techniques" so that they include the Number of the techniques (e.g. H45 ) along with the name.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
The baseline concept is not wery well explained in the guidelines, and is never really defined properly. External docuemnts should not be relied upon to define key conepts.
Also, the descriptive use of \"technologies\" without further explanation is not good when you\'re really refering to data formats, markup and scripting languages (rather than software).
Proposed Change:
Provide a clearer definition / explanation of the baseline concept in the guidelines themselves.
Provide at least one example of a baseline specification (perhaps with the examples under the \"Who sets baselines?\" heading).
The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section "Accessibility Support of Web Technologies" at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
The term "luminosity" is incorrect here (it applies only to certain Broadcast video signals). Relative luninance is the correct term. When used as a ratio, the difference between absolute and relative Luminance can be dropped, but the term luminance rather than luminosity should be used.
http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixA.html#luminosity-contrastdef
defines the coefficients for calculating luminance, and its good to see that the Rec.709 chromaticities are used (rather than, for example, the NTSC ones which do not apply to modern computer monitors at all). (the coeeficients are correct, see the "luminanceToAlpha" section of http://www.w3.org/TR/SVG11/filters.html#feColorMatrix but the specification does not explain why this is so.
However the text as it stands implies that the formula given is universally applicable. it is not. This is particularly importnt when printing Web materials.
Proposed Change:
change "luminosity" to luminance throughout.
change "The luminosity of a color is defined as" to "the luminance of an sRGB color is defined as".
change "blue RGB values" to "blue sRGB values" (the equation does not apply to other color spaces).
Remove the exponentiation operator and the 2.2 gamma approximation. Instead, use the correct sRGB transfer curve.
Reference the sRGB specification. See the SVG 1.2Tiny specification for an example of how to reference it.
You may want to note that the equation given is only correct for typicalcolor vision (the ISO standard observer). For atypical color vision, often incorrectly termed color blindness, different equations apply depending on the type of atypical color vision and the degree of severity.
For more information, please see
http://www.w3.org/Graphics/atypical-color-response
Thanks for the comments and suggestions. To take them each in turn:
CL: change "luminosity" to luminance throughout.
Since Web content doesn't provide any light output (HTML doesn't give off photons) we can't use the word "luminance" (which means light output). However 'relative luminance' is used in the literature for the concept we are describing and we are now using this.
CL: change "The luminosity of a color is defined as" to "the luminance of an sRGB color is defined as".
See above regarding luminance. And, we have switched to specifying that we are talking about sRGB in our equations.
CL: change "blue RGB values" to "blue sRGB values" (the equation does not apply to other color spaces).
Correct and we have done so.
CL: Remove the exponentiation operator and the 2.2 gamma approximation. Instead, use the correct sRGB transfer curve.
Done. Now uses the equations from the W3C document on sRGB.
CL: Reference the sRGB specification. See the SVG 1.2Tiny specification for an example of how to reference it.
Done
CL: You may want to note that the equation given is only correct for typical color vision (the ISO standard observer). For atypical color vision, often incorrectly termed color blindness, different equations apply depending on the type of atypical color vision and the degree of severity. For more information, please see http://www.w3.org/Graphics/atypical-color-response.
We have explained this briefly in our "Understanding" document. A longer exposition of this will be released in a paper (since it is too complicated to put into How to Meet SC 1.4.3 itself. The contrast ratios were set higher than normal and in a way to account for low vision and atypical color vision.
The paper "Atypical colour response" has also been added as a resource.
You can find the updated SC and definitions at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#visual-audio-contrast-contrast and http://www.w3.org/TR/2007/WD-WCAG20-20070517/#visual-audio-contrast7 .
The Understanding SC 1.4.3 and 1.4.5 documents can be found at http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/#visual-audio-contrast-contrast and http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/#visual-audio-contrast7 .
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
"3.2.2 Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order), unless the authored unit contains instructions before the control that describe the behavior"
Consider a user interface for a map, where form fields such as panning controls, layer selections or search boxes are used to zoom,pan, or alter a map. This common use seems to be precluded by the text above.
Proposed Change:
I regret not being able to suggest suitable text at this time. I can see the benefit of what you are trying to do, and I can see that it makes non-confomant some interfaces that are currently used. I think the text needs to be more precise, and look forward to discussing this further with you.
User interfaces that allow the user to select different views of the same data cause changes in content, but not changes in context. Success Criterion 4.1.2 has been changed to require that user agents and assistive technology be notified of the changes in state produced by such changes in views.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I have reviewed the materials at this site and find that they are accurate.
Proposed Change:
From a user\'s and pedagogical perspective, can you simplify the documents so that they are easier for people to read? My students want to design accessible websites; however, they have difficulty interpreting the material at your site.
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page� instead of “Web Unit�)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
If it is sufficient that the change in presentation of text can be
programmatically determined, then most changes in presentation (other,
perhaps, than in bitmapped images) will meet this criterion. The user agent,
after all, requires this information in order to render the change.
However, programmatic determination of the change in presentation is not
sufficient to meet the requirements of user agents and assistive technologies
providing presentations in other modalities (or in the same modality with
different stylistic requirements according to the needs of the user with a
disability). How is the user agent supposed to map the change in presentation
to a corresponding change, whether in text or in presentation, in its
generated rendering, if the purpose or meaning of the variation in
presentation cannot be programmatically determined? In the worst case, it
could simply \"announce\" the change, e.g., \"voice pitch flat\" or \"font size
14pt\" and leave the user to try to work out the significance, if any, of this;
but a better solution is to use the capabilities of the technology to convey
the meaning or significance of the change, while also allowing \"merely
decorative\" changes having no meaningful purpose to be ignored.
This shortcoming of the current criterion is addressed in the proposal below.
Proposed Change:
\"The meaning or purpose of the change in presentation of text can be
programmatically determined\". Alternatively, just \"purpose\" could be used in
place of \"meaning or purpose\" in the above. Alternatively, keep this criterion
as is and add a more stringent requirement at level 2 or level 3.
SC 1.3.1 and 1.3.4 have been combined to read "Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies." This wording ensures that it is the meaning conveyed by the presentation that must be programmatically determined, and allows the author to indicate the meaning in text if it is not feasible to do so programmatically. The How to Meet document describes this in some detail.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Some people use the word \"diagram\" to refer only to charts, schematics and
other drawn illustrations, excluding such graphics as photographs.
If this criterion is not meant to be so restricted, it would be better to use
\"graphics\". If a restriction is meant, \"diagram\" should be defined in the
glossary.
Proposed Change:
\"text or graphics\", or add a definition of \"diagram\" (see above).
SC 1.4.3 (formerly 1.4.1) has been changed only to address text content:
"Text and images of text have a contrast ratio of at least 5:1 with their background. Text or images of text may have a contrast ratio of at least 3:1 where all of the following are true:
* Text is at least twice the height of the body text; and
* the text has a stem width of at least three times the stem width of the body text; and
* the text is presented over a non-patterned background.
Note: This requirement does not apply to text or images of text that are pure decoration."
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Same as 1.4.1 re \"diagrams\".
Proposed Change:
SC 1.4.5 (formerly 1.4.3) has been changed only to address text content:
"Text and images of text have a contrast ratio of at least 10:1 with their background. Text or images of text may have a contrast ratio of at least 7:1 where all of the following are true:
* Text is at least twice the height of the body text; and
* the text has a stem width of at least three times the stem width of the body text; and
* the text is presented over a non-patterned background.
Note: This requirement does not apply to text or images of text that are pure decoration."
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
Re the statement, \"Following these guidelines will also make your Web content more usable to many other users, including older users.\": Older users?! Really? How old? Over 40? 50? 60? Is there proof that \"older users\" need help using the Web just because they\'re over a certain age?
Proposed Change:
Delete this sentence.
Not all older people have disabilities. However, the percentage increases steadily and sharply with age. We have clarified this by changing the sentence to "Because many people develop vision, hearing, cognitive or motion impairments as they age, following these guidelines will make your Web content more usable by many older users."
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
I am doing final copy editing of a book chapter on forms.
I had talked about how clear the January version of WCAG20 was about forms:
SC 4.1.3 The label of each user interface control in the Web content that accepts input from the user can be programmatically determined and is explicitly associated with the control.
But now that has apparently been replaced by:
SC 4.1.2 For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies.
The problem is that 4.1.2 is absolutely inadequate. The \"Role\" of text input field is \"text input\"; the name could be \"keyinput\". 4.1.2 is basic software accessibility - leaving to the AT the process of figuring out what the prompt (label) is.
I just talked with John (who sounds terrific) and he pointed out that -
1.3.1 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies.
Served the same purpose as 4.1.3 - I agree. But it is abstract. It requires interpretation.
With the Last Call version of WCAG 2.0 there is no success criterion that specifically addresses labeling forms and I think that is a very serious mistake.
Proposed Change:
Please reinstate 4.1.3.
The WG feels this requirement is properly covered under 4.1.2 and did not wish to reinstate a SC that would be redundant with that. However, we agree that it's difficult for users to understand that form labeling is part of 4.1.2. We have added a failure and an advisory technique to SC 1.3.1 and 4.1.2:
F68: Failure of 1.3.1 and 1.4.2 due to the association of label and user interface controls not being programmatically determinable
Providing labels for text input or item selection form controls (future link)
Comment (including rationale for any proposed change):
The concept of baselines is misleading. One could define "AVI, TXT" as a valid baseline to tell his/her video collection "conform to WCAG 2.0" and can communicate the site as "accessible". To me this is senseless.
Proposed Change:
If there is a baseline, there should be a minimal requirement, at least for "HTML".
The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section "Accessibility Support of Web Technologies" at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .
WCAG 2.0 is technology neutral, so it would be inappropriate to require any specific technology, such as HTML. (We would, nevertheless, be surprised to find environments that did not consider HTML to be accessibility supported).
If a Web page relies on nothing but AVI and text, it would still need to satisfy all the WCAG success criteria for the level of conformance claimed.
Comment (including rationale for any proposed change):
The note "These techniques may need to be adapted for Web-based presentation" is not really helpful.
Proposed Change:
Link to examples, e.g. http://www.taubenschlag.de/videos/index.html. Add a english translation of the German guidelines for Sign Language Videos.
"These techniques may need to be adapted for Web-based presentation" is helpful because it makes it clear that there may be some distinctions between what works on TV and what works on the web. It is a sort of disclaimer that says "here are some resources that may help, but be aware that they are not designed for the web and although some strategies might be useful, others may not be transferable to the web." It is beyond the scope of these guidelines to go further than that. If someone provides techniques for web videos we will be glad to link to those.
It is beyond the scope of this group to translate German techniques documents. If somemone else does it, we will be glad to link to them if they will be helpful in meeting our guidelines.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
My main objection to WCAG 2.0 is that it is simply too big. Brevity has been abandoned in favor of excessive, often pedantic, discussion. Developers coming to WCAG 2.0 will want immediate, accessible answers that address their problems. Instead, they must follow multiple links in order to gain information about even the simplest topics (e.g., text alternatives). It\'s often necessary to wade through lengthy explanations and rationalizations before arriving at useful information, and this information is frequently cloaked in roundabout language (\"baseline?\" \"Web unit?\") that never makes a direct point.
If the W3C releases WCAG 2.0 in anything resembling its current form-- not just the guidelines document, but the related documents as well, because WCAG 2.0 can\'t really be used without them-- it must then be prepared to defend this document from backlash by a perplexed, bewildered general public. WCAG 2.0 is longer and more labyrinthine than most other recommendations published by the W3C. What does that say about accessibility? It\'s hard to achieve? It\'s overly complex? It\'s a big pain in the neck? If the WAI wants these *voluntary* guidelines to be widely adopted, they must be re-written in a concise, direct manner.
Proposed Change:
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page� instead of “Web Unit�)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Comment (including rationale for any proposed change):
Reasons of why using sign language videos are wrong.
Proposed Change:
Replace it with: "The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in the sign language to understand whole texts. Many people, especially native signers, find it easier to follow sign language than to read the text, since the text are often a second language to them."
The intent section for 1.2.5 has been revised to read:
The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions, is often a second language. Some individuals will require sign language interpretation to gain full access to the multimedia content.
Comment (including rationale for any proposed change):
The technical notes are not wrong, but misleading. One can get the impression that sign language videos are only necessary if there are captions in videos. This does not meet the reality.
Proposed Change:
Please delete this notes.
Captions are required for all multimedia at level AA (1.2.1 Captions are provided for prerecorded multimedia., 1.2.4 Captions are provided for live multimedia. ) It is helpful to discuss why signed language interpretation is needed even though captions are already available in any multimedia being considered at level AAA.
Comment (including rationale for any proposed change):
The technique "Providing a synchronized video of the sign language interpreter that can be displayed in a different viewport or overlaid on the image by the player." can be deleted. There is no need for a different viewport. The video can be placed in the same viewport, either on the same page or in an own page.
Proposed Change:
Replace this with "If the sign language interpreter expresses a content of a video you can include a sign language interpreter in the corner of the video stream. For best comprehensibility only use this technique in videos with fullscreen size."
The technique you propose would also be sufficient, so we have added it. We did not eliminate the option on the part of the author to put it into a new viewport (which could be independently scaled) because that would also be sufficient. The new technique is titled
"Providing a new page that has the video with the sign language interpretation of the audio track." You are welcome to write up this technique if you like and submit it using our technique submission form at http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/. If you do not we will try to create the technique from the notes you sent.
Comment (including rationale for any proposed change):
The technique "Including a sign language interpreter in the corner of the video stream" is only sensible for fullscreen videos, otherwise the signer is too small and not understandable.
Proposed Change:
Replace this with "Provide a video with a sign language interpreter expressing the text contents without restrictions."
The technique was adapted from TV and you are right that resizable windows on a computer screen may make the signer unreadable. But this is a user agent issue. All videos players should have a mechanism to play videos full screen. So usually it would be up to the user to maximize the screen.
However, we have added the following note to the technique G54.
Note: If the video stream is too small, the sign language interpreter will be indiscernible. When creating a video steam that includes a video of a sign language interpreter, make sure there is a mechanism to play the video stream full screen in the baseline technology. Otherwise, be sure the interpreter portion of the video is adjustable to the size it would be had the entire video stream been full screen."
Comment (including rationale for any proposed change):
The thesis "People whose primary language is a sign language sometimes have limited reading ability" is not always true. The reading ability of native signers is broad, from low to top. The focus on captions is not meeting the reality. Many native signers are able to understand captions. The focus has to move to the complete content, i.e. the texts.
Proposed Change:
Replace it with "These individuals may not be able to read and comprehend the textual contents and thus require a sign language interpretation to gain access to the multimedia content."
We have adopted your recommendation into the intent sections for SC 1.2.5 with a slight revision to indicate that this isn't true for all. It now reads as follows:
'The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in the sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions is often a second language to them. Some of these individuals may not be able to read and comprehend the textual content of captions or may not be able to read it quickly enough and thus require a sign language interpretation to gain access to the multimedia content.'
Comment (including rationale for any proposed change):
The thesis "Some people who communicate using sign language and are proficient readers may have impaired vision which may make it difficult to read the captions on the screen. A sign language interpretation may be easier to view." is misleading: Captions are zoomable, a video with a signer is not zoomable to meet impaired vision.
Proposed Change:
Suggestion: Delete it.
Your comment has been adopted and the bullet about vision impaired people reading captions has been deleted from the benefits section of how to meet SC 1.2.5.
Comment (including rationale for any proposed change):
The note "Different sites may address...sufficient by the working group" is a little bit misleading in case of deaf people.
Proposed Change:
Please add to the note that in case of deaf people it is wrong to think about deaf people as human beings not able to understand "texts above upper secondary education level". It is not about cognitive impairments, it is about linguistic matters. It is just that many deaf people understand sign language better than written language, because sign language is their mother tongue. With sign language "texts above upper secondary education level" are more understandable for deaf people.
Thanks you for your suggestion. We have replaced the sentence
"For sites designed for people who are deaf a sign language version of the page may be most useful for users who cannot understand the text well."
with the sentence
"For some people who are deaf, a sign language version of the page may be easier to understand than a written language version since sign language may be their first language."
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Level 1 SC for Guideline 1.2 should also include live captioning. By assigning live captions to Level 2, the working group is designating this as less important than pre-produced captions. In fact, live captions are arguably more important than pre-produced captions-- consider the case of an emergency alert.
Proposed Change:
Move live captioning to Level 1.
The group considered this carefully. Part of the criteria for Level A is that it can reasonably be applied to all Web content. Unlike captioning for prerecorded video, live captioning can not be done by the author, but requires people with very specialized training and skills to transcribe in real time.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
A full multimedia transcript is not an alternative to audio description. (In fact, I doubt its usefulness in general.) Audio descriptions should be required at Level 1, period.
Proposed Change:
Delete the reference to a full multimedia transcript. Move 1.2.3 up to 1.2.2.
After much discussion, the group felt that a full transcript should be allowed as an alternative. A full transcript provides all the information from the multimedia (visual and auditory). That has been our measure for an accessible alternative. It does not provide the same experience, but text alternatives to graphics do not provide the same experience either. In addition, audio-description does not always provide all of the information that is presented visually. For example audio description may not provide all of the information in a training video which is almost all speaking over top of the visuals. In this case, a full text alternative (audio and visual) would give more information than just an audio description.
It was decided to allow the option to provide either audio description or a full text transcript at level A.
Comment (including rationale for any proposed change):
As far as I understand http://www.w3.org/TR/WCAG20-TECHS/#N100C7 (or http://www.alistapart.com/articles/tohellwithwcag2 which translate it into point 12 : « CSS layouts, particularly those with absolutely-positioned elements that are removed from the document flow, may simply be <http://www.w3.org/TR/WCAG20-TECHS/#N100C7>; prohibited at the highest level. In fact, source order must match presentation order even at the lowest level. », I can't agree with that.
Proposed Change:
http://blog.html.it/layoutgala/ shows 40 design based on the same markup, but with differents visual apparences and ordering. It is accessible! Accessibility means that the content must be *understandable* without the CSS, not that it should be presented in the same order.
Failure 1 does not prohibit CSS layouts generally: it only prohibits CSS layouts that change the meaning of the content. For example, positioning a navigation bar does not change the mearning of the content.
We have revised the last sentence of the description of this technique to make this clearer. It now reads, "Thus, it is important not to rely on CSS to visually position content in a specific sequence if this sequence results in a meaning that is different from the programmatically determined reading order."
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Live audio descriptions must also be included in Level 1 SC for Guideline 1.2.
Proposed Change:
Insert a requirement for live audio descriptions into Level 1 SC for Guideline 1.2.
Unless live action is scripted, there is no way to know when the gaps will occur so that live audio description can be done (unless it is video footage which essentially has no audio dialog or, you are going to delay broadcast by some significant amount).
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
It is unrealistic to ask authors to provide an alternative version of a Web site, or any other material, using language written at a lower reading level than the original material.
Proposed Change:
Delete requirement 3.1.5.
Providing an alternate version that is easier to read is one of the forms of supplemental content that satisfies SC 3.1.5, but is not required. This is also at Level AAA, so it may not be possible for all Web pages.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
These comments also apply to 1.4.1:
1. Is it realistic to expect authors to do the math to figure out the luminosity contrast ratio?
2. Why isn\'t MathML used to represent the equations?
3. If the only difference between 1.4.1 and 1.4.3 is the ratio (5:1 vs 10:1), then drop one ratio and therefore one needless requirement.
Proposed Change:
1. Use MathML to represent the equations.
2. Eliminate either 1.4.1 or 1.4.3, preferably the latter.
3. Reconsider the expectation that authors will determine contrast through the use of the luminosity contrast ratio. Did anyone in the working group poll authors to see if this is realistic?
Authors do not have to use the luminosity contrast ratio to determine their contrast ratio. In the resources section, a list of tools have been provided that already do this. One uses an eye dropper and is very easy to use. We have added a note to the intent sections of both SC 1.4.3 (formerly 1.4.1) and SC 1.4.5 (formerly 1.4.3) that refers to the list of these tools to make it more obvious that these tools are available.
Because support for MathML varies across browsers and platforms, because the information from the equations can be mis-presented in some cases, and because it was possible to represent the luminosity contrast ratio in ASCII, a MathML version of the equations was not included in the guidelines themselves. We have, however, added a note to the definition which points to a MathML version. Should support MathML change prior to publication, we will include this version in the guidelines themselves.
The working group determined that there is a significant improvement of readability between 10:1 and 5:1 but that 5:1 was sufficient in most cases and 10:1 is very demanding, basically white on black or vice versa.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Rationale: In my experience, simple magnification is not very helpful for reading web pages. Visual readers with print disabilities always need more. Now, lots of software labeled \"screen magnifier\" does more than magnify, but some products just zoom and that is not very helpful. In the WCAG 2.0 Glossary definition of Assistive Technology, the example of screen magnifier is the only remedy given for individuals with partial sight. There are no examples, other than screen readers, given for other print disabled readers who are sighted. I am afraid that developers who want to test WCAG 2.0 compliance will test against screen magnifiers (especially simple zoom magnifiers) and conclude they have met the needs of sighted users with print disabilities. The example does mention change in color, but there are many other style changes that assist visual reading. Also, motor limitations cause some print disability rather than the more common conditions, dyslexia or partial sight. So I suggest the following example. Note: I had no word for this type of technology so I just coined \"Visual Reading Assistants\". Examples of visual reading assistant products are: specialized style sheets, IBM\'s WebAdapt2Me and Home Page Reader and WYNN from Freedom Scientific. I talked to Phill Jenkins from IBM and he suggested \"Reading Assistive Technology\". That\'s good but might seem circular in the definition of assistive technology. There is a significant needs difference between readers with sight who have print disabilities and readers without sight. While screen readers work for both, sighted readers are never trained in Braille so visually accessible text represents the only static medium available for sighted readers with print disabilities. A static reading medium is necessary for serious literature that requires deep concentration. A non-aural medium is also necessary for deaf readers with print disabilities. Zoom technology does not comes close to addressing this need, so I don\'t want developers coming away with the impression that screen magnifiers solve the problem for this population.
Proposed Change:
Change to definition -- Assistive Technology... Example...
Visual Reading Assistants - Several products modify the document styles such as font size and color, spacing of lines, letters and words, and the font family. These products may also synchronize speech with text, reflow large text to fit the page and add keyboard navigations. They are used by print disabled readers who are sighted but who cannot read standard print formats owing to a variety of visual, perceptual or motor limitations.
We have revised the bullet on screen magnifiers in the definition of assistive technology to:
"screen magnifiers and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order to improve the visual readability of rendered text and images;"
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
I think there are problems with the idea that someone can claim level 3 conformance if they do only 50% of the techniques that apply to their content. That means someone could claim Level 3 conformance and have an audio track that has a loud background when there is a Level 3 SC that specifically says don't do this. I realize that some Level three items are very difficult. But that is what level 3 is all about - going above and beyond. (If some of our Level 3 SC are unrealistically difficult then let's remove those ones) On the other hand, if we are just providing level 3 as a way to encourage people to provide extra accessibility then it should not be a Level but rather a separate advisory section of our guidelines. I don't think we can allow people to say they have reached a level of conformance while blatantly while breaking the GL or SC in that level. I think it undermines the integrity of our Guidelines. I think it will be a source of much confusion and conflict in the public and among disability groups.
Proposed Change:
Require 100% of Level 3 SC that apply to the content to be met in order to meet Level 3. If there are some SC that the group identifies as unrealistically difficult then remove them to a separate document called something like "going the extra mile."
We have changed the definition of Level AAA conformance so that all Level AAA Success Criteria that apply to the content types used must be satisfied.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
Some widgets - such as a tree, the tab order will and should change when a component is expanded. It make no sense to say that that is not OK unless it is not predicable. As AT becomes used to these widgets, instruction will not be required
Proposed Change:
Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order or behavior for a progamaticly determinable widget type.), unless the authored unit contains instructions before the control that describe the behavior.
We agree that what you cite should be allowed; it is already allowed under the current wording. Expanding the tree is a change of content, but not a change of context. The definition of "change of context" includes the note: "A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context."
Note that the clause "(beyond moving to the next field in tab order)" has been removed as unnecessary.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
I am concerned that level 1 SC will act against automatic help and combined with information hiding. For example when information is hidden unless you focus on the element in question, and then all the sub information about it is given.
If you do not hide the information then the page becomes busy and you can not see what the main points are. If the user has a two strep process to access the information, then they may never receive it.
As with many SC, they are OK if you read the definition, but if you just read the text it is misleading.
Proposed Change:
change the term "change of context" to "confusing change in context"
the definition can remain the same
The term "confusing" is subjective and would not be testable.
Because keyboard users must often move focus through other controls to navigate to the control of interest, it is particularly important that just setting focus to a control does not have side effects. Although changes of content such as your example are not changes of context, and hence would not violate this success criterion.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
I am concerned that the requirement for real time synrcrization put a lot of extra work on authors who would like to provide short animations or clips that help people with learning disabilities fulfill a task. On the whole, a lot of multi media, especially in education, is good for many learning disabilities, and these requirements may act as a step backwards for learning disabilities.
Proposed Change:
Make an exception in 1.2 for any content provides extra help visual for tasks and information that has been described in text else wear.
We have added an exception to SC 1.2.1 so that captions are not needed when the multimedia is presenting information that is already available as text:
1.2.1 Captions: Captions are provided for prerecorded multimedia except for multimedia alternatives to text that are clearly labeled as such.
We have also updated the intent section for this criterion to reflect this change.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
To my mind the most important aspect if predictability is exposing to the user agent what each thing is. That way the interface can be tailored to the user's access strategy. If XHTML 2 roles are known - what is main and what is secondary navigation, then the order becomes less important.
Proposed Change:
add success criteria
This requirement is covered in SC 4.1.2 "For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies" and in SC 1.3.1 "Information and relationships conveyed through presentation can be determined programmatically, and notification of changes to these is available to user agents, including assistive technologies."
While additional roles will assist with navigation, the working group does not feel the need to add an explicit navigation-related success criterion requiring these roles, since they are already covered by SC 1.3.1. The current success criteria do not preclude the use of navigational roles to improve the accessibility, and some of the techniques for these success criteria depend upon the availability of reliable role information.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
Terms in the document often seem to mean something a bit different, until you read the definitions. As WCAG is often quoted the terms themselves should be as close to clear language as the can be without viewing the definitions.
Proposed Change:
change the term "programticly determined", to "supported by Assistive technology".
We have struggled to make the concept of "programmatically determined" and other terms used in the document as clear as possible. Unfortunately, "supported by assistive technology" captures only part of the meaning of programmatically determined. The author must also have provided the data in a form that makes information and relationships clear by using appropriate markup within the technology.
Note that the definition of programmatically determined has been amended to say "including assistive technology."
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
You have not provided long enough for public review of these guidelines. You\'ve had over 5 years to get them together. Can\'t you give us more than a month?
Proposed Change:
Give us more time to review the guidelines please.
We agreed. Three weeks of additional time was provided.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
Adaptive interfaces are a good thing. sometimes change is because we know more about what the user likes
Proposed Change:
change the wording
...occur in the same relative order each time they are repeated, unless a change is initiated by the user or may benifit the user
This success criterion applies to the logical order and default presentation of the content. This success criterion does not prohibit choices in adaptive interfaces; enabling adaptive interfaces and alternate presentations is a goal of WCAG2. However, the user still needs to initiate the change in order, even if the change is initiated by global actions such as selecting preferences in a user agent or using a user agent with adaptive behavior. We have added this explanation to the Intent Section of the How To Meet document.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
To get to CR (candidate recommendation we believe two things are required.
1, Concrete checkpoints or list of requirements
2, Tests that completion of the minimum requirements of success criteria at each level will make sites progressively usable for people with disabilities listed in the overview.
Proposed Change:
Create a list of "what to do" checkpoint
We have released the Quick Reference document (http://www.w3.org/WAI/WCAG20/quickref/) which provides a compact list of the success criteria (the checklist items for WCAG 2.0) with the techniques that are sufficient listed directly beneath them. Each technique has a test that can be used to confirm implementation.
If you mean that we need a checklist for getting to CR, there is a list of things that must be met in W3C Process Document.
With regard to your second point, this type of testing is beyond what can be done in CR. This would be an interesting research project but would require considerable funding.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
Level 3 success criteria:
1. Achieve additional accessibility enhancements.
2. Can not necessarily be applied to all Web content.
I object to definition. Because many criteria are level 3 only because they are considered too hard to do on all web content does not mean that level 1 and two achieve minimal and enhanced accessibility.
Level 3 is also minimal accessibility
Proposed Change:
change of wording
Level 3 success criteria:
1. Achieve minimal accessibility, or, if the Success criteria can be applied to all Web content, achieves additional accessibility enhancements.
2. Can not necessarily be applied to all Web content.
We have completely rewritten this section of the guidelines (see http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ):
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.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
The claim in http://www.w3.org/TR/WCAG20/Overview.html learning difficulties, cognitive limitations,
However the checkpoints towards understandability even at level 3 addresses only secondary education level – in other word usable for mainstream people without these disabilities. The basic mechanism for simplifications have not been included, or use of symbols or conversion to symbols. Also left out are use for controlled languages
The result: I read a lot of complex specification. I am even writing W3C specifications, but WXAG is the only on that I can not follow though because of my disability. I can understand the concepts, but the presentation requires remembering what technique 3.1.3 was for, and then (if I forgot what 3.2.3 stood for, going back to the original guidelines finding it, hopefully not confusing it with 1..3.2 etc – why because WCAG are following there own specifications, so I, as a person with a disability, can not use their material.
to say “this document contains principles, guidelines, and success criteria that define and explain the requirements for making Web-based information and applications accessible� and to include learning difficulties, cognitive limitations is an insult to anyone with learning memory or cognitive impairments. there are many clear sets of guidelines that do that. WCAG is not one of them.
Proposed Change:
Practical proposal – state clearly that learning difficulties, cognitive limitations are not fully addressed beyond a very limited way. Then work on a extended guideline, be it optional and untestable, success criteria that does the job.
We have added language to the Introduction, the Conformance section, and the Quick Reference to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and to call 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, and we have proposed 3 new success criteria in this area.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
1. Identifying changes in natural languages USING a technology-specific technique listed below AND Identifying text direction of passages and phrases USING a technology-specific technique listed below (for a technology in your baseline)
The example is an odd one because always, when changing direction, you are changing characters and there for it is, by definition programticly determined
More over bILI languages change direction all the times whenever numbers are used. Are you really expecting each number to be in it’s own span? Why not follow the standard BILI algorithms
Based on comments from the Internationalization Working Group, we have determined that text direction is not an accessibility issue unless it affects the meaningful sequence of text. SC 3.1.2 no longer requires that the direction of text be identified.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html
Comment (including rationale for any proposed change):
from the appendix...
"If style sheets are in your baseline, WCAG 1.0 checkpoint 6.1 (that the word order of text needs to make sense without css) is not required;"
I do not understand this example, In fact it seems to highlight the problem of baseline - that an accessibility problem will persist even if a technology is supported by Assistive technology. For example An Assistive technology may be able to work with Aural CSS (if it was not depreciated) display visible, phuedo class etc, and still not be able to work out what the reading order is just based of pixel positioning of test in columns (without more information).
surely text out of order will not be understandable by assistive technologies even when CSS is supported?
7, Overall people are struggling understanding the baseline concept. One person, hugely talented and experienced in accessibility thought that if all pages used CSS then 6.1 does not matter any more
Proposed Change:
How can we define baseline so that 6.1 is supported in this baseline?
The working group agrees that the problem you cite should not be allowed. However, that problem is already not allowed with the current guidelines. Even if style sheets are in the baseline, the content must satisfy SC 1.3.3. The Failure "Failure of SC 1.3.3 due to changing the meaning of content by positioning information with CSS." would explicitly prohibit this sort of use of CSS.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html
Comment (including rationale for any proposed change):
Provide mechanisms to help users find content, orient themselves within it, and navigate through it
Success criteria does not include what is require to make AJAX regions accessible
Proposed Change:
require blocks are identifiable
The success criterion has been updated to require that roles, states, properties, and values be programmatically determined. It now reads: "For all user interface components, the name and role can be programmatically determined, states, properties, and values that can be set by the user can be programmatically determined and programmatically set, and notification of changes to these items is available to user agents, including assistive technologies."
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html
Comment (including rationale for any proposed change):
mechanism is available for ....
A mechanism is only useful if: it is usable by AT or b, it is usable by the user
Proposed Change:
change definition of mechanism to process or technique for achieving a result that is easy (does not require a change of context, and uses simple language) for the user to use can be programmatically determined for AT for people with learning disabilities
To clarify that the user must be able to access the mechanism, we have added the following note to the definition:
Note: the mechanism must meet all success criteria for the conformance level claimed
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html
Comment (including rationale for any proposed change):
This document contains principles, guidelines, and success criteria that define and explain the requirements for making Web-based information and applications accessible. "Accessible" means usable to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations...
I am not sure that if pages are fixed to comply to WCAG they will be more accessible to LD
Proposed Change:
Change to exclude Learning disabilities.
We have added language to the Introduction, the Conformance section, and the Quick Reference to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and to call 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, and we have proposed 3 new success criteria in this area.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html
Comment (including rationale for any proposed change):
Quote: Because not all level 3 success criteria can be used with all types of content, Triple-A conformance only requires conformance to a portion of level 3 success criteria
This means that no one will bother with level three because you can claim Triple-A conformance by just doing one level 3 SC
Proposed Change:
Remove this paragraph
We have changed the definition of Level AAA conformance so that all Level AAA Success Criteria that apply to the content types used must be satisfied.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html
Comment (including rationale for proposed change):
The primary natural language is identified.
Why is this level 1? I have not seen an assistive technology and user not work at all because the language attribute is missing. this seems to be level 3
Proposed Change:
move to level 3
There were comments to combine 3.1.1 and 3.1.2, to move them up and to move them down. After much discussion, the consensus of the working group was to leave them in the current positions.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html
Comment (including rationale for proposed change):
changes in natural language is identified:
Is WCAG awere that this is huge amount of work? for lots of content this would be more work then the rest of WCAG put together (all the has English in for web site names and odd words..). On the other hand it seems typically understandable by the user as is, and not so important for the user..
Proposed Change:
move SC 3.2 to level 3
There were comments to combine 3.1.1 and 3.1.2, to move them up and to move them down. After much discussion, the consensus of the working group was to leave them in the current positions.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for proposed change):
Interfaces become inoperable when one of the following brake:
1. Each element or widget is marked with full and corrected semantics that fully describes it's behavior Note this is more then information and structure can be separated from presentation .This includes creating enabled javascripted widgets that the Assistive Technology does not know what it is, what states are supported and how it maps to the operating system API. If non exists (like a tree item that can expand to a sub tree when you click on it) Then you may need to add a technology, such as xforms, XHTML 2 Roles
2. The relationships between elements and groups are known. Again, this is more then I see supported by navigation Success criteria. What form element controls what AJAX operated section is a good example of a relationship
3. States, properties, and relationships are valid for each elements behavior and are accessible via the DOM. For example if clicking on a tree item makes it expand or collapses, then it's state (such as expanded) needs to be accessible via the Document Object module Via an attribute that can be understood by assistive technology..
4. There is an element having the correct input focus. This is different to just being keyboard navigatable
Proposed Change:
Add success criteria at level 1 along the lines of:
1, The supported behavior of each element and widget can be programaticaly determined.
2, The relationships between elements and groups of elements can be programaticaly determined.
3, States, properties, and relationships are valid for each elements behavior can be programaticaly determined.
4, There is consistently an element having the correct input focus.
The working group believes that your concerns for additional level A success criteria have already been met with existing criteria. Success criterion 4.1.2 covers the supported behavior of each element and the states, properties and relationships of elements and requires that they be programmatically determinable. The relationships between elements are covered by success criterion 1.3.1. Both of these are level A success criterion. For example, the pressed state of buttons is not currently exposed by user agents to assistive technology. In addition, the lack of states and relationships does not block accessibility today and the current success criteria do not block future technology which provides additional role, state, and relationship information.
We also do not believe that there should be a requirement for always maintaining an element with input focus. For the bulk of content the current focus mechanism is sufficient and allows page scrolling with arrows and change of focus into the user agent address bar with no interaction from the Web content author.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for proposed change):
Web units have titles, what is the advantage if the titles are not descriptive?
Proposed Change:
change to Web units have descriptive titles
We have changed SC 2.4.3 to "Web pages have descriptive titles" and have also reflected this change in success criterion 2.4.5 and the support documents for both success criteria.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for proposed change):
surely this only helps if titles are unique -any objection to unique should not apply at level 3
Proposed Change:
change to Web units have descriptive and unique titles
We have changed SC 2.4.3 to "Web pages have descriptive titles" and have also reflected this change in success criterion 2.4.5 and the support documents for both success criteria.
The success criterion does not require that titles be unique because the working group is concerned that requiring uniqueness will lead to titles that are not as descriptive and usable. It may be very difficult to create titles that are descriptive, unique, and reasonably short. For example, a Web page that generates titles dynamically based on its content might need to include part of the dynamic content in the title to ensure that it was unique. We are also concerned that authors may make titles unique mechanically, such as by including a unique number in the title that is unrelated to the content. For these reasons, although we encourage unique titles in the techniques for this success criterion, we are not including uniqueness in the success criterion itself.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for any proposed change):
sections of content need titles to be able to navigate through a page.
This is particularly true of many AJAX sites that have multiple regions. The regions of a page can change at different rates due to either user actions or asyncrones updates. The user may need to toggle between form controls to results, and updates.
Even in simpler content knowing that a table has a navigation function is hugely usefully even when accessibility is not completely broken.
Proposed Change:
Add level one success criteria
Blocks of content that become updated should be uniquely titled or it's role can be programaticaly determined
When multiple blocks of content in a web unit have the same role they should be uniquely titles
Blocks of content that perform a common task should be titles or its role can be programaticaly determined
success criteria 2.4.1 is no longer needed
The WCAG WG did not create a success criterion specific to live regions. However SC 4.1.2 was modified to require the general case that roles, states, properties, and values be programmatically determined.
In addition, the ability to navigate easily to such regions is an important point and related to other needs as well. Therefore, we created a new Level AAA success criterion in GL 2.4 "2.4.9 Section Headings: Where content is organized into sections, the sections are indicated with headings."
Various ways of conforming to this success criterion would exist, including the suggestion to provide headers for live regions as well as any other meaningful section of content. The technique on 'live regions' is advisory at this time because the technology has not been released yet.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for any proposed change):
2.4.6 When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. [How to meet 2.4.6]
this should be level 1 as it often completely brakes the user interface
Proposed Change:
move SC 2.4.6 to level 1
Because assistive technology cannot provide access to rerendered content if this success criterion is not satisfied, it has been moved to level A.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for any proposed change):
In the roles specification we now have a range widget, which means you can state, in a programaticaly determined way what the max and min values are.
That means that AT can give users the message any way they want - including text, if they want. Surly this is better then requiring text
we also have in the adaptable states and properties module a required attribute, (for situation B in the "how to understand this checkpoint)
Note this is all part of the WAI, and screen readers are working to support it today...
Proposed Change:
change 2.5.1 to: If an input error is detected, the nature of the error can be programaticaly determined or identified and described to the user in text.
This success criterion does not prevent the use of programmatic information which can be used by AT or the user agent to identify and provide error information. There must be some mechanism to provide the error information to the user with all technologies in use today and the requirement for text guarantees that. Even when provided by the AT or user agent rather than the content author, the information can still be conveyed in some form of text to meet this requirement. Thus, we don't see the requirement for text as being too restrictive.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for any proposed change):
2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user.
With things like role attribute you can assign a functional role to an element, and other important information such as allowable range. That means that the assistive technology can themselves perform validation.
Makes it all a user agent thing...
Proposed Change:
2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user or can be progmaticly determined
The current success criterion does not prevent use of Dynamic Web Content Accessibility, XForms or other technologies to provide information that will allow user agents and assistive technologies to provide suggestions for error correction. We do not feel we need to specifically add "programmatically determined" to the success criterion, but such technology-specific techniques could be added as sufficient as user-agent support for them improves. If role and validation information is programmatically provided in the markup for a technology and testing demonstrates that suggestions for error correction are provided to the user via the user agent or assistive technology, this success criterion has been satisfied. The technology-specific techniques should be provided for such technologies. We have provided some advisory techniques for the use of WAI-ARIA and will promote them and will promote them as they qualify as accessibility supported in some environments.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for any proposed change):
With things like role attribute you can assign a functional role to an element, and other important information such as allowable range. That means that the assistive technology can themselves perform validation. We should also work on identifying critical tasks.
Hence one of the list should be (for future proofing) the role of all information and it's critical nature can be progmaticly determined
Proposed Change:
1. Actions are reversible.
2. Actions are checked for input errors before going on to the next step in the process.
3. The user is able to review and confirm or correct information before submitting it.
4. The role of each control and it's critical nature can be progmaticly determined.
This success criterion is addressing the problem of users making irreversible mistakes in the otherwise valid values provided or actions taken. Indicating that a control is critical is not sufficient to satisfy this success criterion. The user must still be given the opportunity to avoid unrecoverable errors.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for any proposed change):
With things like role attribute and concept mapping with RDF you can assign a functional role to an element, That means that the assistive technology can themselves provide the correct help that is tailored to the user. the user experience is better because the help is tailored to their scenario
Proposed Change:
2.5.4 Context-sensitive help is available for text input or the role of each control can be progmaticly determined
The current success criterion does not prevent use of Accessible Rich Internet Application Specifications or other technologies to add information that will allow user agents or assistive technologies to provide context-sensitive help. We do not feel we need to specifically add "programmatically determined" to the success criterion in order to support this additional data, but we have added a placeholder for such technology-specific techniques. If additional information is programmatically provided in the markup and testing demonstrates that context sensitive help is provided to the user via the user agent or assistive technology, this success criterion has been satisfied. The technology-specific techniques should be provided for such technologies. We have provided some advisory techniques for the use of WAI-ARIA and will promote them as they qualify as accessibility supported in some environments.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html
Comment (including rationale for any proposed change):
Most of this (at least at the higher levels) helps blind folks access error information. That is good. Clearly what is missing hear is a game plan for helping people with a learning disability , who have trouble filling in forms.
Forms are real nightmears for a lot of us. In fact I often do not deposit checks and perform other tasks because of the barrier that form filling presents.
Things that make it harder include short labels that do not explain what they are, coping numbers, Non expandable, small fonts. Too much information on one page. Information not being well grouped such as user information, payment information. Then with the short labels I get confused what is what. Server time outs. Asking a lot of information to make forms simpler to process but make form filling much harder and more complex.
For example on this form on line it is much simpler (but PF preferred this table .. oh well) .... the options could be in a combo box as filled out meaningfully text...
Proposed Change:
Perform user testing with different groups of people with learning disabilities and cognitive limitations - including age related.
Identify what technques help
Add them
We have added language to the Introduction, the Conformance section, and the Quick Reference to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and to call 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, and we have proposed 3 new success criteria in this area.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for any proposed change):
With new technology such as roles within the WAI, you can assign the role of the object in a programmatically understandable way. So if assistive technology knows the role of a picture is as a bullet, or to say that a star means it is required, or that spacer.gif is for spacing - why do you have to also fill in the alt tag?
Proposed Change:
Add to the list of options: The role and behavior of non-text content can be programmatically determined
While defining roles is an important new enabler of accessibility, it should not be used as a replacement for the predefined semantics in HTML. Images should always have alternative text, and semantic elements used whenever possible. Roles should be used to supplement semantics when those semantics are inadequately provided by the host language.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for proposed change):
With new technology such as roles within the WAI, you can assign the role of the object in a programmatically understandable way. Also you can use RDF, xfroms etc to similar affect.
Proposed Change:
1.3.2 Any information that is conveyed by color can be programmatically determined or is also visually evident without color
Information conveyed through variations in the presentation must be programmatically determinable in order to conform to SC 1.3.1. Since color is a variation in presentation, any information conveyed by variations in color must be programmatically determinable. Thus a change to SC 1.3.2 is not needed.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for any proposed change):
the information for the user is important not the change in presentation...
Proposed Change:
Information that is conveyed by variations in presentation of text is also conveyed in text, or the informations can be programmatically determined.
SC 1.3.1 and 1.3.4 have been combined to read "Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies." This wording ensures that it is the meaning conveyed by the presentation that must be programmatically determined, and allows the author to indicate the meaning in text if it is not feasible to do so programmatically. The How to Meet document describes this in some detail.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for proposed change):
two questions we need to know for interface components
1, who am I ? This is a question of element integrity
a ball bouncing across the screen is the same ball and not changes of color of pixels across a screen
2, what am I? what is my function (role)
But what I am not sure is mentioned is make sure each element exists in the first place - and is not color across a screen. or letters in no logical order but that are absolutely positioned. A ball is a ball, a word is a word. Things need to know who they are and to what they belong.
Proposed Change:
Add at level one
All objects and components that can be visual perceived can be programmatically identified thought its life cycle.
We have revised SC 1.3.1 ("Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies.") and SC 4.1.2 ("For all user interface components, the name and role can be programmatically determined, states, properties, and values that can be set by the user can be programmatically determined and programmatically set, and notification of changes to these items is available to user agents, including assistive technologies.") so that this is now required.
If objects and components can be visually perceived, SC 1.3.1 requires that they be programmatically determined or described by text. Changes to the object also need to be notified.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for proposed change):
Maybe the user needs to know what the baseline is. Then if they really need this content they can find a user agent that can supply it.
Proposed Change:
Add at level one
The user can access what technologies are included in the baseline, even without using baseline technologies
We are no longer using the term baseline to describe this concept. In order to access a description of the technologies relied upon by a given site, the user would need to access some Web content, which in turn would need to rely on a Web technology of some sort. We cannot see a way out of this dilemma.
We have added the following optional component of a conformance claim to make it easier to determine what technologies are relied upon:
The list of specific technologies that are relied upon, in machine-readable metadata.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for proposed change):
1.3.1 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies...and
Missing hear is you need to encapsulation of the functions and behavours of each element is essential
Proposed Change:
Add at level one
The functions and behavours of each element that can be visual Perceived can be programmatically identified thought its life cycle.
This is addressed by Success Criterion 4.1.2, which requires that relevant properties can be programatically determined and that updates be available to AT, which ensures it will be current throughout the life cycle.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for proposed change):
this needs to be at level one because many sites are completely inoperable because of failure
Proposed Change:
move to level 1
Because assistive technology may not be able to preserve shape, size, visual location, or orientation of components when it transforms content to an alternate presentation, this success criterion has been moved to level A.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for proposed change):
With RDF, XHTML roles etc, time outs can now be programmatically determined
Proposed Change:
add to the bulleted list in 2.2.1 Success criteria
The role of time outs and updated regions can be programmatically determined
The working group recognizes that with the addition of an appropriate role and states, an assistive technology could recognize time-outs within the content. With that knowledge, the assistive technology could take the appropriate action to allow the user to modify the time-out. While this could be true for assistive technologies, there is no checkpoint in the User Agent Accessibility guidelines that requires a user agent to recognize and modify time-outs. Thus, even if the time-out could be programmatically determined, there is no requirement for user agents to respect this information. Thus, someone using a "standard" user agent and not an assistive technology could encounter a time-out which could not be modified. For this reason, the working group has decided not to add your suggested bullet, "The role of time outs and updated regions can be programmatically determined" to the success criterion 2.2.1. If testing revealed that adding the role information was supported by an appropriate assistive technology to modify time-outs, success criterion 2.2.1 would be satisfied. When an assistive technology exists that supports this level of programmatic information we will add an additional sufficient technique.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for proposed change):
With RDF, XHTML roles etc, time outs can now be programmatically determined
Proposed Change:
does the wording cover this, if not add to the wording of 2.2.3 and 2.2.2 Success criteria
...Unless the role of time outs and updated regions can be programmatically determined
The working group recognizes that with the addition of an appropriate role and states, an assistive technology could recognize that particular content was time dependent. With that knowledge, the assistive technology could take the appropriate action to allow the user to pause the content or change the frequency of the update or movement. While this could be true for assistive technologies, there is no checkpoint in the User Agent Accessibility guidelines that requires a user agent to recognize and pause content. Thus, even if the time dependent content could be programmatically determined, there is no requirement for user agents to respect this information. Thus, someone using a "standard" user agent and not an assistive technology could encounter content which could not be paused. For this reason, the working group has decided not to add your suggested clause, "Unless the role of time outs and updated regions can be programmatically determined" to the success criteria 2.2.2 and 2.2.3. If testing revealed that adding the role information was supported by an appropriate assistive technology to pause content, success criteria 2.2.2 and 2.2.3 would be satisfied. When an assistive technology exists that supports this level of programmatic information we will add an additional sufficient technique.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html
Comment (including rationale for proposed change):
quote " At Levels 1 and 2, WCAG conformance is only required for technologies inside the baseline. Technologies outside the baseline need not conform," ah.. and then it is clarified
I do no think that is what you mean but people will misquote that to think that if they set a baseline of html, then there site is conforment because everything is in flash which is outside baseline.
Proposed Change:
change 4.2 wording
Content implemented using technologies outside of the chosen baseline satisfies all Level 1 and Level 2 requirements supported by the technologies even when accessible alternatives using technologies inside the baseline are provided.
We have switched from using "baseline" to using "accessibility supported Web technology".
In order to conform to WCAG, any content in a non-accessibility-supported Web technology must also be available in an accessibility-supported Web technology. This is explained in the Conformance section "Conformance requirements", conformance requirement 5.
We are worried that explicitly saying "even when accessible alternatives inside the baseline are provided" may lead readers to think that there are some situations where there won't already be accessible alternatives. We think this is explained more clearly in the How To Meet document for this success criterion.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
To set the scene, I am your average garden-variety web developer. I am a simple soul, with college education, good English skills and above all, good HTML skills. I spend all day, every day, producing sites - for everything from the local dentist to the multi-million pound nation-wide high street chains.
WCAG 2 has disappointed me.
For a start, I just don\'t understand it. I am not stupid, but I just don\'t understand how it applies to what I build. How can I bear all that in mind when going through the stages of planning/building/testing a site?
It\'s going to take months to combine that into my daily routine and to be honest I cannot see the commercial benefit. Most of the sites I build, I make them WCAG 1 level 2 accessible out of good practice and for good karma. I like it; I enjoy the sense of responsibility I get from it. It sets me apart from the monkeys knocking sites out in the back bedroom.
WCAG 2 is so difficult, why would I bother? My customers do not care! If they do, then they will have to pay me a lot to have a compliant site, as the extra amount of time involved does not come for free.
If WCAG 2 was actually simple - a simple to understand a plain-English check list (i.e. - do you use PDF, see page 3, if not continue to page 4 > checklist) along with highly automated checking system, then we are going to see a lot more developers producing compliant sites. Just dream…an internet with more and more compliant web sites. Is that not what we all want?
Proposed Change:
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page� instead of “Web Unit�)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I disagree strongly with the concept of having a baseline. By NOT specifying a minimum technology set of HTML, then site owners are essentially given free range over choosing to only support the technology that they want, regardless of whether any accessible user agent for rendering that technology is in existence. This goes against the grain of the W3C\'s underlying philosophy of making Web content available to anyone. If the W3C want WCAG to be future-proofed, it should encompass existing technologies, and evolve with version 3.0 when new technologies become in use, not pre-empt them through by being ambiguous.
Proposed Change:
That WCAG 2.0 specify HTML as a minimum technology for making information accessible. That existing technologies be incorporated into WCAG using specific guidelines for current user agents.
The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section "Accessibility Support of Web Technologies" at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .
WCAG 2.0 is technology neutral, so it would be inappropriate to require any specific technology, such as HTML. (We would, nevertheless, be surprised to find environments that did not consider HTML to be accessibility supported).
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
The exclusion of validity is a huge step backwards for web accessibility. A valid document ensures consistent rendering, regardless of user agent.
Proposed Change:
That validity be added as a requirement for conformance to success criteria.
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.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
Thoroughly disappointed and disillusioned with WCAG 2.
I had hoped all the \'problems\' would be ironed out by this stage, but it seems that they have just become more ingrained.
To be fair, I can see where you\'re heading - that being specific about things like current technologies runs the risk of being outdated in the near future. I can see why you are using abstracted terms like \'Baseline\' and not further emphasising Validation, but in practice it is not going to work.
Why?
One of the biggest problems I had with WCAG 1 was the non-measurable stuff. You