- From: Craig Francis <krang@krang.org.uk>
- Date: Sat, 3 Nov 2007 20:13:42 +0000
- To: public-comments-wcag20@w3.org
In regards to the comments to my original post at: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0073.html First of all, thank you for reviewing them... generally I agree with your point of view, but have a couple of comments... ############### 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) ----- FIRST 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) ----- MY RESPONSE: Thank you for implementing the change... I think that will be much better, but I'm not completely convinced by putting the 'short name' in the parentheses, as you will need to read the first part, skip the middle, and then read the end. Perhaps I am just thinking about developers trying to read the spec like a book... but by having the short title as part of the heading, it makes it easier to read as a sentence (human bit), with the additional information being placed at the end (computer based ID). I think this would help keep that information in context, without breaking the reading process... as the ID at the end can be skipped over without much thought. ############### 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) ----- FIRST 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. ----- MY RESPONSE: That is a fair point, I did not realise that it could be taken out of context like that. In which case, could the prefix be updated to help pattern recognition... so the human eye can scan over it to read the important bit. For example, with the (truncated) list: # F30: Failure of SC 1.1.1 due to using text # F20: Failure of SC 1.1.1 and 4.1.2 due to not # F3: Failure of SC 1.1.1 due to using CSS to # F39: Failure of SC 1.1.1 due to providing a text # F38: Failure of SC 1.1.1 due to omitting the If the "F" codes where all 3 characters long, it would make them easier to scan over: # F30: Failure of SC 1.1.1 due to using text # F20: Failure of SC 1.1.1 and 4.1.2 due to not # F03: Failure of SC 1.1.1 due to using CSS to # F39: Failure of SC 1.1.1 due to providing a text # F38: Failure of SC 1.1.1 due to omitting the Although, it might be worth using a 4 digit code if you expect the failure codes to go over 100. Also, could that prefix be in bold, so it acts like an inline heading... again, this should help with scanning over the list, so developers don't need to read over the ID's, which does not really mean anything to a human in this context. I'm not sure how your system works, but a regexp like the following might help: /\bF([0-9])\b/F0$1/ ############### Anyway, thanks for the comments, the document does seem to be shaping up nicely. Craig
Received on Saturday, 3 November 2007 20:13:55 UTC