- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:18:56 -0700
- To: "Cynthia Shelly" <cyns@exchange.microsoft.com>
- Cc: public-comments-WCAG20@w3.org
Dear Cynthia Shelly, Thank you for your comments on the 17 May 2007 Public Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0 http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group has reviewed all comments received on the May draft, and will be publishing an updated Public Working Draft shortly. Before we do that, we would like to know whether we have understood your comments correctly, and also whether you are satisfied with our resolutions. Please review our resolutions for the following comments, and reply to us by 19 November 2007 at public-comments-wcag20@w3.org to say whether you are satisfied. Note that this list is publicly archived. Note also that we are not asking for new issues, nor for an updated review of the entire document at this time. Please see below for the text of comments that you submitted and our resolutions to your comments. Each comment includes a link to the archived copy of your original comment on http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may also include links to the relevant changes in the WCAG 2.0 Editor's Draft of May-October 2007 at http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/ Thank you for your time reviewing and sending comments. Though we cannot always do exactly what each commenter requests, all of the comments are valuable to the development of WCAG 2.0. Regards, Loretta Guarino Reid, WCAG WG Co-Chair Gregg Vanderheiden, WCAG WG Co-Chair Michael Cooper, WCAG WG Staff Contact On behalf of the WCAG Working Group ---------------------------------------------------------- Comment 1: The relationship between labels and names is not clear enough. Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0263.html (Issue ID: 2093) ---------------------------- Original Comment: ---------------------------- When do you need a name, when do you need a label, when do you need both? I believe that you always need a name, if you have a label it should be programatically associated (making it a label), but that labels are optional. Is that correct? Need to be more clear in the guidelines. --------------------------------------------- Response from Working Group: --------------------------------------------- You are absolutely correct. Success criterion 4.1.2 requires a programmatically determinable name for all user interface components. Occasionally the name must be visible as well in which case it becomes a label. Whenever this is required it is specifically called out in the guidelines by saying that a "label" is required. Both terms are defined in the glossary. We will add the following to the intent section of 4.1.2 as a note. "NOTE: Success Criterion 4.1.2 requires a programmatically determinable name for all user interface components. Names may be visible or invisible. Occasionally, the name must be visible, in which case it is identified as a label. Refer to the definition of name and label in the glossary for more information." If you have additional suggestions as to how we could make it clearer feel free to send them in as well. ---------------------------------------------------------- Comment 2: The parenthetical phrase is confusing ---------------------------- Original Comment: ---------------------------- The parenthetical note in the title "(for example spoken aloud, simpler layout, etc.)" is confusing. It seems to me that the subsections below 1.3 define "presented in different ways" whereas the parenthetical note (particularly with the "etc.") leaves room for misinterpretation. For example, Does different ways mean I need to allow for different reading levels? I don’t think that is the intent but the parenthetical note could allow for that. Proposed Change: Remove the parenthetical phrase. --------------------------------------------- Response from Working Group: --------------------------------------------- We have accepted your suggestion. ---------------------------------------------------------- Comment 3: Should Icons be included in contrast requirements? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0265.html (Issue ID: 2095) ---------------------------- Original Comment: ---------------------------- I know that we decided not to include diagram due to the difficulty of determining the correct contrast for varying line thicknesses and such. However, icons have a great role in determining usability of a site than general diagrams do. Proposed Change: Include icons in contrast requirements. Define "icon" and define what sufficient contrast would look like for an icon. --------------------------------------------- Response from Working Group: --------------------------------------------- The problem with ICONS is that most are mini pictures with shading etc. it would be hard to determine what is the foreground and what is the background. For simple icons this would be a good idea. We are adding an advisory technique: "Making icons simple line drawings that meet the contrast provisions for text" to 1.4.3 and 1.4.5 ---------------------------------------------------------- Comment 4: Which sc covers frame names? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0267.html (Issue ID: 2097) ---------------------------- Original Comment: ---------------------------- A collegue thought that frame names should be covered under 2.4 rather than 4.1. Many people may not think of frames as UI elements, and might not be able to find them. Proposed Change: Is there anything we can do to make it more clear that frames are covered under 4.1.2? --------------------------------------------- Response from Working Group: --------------------------------------------- H64: "Using the title attribute of the frame and iframe elements" is listed as a sufficient technique for two success criteria: 2.4.1 and 4.1.2, so the issue is covered in a number of places where the working group felt that authors might find themselves using frames. ---------------------------------------------------------- Comment 5: Not clear that it's ok to provide directions once for a site. Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0268.html (Issue ID: 2098) ---------------------------- Original Comment: ---------------------------- It's not clear from either the text or the techniques that it's sufficient to provide the explanation once for a site or application. Proposed Change: Add a technique about providing it on the first page encountered, one for providing it in help, and one for providing it as part of training for a site that will be used in a closed environment. --------------------------------------------- Response from Working Group: --------------------------------------------- We have added the following general technique and failure: G147: Providing instruction about change of context due to change of input setting ahead of such encounter F76: Failure of 3.2.2 due to providing instruction material about the change of context by change of setting in an user interface element at a location that users may bypass. ---------------------------------------------------------- Comment 6: Does HTML using pt or px meet this with today's user agents? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0272.html (Issue ID: 2102) ---------------------------- Original Comment: ---------------------------- Since you can zoom in Internet Explorer 7 and Opera, and since FireFox allows resizing of pt and px fonts, can we consider HTML resizable? If so, we need techniques for pt and px fonts to ensure that there isn't truncation or overlap when fonts resize. Proposed Change: 1) Add techniques for preventing truncation and overlap when using pt and px fonts. 2) Add user agent notes about zoom vs. font-size in IE. 3) Add techniques about not using images of text 4) Add something (not sure where, maybe in understanding, maybe techniques) about technologies that don't support resizing. One of the questions we seem to get a lot is why we need this SC if all text is resizable works in HTML. 5) Consider adding a minimum font size for text rendered in an image or other technology that doesn't support resizing. --------------------------------------------- Response from Working Group: --------------------------------------------- 1) The use of pt and px in Firefox is covered under "F69: Failure of SC 1.4.4 and 1.4.7 when resizing visually rendered text up to 200 percent causes the text, image or controls to be clipped, truncated or obscured." Authors using these units must test their content according to the procedure outlined in that failure. 2) The Zoom functionality in IE 7.0 does not always scale uniformly when absolute positioning is used and the page is scaled smaller. Microsoft Internet Explorer 7.0 supports both Zoom and Text Size changes for fonts set with %, em or named sizes. 3) We have added an advisory technique "Avoiding the use of text in raster images" 4) We have clarified the need for this success criterion in the intent section of Understanding 1.4.4 5) We have added an advisory technique for minimum font size. "Ensuring that text in raster images is at least 18pt"
Received on Sunday, 4 November 2007 04:19:13 UTC