Issue summary - "Cognitive" sort term

"Cognitive" sort term
Summary of Issues:
1.	WCAG 2 does not address needs of people with cognitive disabilities or learning difficulties, so the claim to cover these disabilities should be removed from the introduction, or additional support should be added. (526, 566, 569, 615, 652, 1021, 1036, 1279, 1309, 1408)
2.	Benefits statements reflect incorrect understanding of various cognitive disabilities (470, 542, 1124)
3.	WCAG documents are not accessible to those with cognitive disabilities (620)
4.	Captioning SC will discourage multimedia that addresses cognitive needs(608)
5.	Suggestions for new SC:
a.	"When web units contain text, the clearest and simplest language appropriate for the users of the content is used and large blocks of information are presented using appropriate headings and subheading." (470, 1255)
b.	"When forms are presented, the controls in similar areas of a form should be grouped together and appropriately identified." (470)
c.	Include information on how mistakes can be prevented (568, 1057, 720?)
d.	Avoid use of justified text, long line length, multiple columns, overuse of styles (569, 1253)
e.	Form guidelines for CD (633)
f.	"Explain/describe/warn about the existence of unusual user interface features or behaviours before they are encountered." (946)
g.	WCAG1 14.2 (supplement text with graphics or auditory info) (1258)
Recommendations or Suggestions:
1.	Distinguish more carefully between different types of cognitive disabilities
2.	Adjust WCAG2 claims to make clear that only some CD are addressed
3.	Can we come up with testable SC that address any of the issues raised?
4.	Add advisory techniques for non-testable recommendations 
5.	Alternate representations are important for these disabilities - actively encourage alternate versions? Task-based conformance?
****************************************************************
Comment LC-470
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: substantive
Location: meaning <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Item Number: Make text content readable and understandable. 
Part of Item: 
Comment Type: TE 
Comment (Including rationale for any proposed change): 

Guideline 3.1 is concerned with the need to make text readable and understandable. In general WCAG 2.0 contains very few provisions for improving the accessibility of web content for people with cognitive disabilities or learning difficulties. There is the level 3 SC 3.1.5, which is concerned with the reading level of text, however it is a fallacy to assume all cognitive disabilities somehow relate to a persons ability to read. 

WCAG 1.0 contained the Priority 1 Checkpoint 14.1 (Use the Clearest and simplest language appropriate for a site's content). It also contained the Priority 2 Checkpoint 12.3 (Divide large blocks of information into more manageable groups where natural and appropriate). Combined these two checkpoints communicated the desirability of preparing content that could be accessed by people with a range of cognitive and intellectual abilities and suggestions for how this could be achieved. Unfortunately, WCAG 2.0 does not appear to contain a similar commitment or guidance to these issues. 

Proposed Change: 
Guideline 3.1 should contain two new Level 2 success criteria, which read: 

1. "When web units contain text, the clearest and simplest language appropriate for the users of the content is used and large blocks of information are presented using appropriate headings and subheading." 

2. "When forms are presented, the controls in similar areas of a form should be grouped together and appropriately identified."
Status: open

Comment LC-526
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: general comment
Location: intro <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Item Number: (none selected) 
Part of Item: 
Comment Type: ED 
Comment (Including rationale for any proposed change): 

Currently the introduction identifies cognitive limitations as one of the disabilities that WCAG 2 addresses. Unlike WCAG 1.0, WCAG 2 gives only scant recognition to the needs of people with disabilities. 

Proposed Change: 

Either improve WCAG 2.0 or remove the suggestion that the needs of people with cognitive limitations (or difficulties) will be met.
Status: open

Comment LC-542
Sort Terms: cognitive reading-level
Document: Understanding WCAG 2.0
Submitter: Greg Gay <g.gay@utoronto.ca>     Affiliation: ATRC UofT
Comment Type: substantive
Location: meaning-supplements <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>  
Comment:
Item Number: How to Meet Success Criterion 3.1.5 
Part of Item: Intent 
Comment Type: GE 
Comment (Including rationale for any proposed change): 

The statement "help people with reading disability" in the intent section of the How to meet 3.1.5 section is incorrect. The ability to comprehend high level language is not related to reading disability. Reading disability is strictly associated at a more general level with lessened ability to mentally convert visual textual information, into verbal auditory information (phonemic awareness). There is no concept of semantic disability associated with reading disability. By definition, a person with a reading disability does not have a semantic processing disability, with normal or above normal intelligence. There are several references throughout the HowTo document that refer to reading disability as an inability to understand. These statements need to be removed. They are not true (see: howto 3.1.6). Reading disability does not affect a person's ability to understand. 

Proposed Change: 

Remove references to simplified language being an accommodation for those with a reading disability.
Status: open

Comment LC-566
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: substantive
Location: accessible-alternatives <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: GE 
Comment (including rationale for proposed change): 

Guideline 4.2 relates to the need to ensure content is accessible or provide an accessible alternative. I am concerned that overall, WCAG 2.0 does not sufficiently recognise the needs of people with cognitive disabilities or limitations and this guideline in particular does not appear to specifically address these needs. 

In my country (and I imagine in most others) people with cognitive disabilities and learning disorders represent the largest proportion of the population with disabilities. In its current state, WCAG 2.0 could leave a site developer, who is keen to improve the accessibility of a site for people with cognitive disabilities, with the incorrect impression that all they need to do is ensure the content is at an appropriate reading level. 

WCAG 2.0 should not avoid addressing the needs of people with cognitive disabilities with the vague excuse that it is not immediately possible because today\'s technologies and user agents do not adequately support content negotiation. 


Proposed Change: 

I strongly urge the Working Group to provide more comprehensive guidance in how to improve the accessibility of web sites for people with cognitive disabilities and learning disorders in WCAG 2.0. 

I suggest Guideline 4.2 (and the associated documents) should specify different ways of improving the accessibility of content for people with cognitive disabilities and learning disorders. Also, the Guideline should clearly indicate appropriate ways of providing accessible alternative content.
Status: open

Comment LC-568
Sort Terms: cognitive -errors
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: substantive
Location: minimize-error <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (including rationale for proposed change): 

Guideline 2.5 states, \"Help users avoid mistakes and make it easy to correct mistakes that do occur.\" The Level 1 and Level 2 Success Criteria for this Guideline all appear to be concerned helping people recover from mistakes. The only SC that relates to avoiding mistakes in the first place is a Level 3 criterion. 

Proposed Change: 

I suggest the Working Group consider including more information on how mistakes can be avoided. At the least, Success Criteria 2.5.4 should be a Level 2 criterion.
Status: open
Working Group Notes: [TEAMC] [HOLD] 

Discussed at Team C call 30 May, 2006 http://www.w3.org/WAI/GL/2006/05/30-wcag-teamc-minutes#item04 <http://www.w3.org/WAI/GL/2006/05/30-wcag-teamc-minutes>  

We recommend rejecting this comment. The working group discussed this issue many times. While we all agree that providing help is generally a good idea, we could not come to consensus on a success criteria that would be applicable to all websites which is our requirement for Level 1 and 2. SC 2.5.3 #3 does provide one success criteria at Level 2 for helping users avoid mistakes in certain situations. So we do have something small at Level 2 for helping users avoid mistakes. 

We do recommend, however, adding an advisory technique on providing help information to "Understanding Guideline 2.5" 

<proposal> 
[REJECT] 
Providing help is generally a good idea but may not be applicable to all websites. Our criteria for SC at Level 1 or 2 is that it has to be applicable to all websites. The Level 2 SC 2.5.3 # 3 does have a requirement for helping users avoid mistakes in certain situations. And we will be adding an advisory technique on providing help information to the "Understanding guideline 2.5" information. 
</proposal> 

01 June 2006 
resolution: 568 - give this a short name cognitive-errors. send back 
http://www.w3.org/WAI/GL/2006/06/01-wai-wcag-minutes.html

Comment LC-569
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: substantive
Location: meaning-supplements <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (including rationale for proposed change): 

I have two main concerns with 3.1.5: 
First, the nominated Success Criterion is Level 3, which suggests that it is only necessary to \"achieve additional accessibility enhancements\" and does not need to apply to all Web resources (without any indication of the resources it should apply to). 
Second, 3.1.5 concentrates solely on a persons reading ability, which is only one of the factors that can influence how well different people with cognitive disabilities or learning difficulties are able to understand a document. For example, what about people who can read well but have considerable difficulty negotiating a complex text-type or comprehending what is written? Or, the additional burden fully justified text and the use of long line lengths can place on many people with reading difficulties? 


Proposed Change: 

I suggest SC 3.1.5 be a Level 2 criterion at the minimum.
Status: open

Comment LC-608
Sort Terms: COGNITIVE Exception for video that is a supplement for cognitive
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com>     Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: media-equiv <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment (including rationale for any proposed change): 

I am concerned that the requirement for real time synchronization put a lot of extra work on authors who would like to provide short animations or clips that help people with learning disabilities fulfill a task. On the whole, a lot of multi media, especially in education, is good for many learning disabilities, and these requirements may act as a step backwards for learning disabilities. 

Proposed Change: 

Make an exception in 1.2 for any content provides extra help visual for tasks and information that has been described in text elsewhere.
Status: open
Working Group Notes: [TEAMA] [HOLD] 
This is a hard one. I remember at CSUN a couple of years ago an organization came and did a demonstration for us during our WG F2F about movies and people with cognitive disabilities. I guess at level 1 it is fine because "real time synchronization is not until Level 2 Captions". 

I don't know how to 

"Make an exception in 1.2 for any content provides extra help visual for tasks and information that has been described in text elsewhere." 

Should I get back to her and ask how she proposes we do that without drawing a blurry line that would allow videos not to caption live material at level 2. How can we construct this exception so as to enable movies intended to help cognitive disabilities, yet forbid uncaptioned movies that are not intended as supplementary information to help cognitively challenged individuals. 

-------------- 
Would like a small team to look into this as a possibility. I think we should try to allow videos for cognitive disabilities that supplement other content. But need to find the distinction between a movie that is supplementing text content and a movie that is just using text content as a transcript and therefore fail level 2 

------------- 

Always dangerous to make an exception for access for one group. What if people are hard of hearing? 


Usually, you do not have to caption if the information is already presented on the same page in text. So if it is video only - you are ok. If it is audio only you are ok. The only exception she needs is if it is audio-visual and the visual is not redundant with the audio. 

What does she have in mind when she says 'add an animation clip'. if not A+V then synch not needed. 

GV sent a note to her asking specifically what she meant. Note read: 
In your comment below you ask for an exception for video that is added to make things clearer for those with cognitive disabilities. 

Usually, you do not have to caption a video if the information is already presented on the same page in text. 
So if you are talking about video only - you are ok. 
If it is audio only you are ok. 
The only problem would be if you adding audio-visual multimedia and the visual is not redundant with the audio. 

What do you have in mind when you say 'add an animation clip'. 
If you really mean just video - and it is an alternate to the text on the page - then you are all set. Not caption or description is required and thus you need no exception. 

Can you give us a more specific example of what you mean? 

Thanks 

Resolution Working Notes - Unapproved:
{partial accept} 
@@Add an advisory technique to 3.1.5 "Supplementing written text with video" 

Response: 

"Thanks for you comment Lisa. We agree that video can help comprehension for people with cognitive issues. In the Guidelines, content that is video only is not considered Multimedia. Therefore, using video-only animations or video-only clips as supplemental material is perfectly acceptable (assuming a *textual* alternative is provided per SC 1.1.1). 

We don't think we should allow for uncaptioned multimedia because captioning is important for many people who are deaf and hard of hearing. However, we have taken your advice and added an advisory technique to 3.1.5 "Supplementing written text with video".

Comment LC-615
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com>     Affiliation: Invited expert at W3C, UB access
Comment Type: general comment
Location: intro <http://www.w3.org/TR/WCAG20/complete.html>  (Introduction)
Comment:
Comment (including rationale for any proposed change): 

The claim in http://www.w3.org/TR/WCAG20/Overview.html learning difficulties, cognitive limitations, 

However the checkpoints towards understandability even at level 3 addresses only secondary education level - in other word usable for mainstream people without these disabilities. The basic mechanism for simplifications have not been included, or use of symbols or conversion to symbols. Also left out are use for controlled languages 

The result: I read a lot of complex specification. I am even writing W3C specifications, but WCAG is the only on that I can not follow though because of my disability. I can understand the concepts, but the presentation requires remembering what technique 3.1.3 was for, and then (if I forgot what 3.2.3 stood for, going back to the original guidelines finding it, hopefully not confusing it with 1..3.2 etc - why because WCAG are following their own specifications, so I, as a person with a disability, can not use their material. 

to say "this document contains principles, guidelines, and success criteria that define and explain the requirements for making Web-based information and applications accessible" and to include learning difficulties, cognitive limitations is an insult to anyone with learning memory or cognitive impairments. there are many clear sets of guidelines that do that. WCAG is not one of them. 

Proposed Change: 

Practical proposal - state clearly that learning difficulties, cognitive limitations are not fully addressed beyond a very limited way. Then work on an extended guideline, be it optional and untestable, success criteria that does the job.
Status: open

Comment LC-620
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com>     Affiliation: Invited expert at W3C, UB access
Comment Type: general comment
Location: intro <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment (including rationale for any proposed change): 

This document contains principles, guidelines, and success criteria that define and explain the requirements for making Web-based information and applications accessible. "Accessible" means usable to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations... 

I am not sure that if pages are fixed to comply to WCAG they will be more accessible to LD 

Proposed Change: 

Change to exclude Learning disabilities.
Status: open

Comment LC-633
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com>     Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: minimize-error <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment (including rationale for any proposed change): 

Most of this (at least at the higher levels) helps blind folks access error information. That is good. Clearly what is missing here is a game plan for helping people with a learning disability , who have trouble filling in forms. 

Forms are real nightmares for a lot of us. In fact I often do not deposit checks and perform other tasks because of the barrier that form filling presents. 

Things that make it harder include short labels that do not explain what they are, coping numbers, Non expandable, small fonts. Too much information on one page. Information not being well grouped such as user information, payment information. Then with the short labels I get confused what is what. Server time outs. Asking a lot of information to make forms simpler to process but make form filling much harder and more complex. 

For example on this form on line it is much simpler (but PF preferred this table .. oh well) .... the options could be in a combo box as filled out meaningfully text... 

Proposed Change: 

Perform user testing with different groups of people with learning disabilities and cognitive limitations - including age related. 

Identify what techniques help 

Add them
Status: open

Comment LC-652
Sort Terms: baseline cognitive LevelAAA
Document: WCAG 2.0 Guidelines
Submitter: Lars Ballieu Christensen <lbc@sensus.dk>     Affiliation: Sensus ApS - European Accessibility Consultants
Comment Type: substantive
Location: 0Free(none selected) <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: GE 
Comment (including rationale for proposed change): 

As a practitioner with 10 years experience in advising site owners and developers on how to develop web sites that are accessible to the widest range of users using the widest range of technologies, I find the following the following issues in WCAG2 highly problematic: 

The introduction of a technology baseline; the concept of a baseline is in my opinion in itself in direct conflict with the idea of creating inclusive solutions; I fear that the baseline will be used widely to formally pass accessibility tests by omitting all potentially tricky technologies from the baseline. In my opinion, the baseline is a mistake that should be removed from the document. If the aim is to promote an inclusive environment, the whole notion of accepting lower standards in, say, private intranets is absurd as it will prevent people with special needs to work in these environments. 

The document is still heavily biased towards the visually impaired. By and large, other groups of people with special needs are in practice omitted from the substance of the guidelines. These include, but are not limited to, the deaf, dyslexic, people with reading difficulties, and the cognitively disabled. The standard remedy of demanding that all non-textual information also be represented as textual information is simply not enough. 

The idea of granting triple-A conformance status to a web site if it passes half (randomly selected?) the level 3 success criteria does not make sense. It suggests either that the level 3 success criteria are irrelevant to the general accessibility or that it is more important to be able to pass the test than to comply with the level 3 success criteria. 

Proposed Change: 

1. Omit the concept of a baseline from the document. 

2. Accommodate other - and in many cases much larger - user groups than merely the visually disabled. Complement the text alternative requirement with requirements for other alternatives including simplified text and sign language. 

3. Decide whether and which of the level 3 success criteria are important. Leave out the unimportant and make the rest mandatory for gaining triple-A conformance status.
Status: open

Comment LC-684
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Bruno von Niman <ANEC_W3CRep_Bruno@vonniman.com>     Affiliation: ANEC (ANEC-ICT-2006-W3C-006)
Comment Type: general comment
Location: 0Free <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment (including rationale for any proposed change): 

Learning disabilities and cognitive limitations are not 
addressed! This may be perceived as usability issues 
but we believe the consumer should not have to 
know the difference between usability and accessibi- 
lity! Older consumers, a numerous part of the EU 
population, will face severe problems! 

Proposed Change: 

Should be covered by the WCAG 2.0 documents. 
Otherwise, the opposite must be explicitly claimed, 
to avoid misunderstandings. 
Another option would be to continue work on a set of 
extension guidelines to address these needs.
Status: open

Comment LC-865
Sort Terms: Text-Alternatives cognitive
Document: WCAG 2.0 Guidelines
Submitter: lisa seeman <lisa@ubaccess.com>     Affiliation: UB access
Comment Type: substantive
Location: text-equiv-all <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: substantive 
Comment (including rationale for proposed change): 

text equivalents for struggling students and people with LD are often of a very different natures to the SC described. 
They would typically not have all included text, point out the key detail that someone is needs to understand 
Alt tags are often verbose, such as explaining or giving a sentence of context to a diagram. We often have multiple prodnotes (using HTMl with Daisy XML as a base) for a single picture often linked to different regions 

descriptive alt tags would be omitted - they would just confuse the user who we are trying to help identify key content and concepts. 

Would such a page be conformant? 

note there are many more people with these needs then who are blind. And blind users are getting all the key information anyway. 
Also note: 
Alt tags and prodnotes are a great way to put info in a page for LD without changing the general use 

Proposed Change: 

create an alternative SC set for pages for people with LD.
Status: open
Working Group Notes: [TEAMC] [HOLD] 

There seems to be contradictory information here: 

"descriptive alt tags would be omitted - the would just confuse the user who we are trying to help identify key content and concepts." 
"Alt tags and prodnotes are a great way to put info in a page for LD without changing the general use" 

Commenter seems to asking for a set of guidelines for Web pages that are specifically targeted at audiences with learning disabilities. Does this mean there are conflicts in what our guidelines recommend and what users with LD need?
Resolution Working Notes - Unapproved:
{reject} 

Our job is to create a set of guidelines that, except at Level 3, can be universally applied to most websites. We can put provisions in at Level 3 that would only be applicable to some websites but these provisions are required in addition to, not instead of, the ones at Level 1 and 2. If alt tags truly are not needed in order for blind users to get the information, then the non-text content is decorative and the alt attribute should be null anyway. 

Comment LC-877
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: lisa seeman <lisa@ubaccess.com>     Affiliation: UB access
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: general comment 
Comment (including rationale for proposed change): 

I think WCAG itself (agendas forms etc) need to be more usable for people with Cognitive Impairments like impaired short term /visual / auditory memory 

If we can not make our own system usable then people with these impairments can not comment and affect the guidelines 

It also clearly shows a lack of understanding of how to make content accessible for people with LD and Cognitive limitations 


As a side note I have participated in a few W3C groups and I find WCAG the hardest for people with LD to participate in. 

If anyone thinks I am unable to understand the concepts they should refer to http://www.w3.org/WAI/PF/GUI/roleTaxonomy-20060508.html 

It is the presentation that makes it inaccessible not the content 


Proposed Change:
Status: open


Comment LC-946
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: M.F. Laughton <adio@crc.ca>     Affiliation: Government of Canada
Comment Type: substantive
Location: meaning <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
The document lacks any reference to dealing with "unusual user interface features or behaviours" that are likely to confuse the first-time/novice user. We feel that such should be described to the user before they are encountered. 

Proposed Change: 

Add a level 3 (at least) success criterion - perhaps to Guideline 3.1 - requiring that "Explain/describe/warn about the existence of unusual user interface features or behaviours before they are encountered.
Status: open
Working Group Notes: [TEAMB] [HOLD] 
SC? advisory technique? 
[SM] Is this covered under Guideline 2.4 "Provide mechanisms to help users find content, orient themselves within it, and navigate through it" and also Guideline 3.2 "Make the placement and functionality of content predictable." 
The condition "unusual" is a subjective and therefore immeasurable state. It would be difficult to define what "unusual" is. This type of scenario is described in the Guidelines as "unexpected". 

LGR (Aug 3): "first time/novice user" makes this sound like a usability issue rather than an accessibility issue. However, there may be implications for some cognitive disabilities. Adding cognitive sort term and putting on hold. 
Resolution Working Notes - Unapproved:
@@ Reject. 

@@ 
Response to Commentor: The condition "unusual" is a subjective and therefore immeasurable state. It would be difficult to define what "unusual" is. This type of scenario is described in the Guidelines as "predictable" behaviour and is covered under Guideline 3.2 "Make the placement and functionality of content predictable." It is further supplemented by Guideline 2.4 "Provide mechanisms to help users find content, orient themselves within it, and navigate through it". 
The team considers these Guidelines to be sufficient for this scenario.

Comment LC-1021
Sort Terms: accum resp - COGNITIVE set up a task force (i volunteer)
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Cognitive disabilities - People with cognitive disabilities are unfairly discriminated against within WCAG2. I believe this is due to the usability and testability requirements. It is generally accepted (and one chair has said so explicitly) that requirements that assist people with cognitive disabilities are often general usability techniques. Criteria that assist people with cognitive disabilities is more likely to fall foul of the requirement for testability than other criteria, simply because these criteria recommend changes to the way content is written, not how a site is coded. For example, in WCAG1 Checkpoint 14.1 - Use the clearest and simplest language appropriate for a site's content - still has no clear equivalent in WCAG2 and partially maps to Level 3success criteria. 

Proposed Change: 

Set up a specific taskforce within WCAG WG to identify success criteria that should be added to ensure WCAG2 addresses the needs of people with cognitive disabilities (I volunteer to be a part of, or to head up, this taskforce), or comply with Lisa Seeman's suggestions in her formal objection (which I have cosigned)
Status: open

Comment LC-1036
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com>
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
WCAG 2.0 claims to define and address the requirements for making Web content accessible to those with learning difficulties, cognitive limitations and others. We object to that claim. 

Specifically, the success criteria requirements for making content understandable largely ignore the needs of people with learning difficulties and cognitive limitations. Please note that there are guidelines published by other groups that will make content much more accessible to these users. However, with the WCAG claim to address learning difficulties and cognitive limitations, people will not know that they need to look further. 

We would like to see continued work in this field and a statement in the WCAG 2.0 abstract and introduction modifying the claim that they currently address accessibility for learning disabilities. Specifically, we recommend removing learning difficulties and cognitive limitations from the list of supported disabilities. A sentence may be added later in the abstract that "these guidelines may also provide some benefits for people with learning difficulties and cognitive limitations". We would then like to see a statement of intent such as: "the working group intends to build additional success criteria to address accessibility for learning disabilities and cognitive limitations." 


All the best, 

Lisa Seeman, www.ubaccess.com 
Jonathan Chetwynd, Accessible Solutions 
Andy Heath, Axelrod Research and Computing 
Gez Lemon, www.juicystudio.com 
Roberto Scano 
Gian Sampson-Wild 
Dr. Andy Judson 
Yvette Hoitink 
Marc Walraven 
Fred Heddell MBE, Inclusion International 
Mrs. Zoe Apostolopoulou e-ISOTIS 
Andrew Arch Vision Australia 
Sofia Celic Vision Australia 
Keith Smith, BILD (British Institute of Learning Disabilities) 
Peter Rainger 
Erlend Øverby 
William Loughborough 
Geert Freyhoff Inclusion Europe 
Better Days advocacy group 
Mencap Accessibility Unit 
The Rix Centre (for Innovation and Learning disability) 
Antonia Hyde, United Response 
Diane Lightfoot, United Response 
Jo Kidd, The Skillnet Group 
Dan Edney The Skillnet Group 
United Response (UR) 
Liddy Nevile, La Trobe University 
Andy Minnion, The Rix Centre 
Simon Evans, The Rix Centre 
Jim Byrne, GAWDS 
Mel Pedley 
Pamela E Berman 
Caroline Lambie, Mencap Web Communications Manager. 
Andrew Holman, Inspired Services 
Robert Hubbert, Ubisan 
John Nissen, Cloudworld Ltd 
Paul Williams 
Roger Hudson 
Janine Ness 
Zoe Porter, Valuing People 
Sue Carmichael, Valuing People 
Geoff Stead 
David Sloan, Digital Media Access Group 
Simon Cramp 
Ann Fergusson 
Dr. Robin Boast 
Matthew Smith 
Neel Shearer, CALL (Communication Aids for Language and Learning) Centre 
Paul Brown, The Scottish Disability Team 
Jim Ley 
Sally Cooper 
TechDis 
Katarina Mühlenbock, Dart 
Emmanuelle Gutiérrez y Restrepo, Sidar 
Mats Lundälv Dart 
Sari Follansbee 
Sarah Riley 
Sally Paveley, Advisory Unit
Status: open
Working Group Notes: [EDITORZ] [HOLD] 

Note: Formal objection explained 
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0119.html 

Comment LC-1057
Sort Terms: Errors Cognitive
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: minimize-error <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
2.5: There should be a Level 1 SC which requires error prevention techniques, such as providing instructions at the beginning of a form 

Proposed Change: 

Create a new SC. I am happy to help with this
Status: open
Working Group Notes: [TEAMC] [HOLD] 

Requiring instructions on forms is a design change to the visual layout of Web content which doesn't meet our criteria for Level 1. 

Alternative 1: 

We could add a Level 2 SC but it would have to be general, something like "A mechanism is provided to help users prevent making errors." We tried in vain to create more specific success criteria. Remember all the discussions about our choice of 75 in this 2.5 Level 3 Success Criteria from 2004: "Where text entry is required for which there is a known set of less than 75 valid choices and they can be provided without jeopardizing security or purpose, users are allowed to select from a list of options as well as to type the data directly." 

Sufficient techniques in support of this SC could be: 
- Providing instructions at the beginning of forms 
- Providing a list of selectable choices 
- Providing examples of expected format 

I still think this might be too much to require at Level 2. What if the form is really simple? So we could add a Level 3 success criteria but I don't think that would satisfy Gian. 

It does seem kind of odd that we have a guideline that says "Help users avoid mistakes... " yet we have nothing at level 1 or 2 to meet it. 

Alternative 2: 

Maybe we should instead propose rewriting this guideline to "Make it easy for users to correct mistakes." 

Discussed in the 14 September 2006 telecon: 
resolution: Return 1057 to team C. Put the results of the survey into the issue; draft a proposal based on the survey results; also tag the issue as "cognitive" and put on hold. 
Survey Comments: http://www.w3.org/2002/09/wbs/35422/20060914-teamc/results#x1057 <http://www.w3.org/2002/09/wbs/35422/20060914-teamc/results>  
http://www.w3.org/WAI/GL/2006/09/14-wai-wcag-minutes.html

Comment LC-1124
Sort Terms: cognitive
Document: Understanding WCAG 2.0
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: editorial
Location: meaning-doc-lang-id <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>  (Benefits)
Comment:
Benefits: These SC do not assist people with cognitive disabilities 

Proposed Change: 

Remove from the Benefits section that these SC assist people with cogntive disabilities
Status: open
Working Group Notes: [TEAMB][HOLD] 
LGR - note that these SC are useful to providing automatic look-up of definitions, translations, etc. as technology improves.

Comment LC-1153
Sort Terms: COGNITIVE
Document: WCAG 2.0 Guidelines
Submitter: Greg Lowney <gcl-0039@access-research.org>     Affiliation: Lowney Access Research, LLC
Comment Type: substantive
Location: conformance-claims <http://www.w3.org/TR/WCAG20/complete.html>  (Examples)
Comment:
The example conformance claims list things like jpeg as 'specifications that this content "relies upon"'. How can jpeg ever be a relied upon specification since the guidelines require Web pages to be usable even when the images are turned off? 

Proposed Change: 

Remove JPEG from list of "specifications that this content relies upon", or else clarify what is meant by including it.
Status: open
Working Group Notes: [TEAMA] [HOLD] Holding to be sure we do not re-introduce something like this in guidelines where images can be used to meet a success criterion. 
Resolution Working Notes - Unapproved:
{accept} 
Relies upon means that it is necessary in order to conform. This one was left over from when there was a SC that could be met by providing supplemental graphics as away to conform. In that case an image format would be needed (relied upon) in order to conform. Since that has been removed, there is no place where a person would rely upon images to conform. So jpg will be removed. 

Comment LC-1253
Sort Terms: font cognitive
Document: WCAG 2.0 Guidelines
Submitter: Henny Swan <henny.swan@rnib.org.uk>     Affiliation: Royal National Institute of the Blind
Comment Type: substantive
Location: meaning <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment: No mention is made of presentation of text i.e. left aligned vs. justified/right aligned text, long lines, multiple columns, overuse of different styles etc. 

Proposed Change: 

Add in.
Status: open
Working Group Notes: [TEAMB] 
LGR: http://www.cjlt.ca/content/vol28.1/mcmullin_etal.html indicates that line length is not significant for understanding, although surrounding white space is. 

See also "Is Multiple-Column Online Text Better? It Depends!" http://psychology.wichita.edu/surl/usabilitynews/72/columns.htm 

"What is the optimal line length when reading 
prose text from a monitor?" http://www.keller.com/articles/UIDesignNov2002.txt 

{SM] Would this be covered under "Principle 1: Content must be perceivable: Guideline 1.3 Ensure that information and structure can be separated from presentation: 1.3.5 Information required to understand and operate content does not rely on shape, size, visual location, or orientation of components. [How to meet 1.3.5] " 

Aug 14, Clarification from commenter: 
Hi Lorretta, 

Really what I am wondering is if there should be a mention of how text 
is presented as this is important to most if not all users as poorly 
presented text can be really problematic to read. There is no specific 
mention in WCAG 1.0 and I have found that on some sites that we audit 
there is a need for a checkpoint on how text is presented. 

The issues that need to be addressed are: 

- avoiding centrally aligned text 
- avoiding justified text 
- avoiding chunks of italic text 
- avoiding overuse of different styles on individual pages and in sites 

The guideline could read something along the lines of "Ensure text is 
easy to read" and the success criteria could then specifically address 
each issue i.e.: 

- paragraphs of text are not justified or centrally aligned 
- paragraphs of text are not italicised 
- text styles are used to back up structural change only (i.e. styles 
are used for headings etc to help the user differentiate different types of content) 

This is obviously a guideline that would also very much help users with cognitive and reading problems as well. 

Does that help clarify the issue? 

Henny 
Resolution Working Notes - Unapproved:
@@Partial Accept 

@@ Response to Commenter: 
The working group believed that this scenario is covered under "Principle 1: Content must be perceivable: Guideline 1.3 Ensure that information and structure can be separated from presentation." In particular SC 1.3.5 "Information required to understand and operate content does not rely on shape, size, visual location, or orientation of components."

Comment LC-1255
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Henny Swan <henny.swan@rnib.org.uk>     Affiliation: Royal National Institute of the Blind
Comment Type: substantive
Location: meaning <http://www.w3.org/TR/WCAG20/complete.html>  (Success Criteria)
Comment:
Comment: WCAG1 14.1 is not represented in this guideline or any other. This is quite a major omission and one that is important for not only users with cognitive and reading problems but also browsing in a second language; a strange omission given W3C's Internationalisation WG. 

Proposed Change: 

Add in
Status: open

Comment LC-1258
Sort Terms: COGNITIVE
Document: WCAG 2.0 Guidelines
Submitter: Henny Swan <henny.swan@rnib.org.uk>     Affiliation: Royal National Institute of the Blind
Comment Type: general comment
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Comment: WCAG1, checkpoint is not reflected in WCAG 2. The WCAG 2 checklist states that this is because it is reflected in the techniques rather than the Success Criteria which are normative. Can be argued that 14.2 is as important to people with cognitive problems as 1.1 and alt text are to VI users. In WCAG one the former was a P3 that later a P1. It may be that because it is not testable that 14.2 hasn't carried over into WCAG 2 but it shouldn't be excluded because it is not testable as it is still a fundamental guideline for this user group. In the Introduction it states that WCAG2 is for people with cognitive and learning problems so therefore this checkpoint should be in WCAG 2.
Status: open

Comment LC-1279
Sort Terms: cognitive introduction
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org>     Affiliation: Vision Australia
Comment Type: substantive
Location: intro <http://www.w3.org/TR/WCAG20/complete.html>  (Opening)
Comment:
Comment: para 1 says that WCAG 2.0 makes web content available to a wide range of disabilities, including "blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others". It seems that learning difficulties and cognitive limitations are not addressed to any significant extent, in fact even less than WCAG 1.0. It seems the emphasis is even more on 'blindness and low vision' and 'limited movement'. This may be because the strong move to testability, but given that this is the case, then lets not kid everyone (or no-one) that WCAG 2.0 address all disabilities. 

Proposed Change: 

change wording to leave these out at this stage. Seriously consider the next task for the working group to be to properly address the needs of these groups with supplement or addenda to WCAG 2.0 (or release as a WCAG 2.1)
Status: open

Comment LC-1309
Sort Terms: cognitive LevelAAA conformance
Document: WCAG 2.0 Guidelines
Submitter: Charles McCathieNevile <chaals@opera.com>
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
The guidelines place in level 3 very many of the requirements necessary to 
help people with cognitive and reading disabilities access the web. Since 
only 50% of level 3 requirements (as chosen by content authors) need to be 
met in order to claim conformance to the guidelines, it is quite possible 
to conform to the guidelines at triple-A level while doing very little 
(and clearly not enough) to address the needs of these user groups. 

I propose either that this be explicitly and clearly explained in the 
introductory and conformance sections, or that the levels system be 
reworked as per my last call comment on them. 

cheers 

Chaals
Status: open

Comment LC-1408
Sort Terms: COGNITIVE
Document: WCAG 2.0 Guidelines
Submitter: British Standards Instution, London, UK <>     Affiliation: British Standards Instution, London, UK
Comment Type: substantive
Location:  <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
1. Addressing Cognitive and Learning Disability 

WCAG 2.0 claims to define and address the requirements for making Web content accessible to those with learning difficulties, cognitive limitations and others. We do not accept that claim. 

Specifically, the success criteria requirements for making content understandable largely ignore the needs of people with learning difficulties and cognitive limitations. Please note that there are guidelines published by other groups that will make content much more accessible to these users. However, with the WCAG claim to address learning difficulties and cognitive limitations, people will not know that they need to look further. 

We would like to see continued work in this field and a statement in the WCAG 2.0 abstract and introduction modifying the claim that they currently address accessibility for learning disabilities. Specifically, we recommend removing learning difficulties and cognitive limitations from the list of supported disabilities. A sentence may be added later in the abstract that \"these guidelines may also provide some benefits for people with learning difficulties and cognitive limitations\". We would then like to see a statement of intent such as: \"the working group intends to build additional success criteria to address accessibility for learning disabilities and cognitive limitations.\"
Status: open
Related Issues: 
878 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=878>  
IS <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=IS>  
PARENT <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=PARENT> 


Closed Issues
Comment LC-543
Sort Terms: cognitive
Document: WCAG 2.0 Guidelines
Submitter: Greg Gay <g.gay@utoronto.ca>     Affiliation: ATRC UofT
Comment Type: question
Location: meaning-pronunciation <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Item Number: Success Criterion 3.1.6 
Part of Item: 
Comment Type: QU 
Comment (Including rationale for any proposed change): 

Is guideline 3.1.6 relevant to alphabetic languages. I was unable to determine the meaning of this guideline as it applies to English, or other alphabetic languages. If it is relevant to alphabetic languages, examples should be provided, or it should be stated that it applies to syllabic, or orthographic languages. 

Proposed Change:
Status: Resolved (resolved_yes).
Response Status: Resolution implemented
Working Group Notes: [TEAMB] 

The language elements that this SC deals with include "Heteronym" and "Capitonyms" (a simple explanation of these can be found at http://en.wikipedia.org/wiki/Homophone). The following are borrowed from this Wikipedia explanation; Heteronyms (also sometimes called heterophones) are words that are spelled the same but have different pronunciations and meanings. An example of Heteronym is "desert (abandon) and desert (arid region) are heteronyms (pronounced differently). 
Capitonyms are words that are spelled the same but have different meanings when capitalised (and may or may not have different pronunciations) - for example, polish (to make shiny) and Polish (from Poland). 

Discussed 29 June 2006 
resolution: accept 543 as currently written 
http://www.w3.org/2006/06/29-wai-wcag-minutes.html 

OUTCOME from July 29 Full WCAG Discussion: Accept, but, Make sure that the response includes the content of the action item that will be done. 

DONE Add the examples to the "Intent of this success criterion" section of "How to Meet 3.1.6". As follows: 
"For example, in the English language heteronyms are words that are spelled the same but have different pronunciations and meanings, such as the words desert (abandon) and desert (arid region). Additionally, in some languages certain characters can be pronounced in different ways. In Japanese, for example, there are characters like Han characters(Kanji) which have multiple pronunciations. Screen readers may speak the characters incorrectly without the information on pronunciation. When read incorrectly, the content will not make sense to users." 

XML updated 04 August.
Resolution - Pending Response:
Guideline 3.1.6 is indeed relevant to alphabetic languages. Examples have been added to the "Intent of this success criterion" section of "How to Meet 3.1.6" to illustrate this. The revised section reads as follows: 

"For example, in the English language heteronyms are words that are spelled the same but have different pronunciations and meanings, such as the words desert (abandon) and desert (arid region). Additionally, in some languages certain characters can be pronounced in different ways. In Japanese, for example, there are characters like Han characters(Kanji) which have multiple pronunciations. Screen readers may speak the characters incorrectly without the information on pronunciation. When read incorrectly, the content will not make sense to users."

Comment LC-720
Sort Terms: COGNITIVE
Document: WCAG 2.0 Guidelines
Submitter: Robert C. Baker <<Robert.C.Baker@ssa.gov>>     Affiliation: Social Security Administration
Comment Type: substantive
Location: meaning <http://www.w3.org/TR/WCAG20/complete.html>  
Comment:
Part of Item: 
Comment Type: TE 
Comment (including rationale for proposed change): 

(See LC 681 for complete submission) 

The guidelines do not address the following: 

§Guidelines for creating HTML documentation and Help must be stated and Help using navigational techniques must also be documented for accessibility. 


Proposed Change:
Status: Resolved (resolved_no).
Response Status: Response drafted
Working Group Notes: [TEAMB] 

SENT FOR CLARIFICATION 
* Do not understand this one. If the documentation is on the Web, it is covered by the guidelines. For the last part are you just saying that there must be a help file on each page that says how to navigate that page? Can you explain more and give us an example of what you think should be on each web page? 

CLARIFICATION RECEIVED 

SSA has found that vendors supplying documentation for products do not have a clear understanding of what is required for accessible electronic documentation. Often documentation is supplied in PDF format and is determined to be not accessible. Vendors will then just convert to HTML and think they are done with it. It is likely that the WCAG guidelines do cover documentation and Help facilities but it is felt that a separate section dedicated to Help and documentation would help to clarify this situation. 

Documentation and Help can be presented in many formats. These include straight text, a Microsoft or RoboHelp type Help facility with frames such as Content, Index and Search, an interactive documentation capability where there is a table of contents and the user is able to move around a document and finally links to context sensitive Help on the same HTML page. The issues that are involved include: 

Equivalent alt text for images 

Ability to move automatically to a content frame when a link is selected from a different frame 

Elimination of A-Z links for index as it requires significant keyboarding to be replaced by drop downs 

Selection of objects moving directly to the object of the selection and therefore a change in focal point 

Ability to move back to original focus when a Help link is selected 

HTML capability to select context sensitive help for a field through keystrokes 

Discussed in the 24 August 2006 telecon: 
Resolution: accept 720 as amended 
http://www.w3.org/WAI/GL/2006/08/24-wai-wcag-minutes.htm 

{reject}
Resolution - Pending Response:
We agree that Help and documentation that is available *on the web* is web content and hence that it should conform to these Guidelines. Note that although the same issues appear for documentation and Help files for desktop applications, these guidelines do not address that content. However, we feel that attempting to single out specific examples of Web content is likely to lead people to believe that only the listed examples are covered. 
Related Issues: 
LC-681 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=LC-681> 


Loretta Guarino Reid
lguarino@adobe.com
Adobe Systems, Acrobat Engineering