- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:18:09 -0700
- To: "Craig Francis" <krang@krang.org.uk>
- Cc: public-comments-WCAG20@w3.org
Dear Craig Francis, 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: Style and layout suggestions for QuickRef Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0163.html (Issue ID: 1955) ---------------------------- Original Comment: ---------------------------- Just been reading the overview at: http://www.w3.org/WAI/WCAG20/quickref/20070517/Overview.php And I have been finding it a little difficult to keep track where I am in the document... which I think can be improved with a couple of little tweaks to the style sheet. I've done a quick bodge job version at: http://www.krang.org.uk/misc/wcag-2.0/ I've only tested it in FireFox 2, as its just to show some ideas I have had - please note that I am not a designer, and only have a very basic understanding of design theory. In the example, I only changed the main style sheet (qr.css) and removed the 'style' attribute from the 'submitAsCT' paragraph, as the padding was not necessary. The rest of the HTML is still technically the same, but has gone though 'HTML Tidy' to make it easier to read. Really the only issue I had with the current design is determining which parts are the headings, and content. I think this is because the yellow boxes are currently indented, which gives the impression that they are 'pull-outs'. To reinforce the 'child' properties of the main content (white background), I indented it and added a border around each part... I thought that the indenting alone left the content 'floating'. The 'advisory' box has then been indented to the same level as the main content, so that it does not give the impression that its a child of the last section (usually titled 'common failures'). Additionally I have removed some of the rules concerning the font- size... mostly because I think the current choice is a little to small for a default... instead opting to use the browsers default font size. I hope this might be of some use, and I know I should be focusing more on the content... but I get the impression that this Overview will be one of the most used documents, so I think we should try to make it easy to understand as possible. --------------------------------------------- Response from Working Group: --------------------------------------------- We have implemented a number of changes to the presentation and style of the quick reference since the 17 May draft was released including many of your suggestions. Please take a look and see if this is better. ---------------------------------------------------------- Comment 2: Trying to help readability Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0073.html (Issue ID: 1992) ---------------------------- Original Comment: ---------------------------- Document: QR Item Number: (none selected) Part of Item: Comment Type: editorial Summary of Issue: Trying to help readability Comment (Including rationale for any proposed change): I've been reading though the WCAG 2.0 quick reference, and I am finding it quite a good read, just a little heavy at times. While going though I had a few thoughts though (below), just regarding the wording and trying to make it easier to read for the average web developer (like myself). I should point out that I am not that much of a wordsmith, so don't take my views as one from an expert... just some ideas that might help. ############################# On some of the headings, you have the bracketed text "(for the technologies you checked above)" I'm not really sure this is necessary, and I think it gets too repetitive when going though the whole document. Considering the user must have consciously limited the guidelines using the form, I think this text can be safely removed. Really I'm just trying to reduce the word count, as I think a huge document can put off some readers... especially when going though the headings that contain off-topic text. ############################# The two <h6>'s at the end of the "Sufficient Techniques for 1.1.1" section, I think should be part of their own section. I think these two parts could be called: # Situations for 1.1.1 --- Situation A --- Situation B --- Situation C # Techniques for 1.1.1 --- Short text alternative techniques... --- Long text alternative techniques... These two headings still need a bit of work (more on that in a minute)... but it should help to split the content into the two distinct parts. ############################ Continuing on the previous point, if we have a boxed section for "Situations for 1.1.1", then we can loose the "Situation X:" prefixes to the child headings. This will reduce the word count, and we can possibly look at using something like an <ol>, or <ul> to list the situations... so we don't loose the 'A, B, C' counting. ############################# As to the headings mentioned in the second point, I am not keen on referring to the guidelines by number. So, for example, you could rename the headers... # Situations for 1.1.1 # Techniques for 1.1.1 ... to... # Situations for non-text content (1.1.1) # Techniques for non-text content (1.1.1) Personally, I think that the average website developer will not think about the guidelines by their numerical reference... I would suggest that a couple of words should be used to summarise each guideline (like \'non-text content\' for guideline 1.1.1). Then with the human readable text, we can suffix the heading with the numerical reference in brackets, as this will help the readers move around the document. ############################# In the "situations for non-text content (1.1.1)", I personally find find it difficult to understand the headings (need to re-read a couple of times). To be honest, I'm not really sure why, but taking the heading... # If non-text content is a CAPTCHA ... I would find it easier to read.... # If the content is a CAPTCHA Just dropping that one word makes it easier for me to read... I think it might be because its not required, as a CAPTCHA is being implied to be non-text (in this context)... perhaps more so when under the boxed heading of \"Situations for non-text content (1.1.1)\". The same is true of the other headings... # If non-text content is a control or accepts user input # If content is a control or accepts user input # If non-text content is multimedia # If content is multimedia # If the non-text content should be ignored by assistive technology # If the content should be ignored by assistive technology ############################# Continuing on from the previous point about not using the numerical references in the headings, can we rename... # Common Failures for 1.1.1 ... to... # Common Failures for non-text content (1.1.1) ############################# Again, with the reference codes, by starting the failures with some code, it takes a bit of thought to work out where you can start reading from. So, could we change the format from... # F30: Failure of SC 1.1.1 due to # using text alternatives that are # not alternatives (e.g. filenames # or placeholder text) ... to... # Using text alternatives that are # not alternatives, e.g. filenames # or placeholder text (F30) I have kept the reference code, but moved it to the end, so its still available to the reader, but becomes more of supplementary information. Also, I have dropped the reference to guideline '1.1.1'... this is because the heading already provides this information (no need to repeat it). For another example... # F20: Failure of SC 1.1.1 and 4.1.2 # due to not updating text alternatives # when changes to non-text content occur ... to... # Not updating text alternatives when # changes to non-text content occur (F20) ############################# Continuing on from the previous point about not using the numerical references in the headings, can we rename... # Advisory Techniques for 1.1.1 ... to... # Advisory Techniques for non-text content (1.1.1) ############################# For the headings in the \"Advisory\" section, I think that most of them are fairly short and sweet, which defiantly makes then easy to read. But, I'm mot sure why the headings end with "(Advisory)" though, as I think they should all be advisory points, considering the heading they are under... so could it be deleted? And again, I would quite like to remove the 'non-text' word from the first two "general techniques" headings... as it does seem a little redundant. Also, some of the techniques start with reference numbers, could these be moved to the end, for example... # H46: Using noembed with embed (HTML) ... to... # Using noembed with embed (HTML, H46) ############################# --------------------------------------------- Response from Working Group: --------------------------------------------- ############################# On some of the headings, you have the bracketed text "(for the technologies you checked above)" I'm not really sure this is necessary, and I think it gets too repetitive when going though the whole document. Considering the user must have consciously limited the guidelines using the form, I think this text can be safely removed. Really I'm just trying to reduce the word count, as I think a huge document can put off some readers... especially when going though the headings that contain off-topic text. RESPONSE: The phrase "for the technologies you checked above" is a reminder that the Sufficient Techniques listed may not be all of the possible solutions to meet the Success Criteria. This reminder is useful in situations where the author: - may not find an appropriate implementation within the listed options but may be able to introduce another technology with a solution that can be accommodated. - has saved the settings in their first visit and forgotten this during subsequent visits. ############################# The two 's at the end of the "Sufficient Techniques for 1.1.1" section, I think should be part of their own section. I think these two parts could be called: # Situations for 1.1.1 --- Situation A --- Situation B --- Situation C # Techniques for 1.1.1 --- Short text alternative techniques... --- Long text alternative techniques... These two headings still need a bit of work (more on that in a minute)... but it should help to split the content into the two distinct parts. Continuing on the previous point, if we have a boxed section for "Situations for 1.1.1", then we can loose the "Situation X:" prefixes to the child headings. This will reduce the word count, and we can possibly look at using something like an , or to list the situations... so we don't loose the 'A, B, C' counting. RESPONSE: The situations include techniques that are applicable only in that particular situation. A specific heading such as the one suggested would be misleading in regard to where the techniques are listed. Note that Success Criteria 1.1.1 is the only Success Criteria that includes a group of techniques that may be applicable to multiple situations. Please look at our new format. This should make it clearer. ############################# As to the headings mentioned in the second point, I am not keen on referring to the guidelines by number. So, for example, you could rename the headers... # Situations for 1.1.1 # Techniques for 1.1.1 ... to... # Situations for non-text content (1.1.1) # Techniques for non-text content (1.1.1) Personally, I think that the average website developer will not think about the guidelines by their numerical reference... I would suggest that a couple of words should be used to summarise each guideline (like \'non-text content\' for guideline 1.1.1). Then with the human readable text, we can suffix the heading with the numerical reference in brackets, as this will help the readers move around the document. RESPONSE: Your idea to put the "short name" in each technique or failure title is a good idea. We are implementing it with the short name in parentheses, however, since it stands out from the sentence better. E.g. # Sufficient Techniques for 1.1.1 (non-text content) ############################# In the "situations for non-text content (1.1.1)", I personally find find it difficult to understand the headings (need to re-read a couple of times). To be honest, I'm not really sure why, but taking the heading... # If non-text content is a CAPTCHA ... I would find it easier to read.... # If the content is a CAPTCHA Just dropping that one word makes it easier for me to read... I think it might be because its not required, as a CAPTCHA is being implied to be non-text (in this context)... perhaps more so when under the boxed heading of \"Situations for non-text content (1.1.1)\". The same is true of the other headings... # If non-text content is a control or accepts user input # If content is a control or accepts user input # If non-text content is multimedia # If content is multimedia # If the non-text content should be ignored by assistive technology # If the content should be ignored by assistive technology RESPONSE: That is an interesting point. We have decided to go one step further and change 'non-text content' in all the sub-clauses to 'it'. That way, we both preserve a clear reference to "non-text" content and we shorten them further. ############################# Continuing on from the previous point about not using the numerical references in the headings, can we rename... # Common Failures for 1.1.1 ... to... # Common Failures for non-text content (1.1.1) Again, with the reference codes, by starting the failures with some code, it takes a bit of thought to work out where you can start reading from. So, could we change the format from... # F30: Failure of SC 1.1.1 due to # using text alternatives that are # not alternatives (e.g. filenames # or placeholder text) ... to... # Using text alternatives that are # not alternatives, e.g. filenames # or placeholder text (F30) I have kept the reference code, but moved it to the end, so its still available to the reader, but becomes more of supplementary information. Also, I have dropped the reference to guideline '1.1.1'... this is because the heading already provides this information (no need to repeat it). For another example... # F20: Failure of SC 1.1.1 and 4.1.2 # due to not updating text alternatives # when changes to non-text content occur ... to... # Not updating text alternatives when # changes to non-text content occur (F20) \ RESPONSE: With regard to technique and failure naming, the techniques and failures are all titled in a way that they are understandable when taken out of context. We envision the information to be used in many ways, including pulling out only the information or techniques of relevance. Important information may be lost when part of the content is taken out of context if all of the important information is not contained within the headings. Thus they need to be understandable without looking at the title of the section they are in. This is particularly true for advisory techniques or failures which must not be confused with sufficient techniques. We start all failures with the words "failure of SC XXXX" because the failures could otherwise be mistaken for techniques. Putting NOT in front of them makes them negative techniques but techniques just the same. And techniques are optional, but failures must always be avoided. ############################# Continuing on from the previous point about not using the numerical references in the headings, can we rename... # Advisory Techniques for 1.1.1 ... to... # Advisory Techniques for non-text content (1.1.1) For the headings in the \"Advisory\" section, I think that most of them are fairly short and sweet, which defiantly makes then easy to read. But, I'm mot sure why the headings end with "(Advisory)" though, as I think they should all be advisory points, considering the heading they are under... so could it be deleted? And again, I would quite like to remove the 'non-text' word from the first two "general techniques" headings... as it does seem a little redundant. Also, some of the techniques start with reference numbers, could these be moved to the end, for example... # H46: Using noembed with embed (HTML) ... to... # Using noembed with embed (HTML, H46) RESPONSE: With regard to putting numbers at the end. Sometimes a number of techniques have similar beginnings. To make it easy to see when they are the same or different we put the technique numbers first. It also fits with our overall policy of providing a short way to refer to things right at the front.
Received on Sunday, 4 November 2007 04:18:23 UTC