WCAG 2.0 - November draft - Detailed Suggestions on WCAG Content

[based on comments relating to the July draft and submitted originally as an
anonymous contributor on 23 Nov 04]
Disclaimer: The comments below represent the personal opinion of the sender;
they do not necessarily represent the University's viewpoint.


oo Detailed Suggestions on WCAG Content

- Level 1 Success Criteria: Should it be allowed that accessibility level 1
be achieved through scripting? I thought that the idea of the Web Content
Accessibility Guidelines 1.0 was that web pages should be usable if
scripting was turned off. Has this idea been abandoned?
from WCAG 1.0:
"Priority 1 checkpoints
And if you use applets and scripts (Priority 1)
6.3 Ensure that pages are usable when scripts, applets, or other
programmatic objects are turned off or not supported. If this is not
possible, provide equivalent information on an alternative accessible page."

- Level 2 Success Criteria: 
"Increase accessibility through either or both of the following: 
a. additional facilitation of user agent based accessibility 
b. content and/or presentation that provides direct accessibility without
requiring users or their user agents to do anything different from users
without disabilities"
Phrase a is rather vague and makes the level of accessibility dependent on
the user agent used. Does that mean that if the web pages support
accessibility features of one particular user agent, they can be claimed to
satisfy this requirement? 
Phrase b is hard to understand. What does 'direct accessibility' mean?

- Level 3 Success Criteria: 
"Go beyond Level 1 and 2 to increase direct and user agent enhanced
accessibility" 
What do 'direct and user agent enhanced accessibility' mean?

- Note on Web content presented to a human reader vs. to a structured
database or metadata
How will the principles apply to cases where a database is queried by
another database and then presented to a human reader? The owner of the
original database may not know that this is happening. Who is responsible
for ensuring accessibility?

- Level 1 Success Criteria for Guideline 1.1: 
Not sure that (a) content that is functional is sufficiently different from
(b) content that us used to convey information. Would it be possible to make
the distinction clearer?
Also (5) 'Non-text content that does not provide information, functionality'
> Should this not be made clearer? All content conveys some information,
even if it is e.g. purely esthetical information.

- Example 4 of Guideline 1.1:
Should there not be a long description as well, giving more information on
the structure and musical style of the piece?
This raises the general issue of what is an equivalent description of a
visual or auditory piece of information. For some images, for example
paintings and historic prints, it is quite impossible to give an equivalent
description because every viewer will interpret the image differently. E.g.
a medical historian or doctor may see different information in a painting
compared to a theologian. How can this be dealt with adequately? Typical
examples of such images can be found at
http://special.lib.gla.ac.uk/collection/index.html. 

- Example 1 of Guideline 1.2: 
Sorry, I don't understand the text of this example.

- Level 1 Success Criteria for Guideline 1.3 
"Structures and relationships within the content can be programmatically
determined." > Although correct, will it be clear to readers what is meant
with 'programmatically'? Could this be made more concrete, e.g. by
mentioning user agents and assistive technology?

- Example 1 of Guideline 1.3
It is a general usability guideline to inform users in advance which fields
are mandatory. The example may be interpreted as that users need only be
informed which fields are mandatory after they have filled out and submitted
the form.

- Guideline 1.4 In visual presentations, make it easy to distinguish
foreground words and images from the background. 
Should a distinction not be made between background colours (as defined in
the html or CSS) and background images? Should foreground text over
background images not be discouraged? Will the test for measuring the
contrast take into account how people with different types of
colour-blindness see?

- Level 1 Success Criteria for Guideline 1.4 
If this criterion is met automatically whenever guideline 1.1 is met, should
it be mentioned again as a separate guideline? 

- Level 2 Success Criteria for Guideline 1.4 
My concerns with this are that:
(a) Guidelines like this exclude a certain percentage of users because the
criterion will invariably be based on x% (90-95%) of users' sight. Is this
not contradicting the principle of universal access?
(b) The measurement is software-based and does not take into account how the
hardware will display the contrast. Different users will use different types
of hardware, e.g. handheld devices and older monitors, which will make it
quite impossible to predict how users will see the contrast. 
Should Point 2 under Level 3 Success Criteria for Guideline 1.4 not be the
only level 1 success criterion for this guideline? The current Level 1
Success Criterion for Guideline 1.4 opens the door for using background
images which obscure the text. Only requiring that the text can be
re-presented in a form which allows the text to be distinguished from the
background is not very user-friendly. It implies that the user needs to
invoke some action (via a user agent or other software) to be able to read
the text. This is not in line with usability principles. 

- Level 3 Success Criteria for Guideline 1., Point 2
Would it not be clearer to non-technical readers if the text in the note was
incorporated in the success criterion and the notion of decibels left out?
How can content authors measure the background noise against the audio
content in practice? Will this guideline work in practice? 

- Level 1 Success Criteria for Guideline 2.1 
Point 1: "where the functionality or its outcome can be described in a
sentence" > is this qualifier quite accurate and to the point? What is meant
with the functionality of the content? Whether or not the functionality can
be described in one sentence will depend on the writing skill of the content
author - is this testable? Different people will definitively come up with
different options on whether content meets this guideline. Is the one-line
limit useful? 

- Level 1 Success Criteria for Guideline 2.1 and Level 3 Success Criteria
for Guideline 2.1
What is the difference between 'is operable' and 'is designed to be
operated'? In theory, there can be a difference between whether keyboard use
was considered during the design or not but what matters is the end result -
not the intentions of the designer. Also, considering keyboard use at the
design stage does not mean that the resulting solution is usable at all.

- Level 2 Success Criteria for Guideline 2.1 
What is meant with 'more abstract'?

- Examples of Guideline 2.1
.. Example 1: I think 'API of the environment' is too technical a term. 
.. Example 2: 'If it's written' > what does 'it' refer to?

- Level 1 Success Criteria for Guideline 2.2
The fact that the user is allowed to deactivate the time limit conflicts
with the fact that the time limit would be essential. 
The fact that the time limit will expire anyway if the user does not react
within 10 seconds, means that the user has to keep paying attention to what
is going on - this can be a problem in a noisy environment or if the user is
performing another activity at the same time. It can also be a problem for
users with concentration problems, especially if they are being distracted
by other activities going on around them.
The first three options (being able to deactivate the time limit, being able
to adjust it and being warned) are not really ideal from a usability point
of view. Why bother the user with having to deactivate or adjust the time
limit or respond to a warning? This requires extra effort from the user.
Either the time limit is essential (e.g. in competitive gaming) or it isn't
and in that case the time-limit should not be there. 

- Level 2 Success Criteria for Guideline 2.2 
Points 1 and 2: 
Again this can lead to violation of basic usability guidelines. Should the
option to turn off, pause or stop be allowed? Is providing the option to
turn off, pause or stop good enough? Should content authors not be
encouraged to provide a usable experience for end users? 
At which level would turning off or pausing/stopping apply? For every
individual bit of text? This would mean that it is ok to have a page with 10
blinking pieces of text which the user must click individually to stop the
blinking.

- Level 3 Success Criteria for Guideline 2.2, Point 2
Allowing the option that the user can postpone non-emergency interruptions
such as updating of content is requiring more effort than necessary from the
user. Also, interrupting with the option for the user to postpone the
interruption makes that the user is not in control. Should it not be the
other way around that the user can request an update of the content if he
wishes so? 
Again, the question raises - if the user can postpone interruptions - at
which level should this happen? One for the page? Once for the site? For
every individual occurrence of frequently updated content?

- Examples of Guideline 2.2
"dialog that disappears after a short period" > Does this mean that the user
must be able to avoid that the dialog box will disappear? But Level 1
Success Criteria for Guideline 2.2 itself uses a warning which times out
after at least 10 seconds. Is this not conflicting?

- Examples of Guideline 2.2 
Example 1: See above re. comments on requiring action fro the user to turn
off blinking - and re. the level at which this would be acceptable. 
Example 2: Having the option to turn off updating of content in a separate
'user preferences' part of the web site opens the door to web sites which
are accessible in theory but aren't in practice. Only a small percentage of
users ever change default user settings. Also, it would very much depend on
the rest of the site whether or not this feature would be discoverable. For
example, if the link to the preferences section would be at the very bottom
of a page, chances are small that e.g. screen-reader users would encounter
the option. 

- Guideline 2.3 Allow users to avoid content that could cause photosensitive
epileptic seizures. 
I think the information in the Glossary for Success Criteria for Guideline
2.3 is much too technical. If the tool from the University of Wisconsin's
Trace Center is available, could the success criteria not simply require
that the content be tested with this tool and that certain simple criteria
are met? Moving the technical details from the actual guidelines to the
glossary (as was done between the July and the November draft) does not
solve the problem of this information being too technical.

- Guideline 2.4 Provide mechanisms to help users find content, orient
themselves within it, and navigate through it.
Is "find content" not ambiguous? This could be interpreted as referring to
search functionality.  

- Level 1 Success Criteria for Guideline 2.4 
In answer to the editorial note, I would suggest including the success
criterion only in guideline 1.3 and not in guideline 2.4. Guideline 1.3
covers the separation of content and structure from presentation. I think
this success criterion fits there better than under 2.4, which relates to
structure itself.

- Level 2 Success Criteria for Guideline 2.4 
.. Point 1: Why is reference made to 'documents'? What does the term mean in
web context? A page? 
.. Point 2: Requiring more than one way to locate content does not put any
constraints on how effective search and metadata need to be. If metadata,
for example, are not chosen appropriately and do not use the terminology
which the end user uses, a web page can meet this requirement in theory but
not in practice. E.g. if a web page is aimed at laymen and uses only
specialized medical terms in the metadata and the text, it is unlikely that
the end user will find the web page using search. Again, this opens the door
to accessibility in theory but not in practice. 

- Level 3 Success Criteria for Guideline 2.4 
.. Point 1 "When content is arranged in a sequence that affects its meaning,
that sequence can be determined programmatically."
I think this success criterion is too vague; sequence will almost always
affect the meaning of the content - in most cases, reading order will not be
irrelevant.
Point 3: What is meant with structure for images?
.. Point 5 Text is divided into paragraphs.
Does this refer to the linguistic meaning of paragraph (a block of text) or
the mark-up (e.g. <p> </p> in html)? Text will usually be divided into
paragraphs. Does this also put visual constraints? E.g. Paragraphs can be
marked up correctly in html but the individual paragraphs may not be
discernable visually.
In the Level 3 Success Criteria for Guideline 2.4, the guidelines are trying
to pin down what 'good structure' is but I think this is quite impossible to
catch. A skilled (web) author should be able to present information in a
well-structured way. I don't think the guidelines should try to cover this
because it is impossible to do this accurately. 
Point 6: Why does this mention 'documents'?

- Who Benefits from Guideline 2.4 
.. When the logical structure is provided in mark-up or a data model, all
users - not only users with cognitive disabilities - can use structure
(chapter titles, headers, etc.) to provide more context for the text that
follows them. 

- Examples of Guideline 2.4 
.. Example 1: Could this not be made more web-oriented?
.. Example 2: What does this example mean? Sorry, don't understand.

- Level 2 Success Criteria for Guideline 2.5 
"Where consequences are significant and time-response is not important, one
of the following is true: 
Actions are reversible. " > From a usability point of view, actions should
always be reversible, unless in very specific and valid cases.
Actions should always be checked for errors if at all possible, also if
actions are reversible. Could this be made clearer?

- Level 3 Success Criteria for Guideline 2.5
Point 1: Why the limit of 75?
Should both selecting from a list and entering directly as text always be
provided? That can lead to cumbersome and ambiguous forms.
Point 2: Should the decision to offer spell checking and to suggest correct
spellings not be left to the content author? The usability of the result
will very much depend on factors such as:
.. Quality of the dictionary used. The average web author will not be able to
purchase a high-quality online dictionary.
.. Language being used by the user. If a user enters information in a
language different from the language of the web page (and this can well be
relevant in particular cases), the dictionary will not cover the words used
and this will be very annoying for the user.
.. Terms and names used. If the user uses more technical terms than the
content author has anticipated, a lot of errors will be flagged up which
again be very annoying for the user. Same applies to foreign or less
well-known names. 
Another area for user frustration is postal codes. Often the content author
has not anticipated that the user can live in a different country and only
certain address formats are accepted. 
Offering 'corrections' to words the user has typed in can actually introduce
extra errors since it can lead to the user acknowledging corrections by
mistake. 
In general, systems which try to be too clever usually get on users' nerves.

- Who Benefits from Guideline 2.5 (Informative) 
Not sure whether identifying supposed typing errors will actually help
dyslexic people and people with other disabilities. It is quite hard to
select the correct word from a list of very similar words. Maybe it should
be left to the user to turn to a dictionary or spell checker of his/her
choice and language rather then forcing one on him by the content author.
And anyway, in most cases, typos are not the end of the world. Only in
critical cases, e.g. passwords and critical personal information, should the
user be asked to double-check and then it is up to the user to verify the
information. I don't think content authors should try to be too clever.  

- Level 1 Success Criteria for Guideline 3.1 
"The meaning of abbreviations and acronyms can be programmatically located."
> should abbreviations and acronyms not always be expanded in the text?
Should the user be required to use software to find the meaning of
abbreviations and acronyms?

- Level 2 Success Criteria for Guideline 3.1 
Point 1: Will this always be possible? What about minority languages and
dialects?
Point 2: What about regional languages and dialects?
Point 3 - Note: What is meant with 'standard extension of the language'? Is
this unambiguous?

- Level 3 Success Criteria for Guideline 3.1 
Point 1: I don't think this is very practical in practice for the reason
that 'associated dictionary(s)' is not always unambiguous. Which one would
it be for British English, for example? The Oxford? If so, which edition?
Point 3: 
This opens the door for sites having statements but not being accessible in
practice. I think that the W3C should be encouraging good practice - in
deeds, not in words. 
I strongly believe the additional information on writing for the web (from
'In General' up to and including 'Logic and Relationships') should not be
included in the WCAG. See the section 'Scope of the Document' above.

- Level 3 Success Criteria for Guideline 3.1 
'Instructions and operable content' > thoroughly explaining instructions:
What does this refer to? Does it refer to help about web pages? If so, I
believe web pages should not have help but should be intuitive to use.
Effort spent on writing help could be much better spent on improving
navigation, labels, etc.
What is meant with 'menu prompts'?

- Who Benefits from Guideline 3.1
Providing expansions of abbreviations and acronyms is general good practice,
beyond the web. Should this be included here?
What is meant with 'Facilitating unambiguous decoding of characters'?
Summarizing information that is difficult to understand helps people who do
not read well. > Helps everyone.
What is meant with 'Providing a summary of the visual cues that show
relationships'?

- Examples of Guideline 3.1
.. Example 4: How does these tie in with the guideline?
.. Example 7: Should a text alternative describing the clip not be added
(Guideline 1.1: For non-text content that is intended to create a specific
sensory experience, such as music or visual art, text alternatives identify
and describe the non-text content)?

- Level 2 Success Criteria for Guideline 3.2 
Point 1: Does this apply to navigational as well as content components? If
so, should a certain variation in content components not be permitted, at
the judgement of the content author?
Point 6: Should the destination of links not always be identifiable through
the words or phrases and optionally also programmatically?
A related issue which was mentioned in WCAG v1.0 (and has been dropped in v
2.0?): Links were supposed to start with unique words. This breaks the
parallel construction of e.g. lists which is recommended from a writing
point of view. Which should prevail? 

- Level 3 Success Criteria for Guideline 3.2
Achieving a consistent look and feel is more complex than suggested by the
Level 3 Success Criteria for Guideline 3.2. The danger is that content
authors interpret the letter of the WCAG and ignore wider best practices. 
Point 1: If they have the same function/meaning in different pages. An image
may have a slightly different meaning depending on context or audience.
Point 2: Should this apply to sections in the main content? There may be a
good reason to lay out a page differently.
Point 3: What the success criterion does not say is how easy this should be
for the average user. This will impact usability.

- Who Benefits from Guideline 3.2 
First bullet: This is a general usability issue. Should it be covered in the
WCAG?

- Examples of Guideline 3.2
Example 1: If this approach is allowed, users have to check the checkbox for
each page and every time they visit this page. This is not quite usable. 

- Level 1 Success Criteria for Guideline 4.1 
Should breaking a specification be allowed? Will this not mean the web site
will work with one particular user agent or type of assistive technology and
not with others. Is this not against the idea of accessibility? 

- Who Benefits from Guideline 4.1
The (unsolved) problem is that current technologies do not respect the
specifications. So as long as they don't, content authors will need
work-arounds from time to time.

- Level 1 Success Criteria for Guideline 4.2
Point 1 is difficult to understand, partially because of the reference to
points (a) to (i). Is the phrase 'If inaccessible plug-ins are available'
necessary?
Point 2: Could 'programmatic user interface components' be expressed in a
way which would be clearer and not need referral to the glossary?

- Level 2 Success Criteria for Guideline 4.2 
What is meant with 'accessibility conventions of the mark-up'? 

- Level 3 Success Criteria for Guideline 4.2 
Point 2: Would it be useful to explain what a degraded but still usable
experience is?

- The guidelines are not quite balanced in terms of level of detail. E.g.:
Guideline 1.3 Ensure that information, functionality, and structure are
separable from presentation. >  high-level guideline
Guideline 1.4 In visual presentations, make it easy to distinguish
foreground words and images from the background. > quite detailed guideline

- The success criteria are not quite balanced in terms of level of detail.
E.g.:
Level 1 Success Criteria for Guideline 1.3 
1. Structures and relationships within the content can be programmatically
determined. > high-level criterion
2. Emphasis can be programmatically determined. > quite detailed criterion
3. Any information presented through colour is also available without colour
(for example, through context or mark-up or coding that does not depend on
colour). > quite detailed criterion



oo Minor Suggestions
- For reviewing subsequent drafts, it would be useful if there could be
links from the change history to the draft whenever possible.

- 'Automatic refresh' is not really a type of content, it is an action, a
technique.
"Examples of Guideline 2.2 (Informative) 
Examples of content that must meet the success criteria of this checkpoint: 
automatic refresh, 
redirection, ..."
- "Level 3 Success Criteria for Guideline 3.1 
.... Section headings and link text are understandable when read by
themselves as a group ..." > Is this quite clear?

- Should some instances of 'where' not be replaced with 'if'? 
Examples:
.. "Level 3 Success Criteria for Guideline 3.1 
Where a word has multiple meanings ..." > 'If a word ...'
.. "Level 2 Success Criteria for Guideline 2.5 
....Where consequences are significant"
.. Level 3 Success Criteria for Guideline 3.1 > 'Being clear where the
document:' 


Dr. Catherine M. Brys
Library Web Services Administrator
- Library Web Site Accessibility and Usability Project - 
Glasgow University Library, Hillhead Street, Glasgow, G12 8QE, Scotland, UK
e: c.brys [at] lib.gla.ac.uk
t: +44 (0)141 330 6748
w: www.lib.gla.ac.uk/accessible

Received on Monday, 10 January 2005 17:27:07 UTC