- From: Loretta Guarino Reid <lguarino@adobe.com>
- Date: Fri, 20 Oct 2006 14:12:29 -0700
- To: <public-wcag-teamb@w3.org>, <public-wcag-teamc@w3.org>, <public-wcag-teama@w3.org>
- Message-ID: <EDC8DDD212FEB34C884CBB0EE8EC2D910282E7C9@namailgen.corp.adobe.com>
"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
Received on Friday, 20 October 2006 21:13:11 UTC