W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > November 2007


From: Craig Francis <krang@krang.org.uk>
Date: Sat, 3 Nov 2007 20:13:42 +0000
Message-Id: <F474BA0B-DB42-4999-A278-A367D8253923@krang.org.uk>
To: public-comments-wcag20@w3.org

In regards to the comments to my original post at:


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)



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)



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)



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.



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  

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:



Anyway, thanks for the comments, the document does seem to be shaping  
up nicely.

Received on Saturday, 3 November 2007 20:13:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:45 UTC