- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 22:06:16 -0700
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: public-comments-WCAG20@w3.org
Comment 39: "all" of the following requirements CAN'T be met, as depends on chosen level Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0367.html (Issue ID: 2220) ---------------------------- Original Comment: ---------------------------- The first para states "In order to conform to WCAG 2.0 all of the following conformance requirements must be met..." Then, the first 3 requirements are mutually exclusive, or rather they\'re a single requirement which changes depending on which level the author wants to claim conformance to. Proposed Change: Aggregate the first 3 requirements into a single requirement with sub-points: 1) All SCs for the chosen conformance level are fulfilled: - Level A Conformance: ... - Level AA Conformance: ... - Level AAA Conformance: ... This then requires a renumbering of the following points: 2) Alternative Versions: ... 3) Accessibility-Supported Technologies Only: ... --------------------------------------------- Response from Working Group: --------------------------------------------- We have changed the conformance requirements as you suggested. ---------------------------------------------------------- Comment 40: Addition to "Accessibility-Supported Technologies" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0369.html (Issue ID: 2221) ---------------------------- Original Comment: ---------------------------- The final para in "Accessibility-Supported Technologies" can possibly be expanded to mention "alternative versions" again, thus also reinforcing the previous point. "...must also be available via technologies that are accessibility supported." Proposed Change: "...must also be available via alternate versions using technologies that are accessibility supported." A thought, though: would this new wording cover things like fallback mechanisms of OBJECT element in HTML? Does that count as an alternate version? --------------------------------------------- Response from Working Group: --------------------------------------------- The words "Alternate Versions" in our document means alternate versions of entire web pages. The sentence you cite is meant to include making the information available on the same page as well as other pages (including the method you suggested with "object"). We did not include the "alternate versions" language since it would be too narrow, and adding all the different ways would make the sentence too long and hard to parse. But you have the right general idea. Technique H53 is about using the body of the object element but the technique is not supported well by assistive technologies and cross-browser support is irregular. ---------------------------------------------------------- Comment 41: "Non-Interference" "No Keyboard Trap" dependend on UA/plugin as well Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0370.html (Issue ID: 2222) ---------------------------- Original Comment: ---------------------------- "No Keyboard Trap" is not simply down to authors. It's dependent on the user agent and the plugin itself (consider keyboard issues in current and recent browsers + flash, where keyboard focus either gets lost, or it's not possible to jump into the flash movie in the first place via keyboard alone). Proposed Change: possibly add a note that this is dependent on UAAG compliance of UA and plugin technology itself. --------------------------------------------- Response from Working Group: --------------------------------------------- We have moved the keyboard trapping requirement to a new success criterion: "2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys, the user is advised of the method for moving focus away." The problem of trapping may or may not involve the user agent. But if the keyboard will be trapped by a technology that the author is using to create content, then it is up to the author to either tell the user how to get out before they encounter the keyboard-trapping content or to provide a natural means for them to get out. ---------------------------------------------------------- Comment 42: "machine-readable metadata" preferred...but do UAs support it? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0371.html (Issue ID: 2223) ---------------------------- Original Comment: ---------------------------- "Optional components of a conformance claim\", first numbered bullet: "This information should be provided in a form that consumers can use, preferably machine-readable metadata." This seems to imply that users CAN actually make use (with current user agents) of this metadata. In practice, how many end-users have a UA that can read, say, EARL or DC accessibility data? Proposed Change: Drop the "preferably machine-readable metadata" altogether. --------------------------------------------- Response from Working Group: --------------------------------------------- This is kind of a chicken-and-egg situation. Although current technologies cannot take advantage of this, AT could be designed to if pages were so marked. Providing this information in any other form would be so much less useful that, if one is going to do this, we believe they should do it in machine readable (metadata) format. ---------------------------------------------------------- Comment 43: "Optional components..." typo and awkward sentence Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0372.html (Issue ID: 2224) ---------------------------- Original Comment: ---------------------------- \"3. ... , that the content with which the content has been tested.\" typo. Proposed Change: "3. ... , with which the content has been tested." if you're not bound by arcane "no split infinitive" rules and actually use language that is used every day anyway: "3. ... , that the content has been tested with." Even easier, to avoid the debacle, turning the sentence around: "3. A list of user agents, ... , that were used to test the content." --------------------------------------------- Response from Working Group: --------------------------------------------- Thank you. We have updated this item to read, "A list of user agents, including assistive technologies, that were used to test the content." ---------------------------------------------------------- Comment 44: "Optional components..." meta-data reference, pt 2 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0373.html (Issue ID: 2225) ---------------------------- Original Comment: ---------------------------- "5. ... , in machine-readable metadata." As with my comment on point 1 of the same list, this assumes that programs that can consume this metadata are readily available. As this, to my knowledge, is not the case, I'd suggest dropping the reference to metadata altogether. Proposed Change: drop the reference to metadata altogether. --------------------------------------------- Response from Working Group: --------------------------------------------- See Response to Issue 2223. ---------------------------------------------------------- Comment 45: "Contrast ratio" definition and user-selected colours Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0397.html (Issue ID: 2263) ---------------------------- Original Comment: ---------------------------- "Note 4: ... white is assumed." May be worth mentioning that users could have set their own bg colour as well. Proposed Change: "Note 4: ... white is assumed. However, it's worth noting that users may have set their own preferred background color, which may differ considerably from the luminance value of white." or similar --------------------------------------------- Response from Working Group: --------------------------------------------- Respond with: We have changed the note to state that foreground and background colors must be specified together to avoid arbitrary contrast. This is supported by F24: Failure of SC 1.4.3 and 1.4.5 due to specifying foreground colors without specifying background colors or vice versa. "Background color is the specified color of content over which the text is to be rendered in normal usage. It is an error if no background color is specified when a foreground color is specified, because the user's default background color is unknown and cannot be evaluated for sufficient contrast. For the same reason, it is an error if no foreground color is specified when a background color is specified." If the user has explicitly set their own background color, then they should also set the foreground color because in common web technologies in use today, the content has no way to respond to this in a way to preserve contrast ratio. ---------------------------------------------------------- Comment 46: "tactilely" in "human language" definition Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0398.html (Issue ID: 2264) Status: VERIFIED ACCEPTED ---------------------------- Original Comment: ---------------------------- "...(visually or tactilely)..." although grammatically correct, it's far from common usage. Proposed Change: change "tactilely" to "by touch" "...(visually or by touch)..." --------------------------------------------- Response from Working Group: --------------------------------------------- Response: We have changed the wording of "visually or tactilely" to "through visual or tactile means" ---------------------------------------------------------- Comment 47: "idioms" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0399.html (Issue ID: 2265) ---------------------------- Original Comment: ---------------------------- may be worth either expanding the first para, or adding an additional note, to mention that idioms can't be translated word for word / verbatim. Proposed Change: "note: idioms cannot be translated directly, word for word, without losing their (culture or language dependant) meaning." --------------------------------------------- Response from Working Group: --------------------------------------------- We have added the note that you suggested. ---------------------------------------------------------- Comment 48: "keyboard interface" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0400.html (Issue ID: 2266) ---------------------------- Original Comment: ---------------------------- there's no explicit mention of switch access or sip/puff devices. should there be? Proposed Change: add a mention of switch access + sip/puff devices. --------------------------------------------- Response from Working Group: --------------------------------------------- We have added these examples to the definition of assistive technology ---------------------------------------------------------- Comment 49: "large scale" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0401.html (Issue ID: 2267) ---------------------------- Original Comment: ---------------------------- the definition talks of "points", but these end up being relative due to user/OS settings. worth noting that they're not really absolute, as they can be overridden (knowingly or unknowingly) by the user. Proposed Change: "note 3: in the context of digital displays, actual point size, like any other 'absolute' measurement unit, depends on the user's display size/settings." --------------------------------------------- Response from Working Group: --------------------------------------------- It is true that text is not always displayed at the author-requested size, even if the author specified a point size. This can be due to an incorrect pixels per inch setting on the user's display device, or user font size preferences. The author cannot be responsible for these conditions, though should be aware of the potential. Therefore we have added a note to the definition that reads: "The actual size of the character that a user sees in dependent both on the author-defined size and the users display or user-agent settings. This success criterion is based on common pixel sizes available today. Users who have low vision would be responsible for choosing appropriate settings." ---------------------------------------------------------- Comment 50: "non-text content" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0402.html (Issue ID: 2268) ---------------------------- Original Comment: ---------------------------- maybe pedantic, but worth rewording the note to be even more explicit: "Note: This includes ASCII Art ..." Proposed Change: "Note: This also includes sequences of characters used as ASCII Art ..." side note: what about emoticons?
Received on Sunday, 4 November 2007 05:06:33 UTC