Evaluation/Cognitive perspectives on WCAG2.0

As an accessibility auditor, and as a learning disabilities specialist 
here's my take on WCAG 2.0. My overall sense it that it is missing 
something. Since most of our work focuses on reviewing the accessibility 
of HTML content, I would guess that Techniques or HTML Accessibility 
will help clarify the general guidelines presented in WCAG2. Others have 
expressed this in other post, so I'll try to stay focused on how these 
guidelines affect evaluation, and affect people with specific cognitive 
disabilities. I would also suggest synchronizing WCAG guidelines with 
components of the IMS ACCLIP specifications.

ACCLIP
http://www.imsproject.org/accessibility/acclipv1p0/imsacclip_infov1p0.html

Perceivable
1.1 Include an example of a non-meaningful non-text element with an NULL 
text equivalent used to force AT to ignore the element (empty Alt text 
specifically). A spacer can be "expressed in words" but should not be, 
otherwise it interferes with comprehension of the meaningful content on 
the screen, particularly for those with cognitive disabilities. (see 
proposed "reduce clutter" guideline in "Understandable")


1.3 Are tables used for layout (i.e. to structure content) a violation 
of this guideline?

Evaluation: Enforcing non-table layouts is not possible at this time for 
any more than Web sites with  simple presentations. Clients will often 
respond to minimizing the use of layout tables, but not to removing them 
completely. This will likely change as browsers become more consistent 
in the support of CSS layout properties. Minimal table layouts pose no 
accessibility barriers for relatively current assistive technologies.


1.4  I had a hard time understanding what this guideline was talking 
about. Needs more examples. Are the use of 8859 and windows charsets 
etc. still legal, under the assumption that these charsets can be mapped 
backed to unicode (utf-8/16)? Does this mean a developer must provide a 
utility that will convert other charsets to unicode? Need more 
explanation of "mapped back to Unicode".

Should Best Practice 1  for Checkpoint 1.4 be included with guideline 
3.2 instead?

1.5 Association between table headers and data cells in many cases is a 
necessary feature of tables for comprehension by blind users (I'm 
assuming this guideline fits here). Limited short term memory otherwise 
makes it difficult to mentally make header to data cell associations 
beyond the first few rows of a large data table. This should probably be 
a Core requirement, retaining its P1 designation from WCAG 1.0. Form 
labels are less critical provided they are position next to a form 
field, so they could probably remain an extended guideline.

1.6 While contrast can usually be assessed through subjective 
experience, how will it be objectively measured if for instance 
foreground and background contrast levels are questionable.

Operable
2.1 [Exception: onclick, in reality, has become a device independent 
event handler, normalized through broad adoption by Web browser and AT 
developers].

2.4 50,000 words is a lot of words. Any single screen over a few hundred 
words could provide a means to navigate among the major sections of the 
page, if they exist, and aid comprehension by providing an overview of 
the page and quick navigation to specific points in a page (anchors 
before primary headings and a linked table of contents at the top of the 
document). Take the WCAG 2.0 document itself. It contains less than 
14000 words.

One of the other commenters suggests that the common table of contents 
anchor links that are found at the top of many long document interferes 
with effective navigation through a page because this can be done more 
effectivley by listing the headings on the page. But, from a cognitive 
perspective, a table of contents at the top of a long document can be an 
invaluable tool for learners with learning disabilities. I myself find 
them quite useful for providing a quick summary of a page without having 
to scroll through the page and keep headings in mind as I move through 
multiple screen fulls of content.  In this instance I would suggest that 
the table of contents be a feature for page that include more than 5 
subsections and 5000 words, and be optional as per the ACCLIP 
useTableOfContents preference. A screen reader user can benefit from 
having TOC turned off, while an LD user can benefit from having them 
turned on.

Site navigation mechanism: what are "dynamic fisheye views"? Is it a TOC?


2.5 Required criteria for this guideline applies to success feedback as 
well as error feedback. When a screen reader user for instance, submits 
a form that performs a particular action, they will often want to verify 
that the operation was successful. Without success feedback it can be 
very time consuming to make this verification.  "2. after a successful 
operation , provide the user with confirmation feedback".

Success feedback might have its own guideline (2.6,  though it might fit 
as 3.4 (3c)) since it is fundamentally different from error feedback, 
and error recovery.  However, both error and success feedback could be 
consider  "graceful recovery". We distinguish between error, warning, 
and success feedback in ATutor. Error messages state the problem that 
occurred and provide courses of action. Warnings state that a possible 
error has occurred and provide a means to revert to a previous state our 
take an alternative course of action. Success feedback provides simple 
confirmation (in most cases)

ATutor Instructor Demo (see the feedback system as an instructor by 
performing various tasks such as creating, updating, or deleting 
content, modifying preferences, posting announcements....)
http://www.atutor.ca/atutor/demo.php

See "Learning from Your Mistakes" for more about fundamental cognitive 
differences between error and success feedback
http://www.ldrc.ca/projects/projects.php?id=23

Understandable
3.2
Best Practice for Checkpoint 3.2 #2.b is not related to the guideline 
itself? How is a summary related to unambiguous presentation of 
abbreviations or acronyms.  Nor do some of the definitions or benefits 
listed with this guideline seem relevant.

A separate guideline is needed to outline the need for summary or 
context information such as table summaries, frame titles, list priming, 
...

3.3
Evaluation: While I agree with all the points listed under Required 
Criteria from a  learning disabilities perspective, evaluating the 
familiarity of terms and language structure, length and complexity, and  
coherence of paragraphs (1.abc) in many cases would not be possible 
without undue expense. While we evaluate technical compliance and 
practical usability in our accessibility assessments, in many cases it 
would not be realistic for us to review the integrity of the content 
itself. That would, in most cases, involve analyzing a significant 
amount of information, and would increase the assessment effort  (and 
cost) excessively. Copy editors do this kind of work, and content 
reviewing represents an expertise on its own that can't be expected of 
an accessibility evaluator.

Other reasons for not including language as a criteria for accessibility 
also come to mind: how to create an objective measure for automated 
evaluation utilities;  at what point does a site fail this guideline; 
how might language usage requirements vary depending on the context or 
intended audience, and how would you measure that ...  There's too much 
subjectivity. Measures of word and sentence length provide only a very 
rough estimate of language complexity. Word frequency stats would also 
need to be assessed to determine the complexity of language.

This requirement might distinguish between language used in content or 
information and language used in the interface or application itself, 
the latter of which can reasonably be evaluated in most cases.

In example 5, linking to a sound clip is providing an alternative format 
rather than providing a simpler form.

A distinction needs to be made between simpler forms and alternative 
forms (i.e. Multi-modal presentations). As suggested in the Note in the 
Benefits section, providing a picture to supplement text information, 
suggests that an alternative format does not necessarily represent a 
simpler form.


3.4 An extreme change can be identified after the change has occurred, 
such as a "close new window" link as the first feature of a popup 
window, or presenting a feedback message after server side redirecting a 
user from the content editing screen to the content display screen when 
editing is completed (feedback like "content was successfully updated" 
see guideline 2.5 above).

guideline should read "..., but not necessarily identical".



Robust:
4.1 Does this include nonW3C technologies: Javascript, Active X, 
Flash,... used according to specification? Can developers use these 
technologies if they are designed with accessibility features. How would 
an evaluator determine if Javascript or perhaps Flash has been used to 
specification? Whose specification for Javascript. I also would imagine 
Javascript can be used to specification, but be innaccessible. In 
combination with the "device independence" guideline, this might work.

(1c) Could be interpreted as "all" or "one of the" accessibility 
features have been used. Using enhanced features like accesskeys, 
explicit form labels where adjacent implicit labels are sufficient, and 
table summaries are not otherwise required for CORE compliance (ala WCAG 
1.0 P3 items). Which accessibility features need to be used?

Best practices "Benefits of Checkpoint 4.1" does not seem to apply to 
issues of specification validation.  How does providing a search engine 
relate to using technologies according to specification.

Scenario for testing Guideline 4.1
A developer creates a Flash MX presentation that makes use of all the 
accessibility features that are available. While the Flash presentation 
is accessible to JAWS 4.5 and Windoweyes 4.2, it remains inaccessible to 
all other assistive technology users. Is this Flash presentation WCAG 2 
compliant? Given the majority of screen reader users are likely to be 
using pre  4.0 versions of these technologies, the Flash MX presentation 
will not be accessible to them.

How has the "until user agents support..." problem in WCAG 1 been dealt 
with? Are there limitations on support for older technologies when newer 
versions of these same technologies are available that do support newer 
accessibility features?

There needs to be some agreement on limitations to supporting older 
technologies. Do developers still have to support IE 3, or Netscape 3 
(or Netscape 4 for that matter) given the percentage of users still 
using these technologies in miniscule, and likely nonexistent for users 
who require accessibility support?

4.2 Need a quantitative definition for "widely available". Widely 
available technologies in English is not likely the same as widely 
available in Farsi, for example.  "Easily available" might be a better 
choice of words.

4.3 Keep this guideline but reword "versions" to "representations of the 
content", to suggest presenting the same content in different ways 
rather than presenting multiple copies. This guideline should be 
retained to discourage the creation of alternative versions (such as a 
text only site) when the original itself could be made accessible.

Text only sites should be a transformation of the original content (such 
as wrapping an accessible header/footer around the same content that 
appears in another less accessible header/footer)? Two versions of the 
same content should still be discouraged, but transformations of the 
same content should not.

New Guideline Suggested for Section 3 Understandable
3.5 [EXTENDED] Minimize the use of repetitive and non-meaningful content.

A guideline is needed to encourage  reducing information overload for 
screen reader users, and users with cognitive disabilities, essentially 
minimizing, or providing a means to minimize complexity. Within the  
Understandable guidelines an additional extended guideline should be 
introduced that requires minimizing the amount of irrelevant or 
non-meaningful or repetitive information. Such instances might include 
using an empty Alt attribute to cause AT to ignore meaningless images,  
using and empty summary attribute for irrelevant layout tables,  or 
using empty Alt for icon links reproduced as alternative text links so 
links are not announced twice....

Concession for necessary violations:
In the previous draft of WCAG2 there was a concession for necessary 
violations which allowed developers to document these violations as 
necessary, in many cases for backwards compatibility. For example, we 
use the Target attribute as a backup access strategy for popup windows 
controlled by Javascript. If Javascript support is not present, then  
the new window opens in a window defined in the target attribute. Target 
is deprecated so this would be a violation of 4.1, but without this 
violation we are not aware of another strategy that would allow 
developers to use new windows in a fully accessible manner.

I am aware of the arguments against the use of new windows,  though I 
think it is unrealistic to expect developers not to use them.  In fact 
not using them in some instances impedes accessibility from a cognitive 
perspective. Help windows for instance are often more useful if they are 
opened alongside the screen they reference so users can read the help 
information in one windows, and apply the help suggestions in another, 
rather than trying to flip back and forth between help and its reference 
in the same window.

Another example is the use of EM as a font size measure (as well as a 
number of other style attributes used within tables), which do not 
function effectively, or function adversely in Netscape 4. With 
limitations on the backwards compatibility this may not be an issue, but 
many clients require their sites to function effectively in Netscape 4, 
and as such need to be able to violate certain guidelines to do so.

There's lots of other instances where violations are likely to be 
necessary.

Developers need to be able to use workarounds that violate guidelines, 
provided they are necessary and they are documented in an accessibility 
statement.


Greg Gay
Adaptive Technogy Resource Centre
University of Toronto

Received on Tuesday, 2 September 2003 08:17:47 UTC