Trying to help readability

Name: Craig Francis
Email: craig@synergycms.com
Affiliation: 
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.



Best Regards,

Craig









#############################



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)



#############################

Proposed Change:
See comment

Received on Saturday, 9 June 2007 16:47:32 UTC