Post WCAG 2 Issues Sorted
This page is for the collection and initial categorization and review of items that the group may consider for future work. The items initially entered came from the Post WCAG 2.0 wiki page.
The columns are as follows:
- Assigned to: Individuals agreeing to review the issue
- Row: Row number
- Issue: A (hopefully) concise description of what the issue or concern is
- Category: Categories are somewhat in flux, but "mobile", "cognitive", and "low-vision" are proposed categories.
- Possible or proposed solution: What is the fix for this issue?
- Changes or extends WCAG 2.0?: The answer here is "Changes" or "Extends". We need to know if extension work will modify the current success criteria or add to them.
- Impacts fallback?: If we required this solution in an extension, would a page conforming to WCAG 2.0 and the extension still meet WCAG 2.0 on its own? This column should be answered "yes" if a page would pass WCAG 2.0 if the extension was not part of the conformance claim and "no" if it wouldn't. For example, if SC 1.4.3 was changed from AA to A in an extension, the page would still meet WCAG 2.0 even if the extension wasn't referenced because the extension is more strict. If 1.4.3 was moved to AAA in an extension (just an example, don't worry, no one is proposing this!) then the page wouldn't meet WCAG 2.0 on its own.
- What should WCAG do?: How WCAG WG will act on the issue. 'Not sure' or 'Nothing' are legit answers.
| Assigned to | Row | Issue | Category | Possible or proposed solution | Changes or extends WCAG 2.0? | Impacts fallback? | What should WCAG do? |
|---|---|---|---|---|---|---|---|
| David MacD; cstrobbe; KW | 1 | Any resource that is not described with metadata must be accessed in order to discover what it is about and how it works and can be accessed. This places a burden on users at selection time, if it is being accessed other than because it is already known to be what the user wants, and so it makes access to the resource less flexible and potentially distracting (as is the case when it is not what the user wants but they have had to retrieve it to discover this). Source | Cognitive | David: This comment goes back to 2007. It does not appear that any AT has begun to support metadata in the 8 years since the comment. There has been discussion about MetaData in general around the W3C, but not about metadata for an accessible version on an inaccessible page. Given the lack of momentum, lack of technology, and lack of discussion, I don't think we should take this into an extension. The reasons given by the WG for not taking it on in 2007 still hold true. Otherwise, there may be some momentum behind better use of Metadata in the future, at which time we could revisit this. | Extends | No | Suggest we move to Cognitive task force. |
| David MacD; KW | 2 | When the means of accessibility is not a static, conformant page but rather a dynamic compilation of components, as is common with Web 2.0, and as may be achieved by a service that provides resources to match a user's personal needs and preferences (using components that in themselves and in isolation may not be fully conformant), without appropriate metadata, the service agent can not know what components to compile to suit the user. In this case, such a service that potentially provides a higher than usual form of accessibility would be denied. It seems odd to allow this situation to exist. Source | Cognitive | David: This is from 2007. It does not appear that any AT has begun to support metadata in the 8 years since the comment. There has been discussion about MetaData in general around the W3C, but not about metadata for components, so that they can be included or dropped from an accessibility report based on their audience. Personalization is becoming popular, but my understanding is that the winning vehicle is cookies rather than metatags. Given the lack of momentum, lack of technology, and lack of discussion, I don't think we should take this into an extension. The reasons given by the WG for not taking it on in 2007 still hold true. Otherwise, there may be some momentum behind better use of Metadata in the future, at which time we could revisit this. | Extends | No | Suggest we move to Cognitive task force. |
| David MacD; KW | 3 | On 30 September 2010 we discussed the question of a survey that pops up after a delay when a page loads. This was determined to be a failure of 3.2.5 Change on Request and 2.2.4 Interruptions, both AAA. It was considered almost but not quite a failure of 3.2.1 On Focus (which is Level A). The feeling is that it should be a failure at AA, but the SC as they exist didn't cover the situation. Two issues need to be more clearly addressed in the future: Should loading of a page be covered by the same provisions that 3.2.5 has for focusing a component? A change of context that happens after a timeout creates a greater problem with respect to interruptions and disorientation than a change of context that happens immediately, yet appears to be permitted as a loophole because the wording of the SC is specific to changes that happen immediately. |
Blindness, Cognitive, Keyboard Only | David: A popup after about 15 seconds for instance is a change of context. The user has started reading the page and the context changes. I don't see a limitation in 3.2.5 on "immediate" changes that would allow this to pass. I think it fails 3.2.5 AAA. However it is relegated to AAA. We didn't consider this type of issue while authoring WCAG because it was not common. Now many newspaper sites etc., do this. Therefore, I think we could need to address it. | Extends | No | consider a new SC criteria for WCAG.NEXT that would address this at a the AA level. It could also address changes to the DOM that are not "progressive disclosure" (i.e., a button saying "Do you have children" which inserts fields for kids names *prior* to the button in the DOM.) The Success Criteria could be something like: "All changes to the content initiated by a control, follow that control in the reading sequence, or the user is notified of the new content with instructions on (or before) the control. There is notification of automatic or timed changes of context, and a mechanism to stop such changes of context before they occur." |
| David MacD; KW | 4 | Focus order vs programmatically determined reading order vs visual presentation order; | - Keyboard Only User | - David: The comment is looking to move 2.4.7 (Focus visible) to Level A because it is part of keyboard accessibility and 2.1.1 (Keyboard) is Level A. However, 2.4.7 is for sighted keyboard users, some of whom may have software that overrides the focus removal. (Personally, in 17 years of accommodations, I have yet to meet a sighted keyboard *only* user who doesn't use mousekeys as part of their strategy.) Even if their are an abundance which I have not met, I think the AA status is justified because a failure does not result in the same level of impact as keyboard use. It is certainly a *very* common failure of WCAG these days. | Extends | No | Take no further action |
| David MacD; KW | 5 | what keyboard users want/expect from initial focus placement source | Keyboard users, and those who are blind | The comment actually doesn't talk about initial placement of focus. But it is an issue some are concerned about so I will make a few comments. There is a lively discussion about this on the IG | Extends | No | Introduce a new SC which says something like. "Initial focus is not managed by the author, unless the element that receives initial focus is the purpose of the page. (i.e., a video page that places focus on the play button, or a Search engine that places focus in the search field)" |
| Louis Cheng; Kenny Zhang | 6 | strategies and standards for navigating around a page in ways other than tabbing through all controls | Keyboard (Navigable) | Kenny: It's not pointed out the source, I'm not sure who/when asked this issue, looks WCAG guideline 2.4 focuses on navigate mechanism that could solve parts of this issue, but lack of details for "navigating around a page in ways" | Extends | No | - |
| Louis Cheng; Kenny Zhang | 7 | possible standards and conventions for keyboard access | Keyboard (Navigable) | Kenny: WCAG's guideline 2.1 and guideline 2.4 enough to explain the issue | Changes | No | - |
| Louis Cheng | 8 | User Agent and AT support that is needed to improve keyboard experience for HTML | Keyboard (Navigable) | This seems more related to implementation and not in WCAG scope | Doesn't Extend | No | Take no further action |
| Louis Cheng; Kenny Zhang | 9 | modification of font-family based on element (tag) type Sources: 1, 2, 3 | low vision; dyslexia | Kenny: WCAG SC 1.3.1/1.4.3/1.4.4/1.4.5/1.4.6/1.4.8/1.4.9 relates to this issue, another hand that also should be fitted into UAAG guideline 1.4 | Changes | No | - |
| Louis Cheng; Kenny Zhang | 10 | enlargement of letter, word and line spacing for text. Sources: 1, 2 | low vision; dyslexia | Kenny: Same issue with last item | Changes | No | - |
| AWK, Laura Carlson | 11 | variable enlargement linked to element type Sources: 1, 2 | low-vision | AWK: Perhaps the simplest approach would be to adopt the text from 1.4.2 in UAAG 2.0 (http://www.w3.org/TR/UAAG20/#sc_142). Would this included 1.4.1 and 1.4.3 also? Item 15 below discusses the idea of adjusting link hover coloring, but would adopting 1.4.2 eliminate that as a possible need? Laura: Yes. UAAG's 1.4.2 seems to be an appropriate solution. Maybe explicitly mention hover so that fixes #15 too. To be thorough I'd suggest including 1.4.1 (Level A) and 1.4.3 (Level AA) | Extends | No | Laura: Adopt the text from 1.4.2 in UAAG 2.0 (http://www.w3.org/TR/UAAG20/#sc_142) and maybe 1.4.1 and 1.4.3 too. |
| AWK, Laura Carlson | 12 | If a user action causes new content to be added, especially outside the user's current viewport, the user needs to know both that the content changed and where the changes are located. This is particularly an issue for blind users when content is added before the current location. Screen reader users read down a page not generally up, so information that is inserted ABOVE the control might be missed. ARIA live regions may be a solution to this in some situations. situations. Source | Cognitive, Low-vision (other?) | AWK: This might fit into guideline 3.2 (predicable: make web pages appear and operate in predictable ways) but could also be considered under Principle 1 (perceivable) – I’m leaning toward the latter. In either case, the argument is that content needs to be offered in a way that makes it possible for end users to be aware that the new content is added. Possible language might be along the lines of: Dynamic Content: Dynamic content changes on a web page must be added in a manner that users can detect. Also covered for controls with 4.1.2. Laura: Agreed. Principle 1 would be a good fit. A related item (F69) is: one of the most important functional needs for screen magnifier users is to have well-placed calls to action in content that is not dynamic as it is very easy to loose context. We have found that out in recent usability testing with students with disabilities. Also Derek Featherstone has evangelized this with his straw test (youtube) | Extends | No | Laura: Adopt AWK's suggested verbiage: "Dynamic content changes on a web page must be added in a manner that users can detect." |
| AWK, Laura Carlson | 13 | We have been collecting current and emerging Captcha techniques and alternatives. It is a terrible problem and we haven't solved it yet. We need to work on this. | Cognitive, Vision (other?) | AWK: It seems that the most impactful thing that we might be able to do would be to be more specific about CAPTCHA. We aren’t going to be able to forbid CAPTCHA, but we can be more clear that when CAPTCHA is used that the collection of CAPTCHA alternatives need to meet all WCAG SC in aggregate to cover as many users as possible. Laura: Pragmatically, that may be the best WCAG can do. I updated the current and emerging Captcha techniques and alternatives Wiki page by adding a new row for Google's latest "No CAPTCHA ReCaptcha Reboot" and related references and testing (December 2014 and May 2015). | Extends | No | Laura: Try to be more specific about CAPTCHA. We should coordinated with PF (APA) as they have an "Inaccessibility of CAPTCHA Note" as a deliverable in their draft charter. |
| AWK, Laura Carlson | 14 | As discussed by the working group on February 18, 2014 we want to discuss the possibility of raising Success Criterion 1.4.3 Contrast (Minimum) from it's current location at Level AA - up to Level A. Many working group members feel that due to the mobile paradigm of web content today that this Success Criterion would make more sense being at Level A, and would help address significant readability issues that could be found on Level A conforming sites. See also comments from an article by Jared Smith (WebAim) supporting this idea. |
Low-vision | AWK: Promote 1.4.3 from AA to A. Laura: This may be the simplest and an effective solution. In any event, some sort of Level A SC is needed. (Jared made a keen observation: WCAG shouldn't allow white text on a white background to be Level A conformant.) | Changes | No | Laura: Unsure. Per Michael at the June 2, 2015 WG meeting. "There was not contrast requirement at the A level since it doesn't have requirements that can be managed with 'machine help.' If we change, we need to explain why this approach would be different." Per James: "may not want to fail white on white text since that could be a technique to hide text."
|
| AWK, Laura Carlson | 15 | As discussed by the working group on February 18, 2014 we want to discuss the possibility of updating the Understanding document to address hover and link text states and whether they are applicable to the color-contrast ratio of the Contrast requirements (1.4.3 and 1.4.7). At the time of Makoto's comment Gregg V. felt that the current language did not cover this circumstance. I, Katie Haritos-Shea, disagree with our response that this is a usability issue and I believe it should fall under 1.4.3/1.4.7 - and I hope that we revisit this issue to update the Understanding document when we can. See LC-2893 | Low-vision (Cognitive?) | AWK: I still don't think that this is covered by the current SC, and it isn't clear to what extent this is an actual issue for users. Further, if the comment in Row 11 is addressed as described, is this one taken care of by that? I'd need to know more about how impactful this type of modification would be before committing to the change. Laura: I have witnessed hover contrast issues with low vision students when hover alone was used to convey information without a static on-screen text link as in a case where icons were links. Anyway, it may be good to cover it under row 11 if possible. (Related issue: when ZoomText is used, hover content is often obscured by the larger mouse pointer, making it inaccessible.) | Extend | No | Laura: Unsure. |
| Marc J, Moe K | 16 | There is a need for clarification on color contrast in icons. Discussed in LC-2762 on June 25, 2013 WG meeting | Low vision | MEK: This is tricky while we would need to consider icon size and number of colors used. 1 or 2 colors could work.
- Recommendation: Important icons with 2 colors should meet a minimum contrast of 3:1 between their foreground and background color. Important transparent icons with only 1 color should meet a minimum contrast of 3:1 ratio with its background. - MKJ: Agree with Moe - but I also want to be sure that we are calling out contrast between the icon itself and the page background - not just contrast issues inside the icon itself. I believe this can be handled by simply adding "icons" to the SC of 1.4.3 "The visual presentation of text, images of text, @@and icons replacing text@@, has a contrast ratio of at least 4.5:1, except for the following: (Level AA)" etc |
Extends 2.0 | Yes | - |
| Marc J, Moe K | 17 | There is a need for some clarification in the area of captions. A comment was raised [1] which inquires about what language captions need to be provided if there is an English video on a Japanese site. The consensus is that captions need to be in English if the audio is in English, but there is a possibility that end-users who speak only Japanese and are deaf/HOH may miss key information that isn't currently required in situations where the video includes non-spoken information. The video is likely to be subtitled in Japanese, but unless the non-spoken information is included in the subtitles then the deaf/HOH japanese user will miss it. | Deaf / HOH | MEK: The commenter talks about non-spoken content, however, Captions are provided for all prerecorded audio content in synchronized media, as per checkpoint 1.2.2. I agree the captions should be in English for English content and subtitles are translated into Japanese.
|
Does not extend 2.0 | N/A | - |
| Marc J, Moe K | 18 | Discussed in March 24, 2015 call (http://www.w3.org/2015/03/24-wai-wcag-minutes.html) The issue is that if a developer uses CSS background images to include an image on a page and uses a technique to provide alternative text (e.g. ) the text can show up when CSS is disabled (the css image fails and the hiding of the text fails) but what about when the image is shown and the browser disabled css background images? Or what about if the author does this () - the image is shown visually and the AT user gets the alternative text, but browsers don't show the aria-label content if background images are not used. The question is whether this is a problem under 1.1.1, or possibly 1.3.1. For color there is a "don't rely on color alone" SC, but there is no "don't rely on images alone" SC and the result is a gap in coverage for VI users. |
Blind / Vision Impaired | MEK: The issue is not clear. Background images should not be used to convey important information. This is a failure of 1.1.1, http://www.w3.org/TR/WCAG20-TECHS/F3.html
|
Does not extend 2.0 | N/A | - |
| Marc J, Moe K | 19 | We will consider including information that more clearly associates failures with the technologies they relate to in future versions of the Techniques document. Issue 2678 | All | MEK: Organize Common Failures into categories that map to their technique/technology category: General failures, HTML failures, CSS failures, Scripting failures, Server side failures, SMIL failures, Plain text failures, ARIA failures, Flash failures, Silverlight failures, PDF failures.
- However, This may require a renumbering of failures, e.g. FG1, FH2, which may be very expensive in updating links that refer to these failures. - I’m not sure that organizing failures in such a way has enough benefits to justify the work. - Recommended: An optional approach would be to add links to the related failures on the grouped technique page, e.g. PDF Techniques page also has links to related failures but the failures continue to have the same number identifiers. |
Does not extend 2.0 | N/A | - |
| Marc J, Moe K | 20 | Document a series of techniques about CSS media queries and layout module to provide more flexible layout mechanisms that meet WCAG more elegantly. | Low vision/Vision impaired | MEK: I think it is worth investigating whether techniques should be added that cover CSS media queries and Responsive Web design (RWD). Jonathan Avila from SSB Bart Group, wrote an article on the accessibility considerations to take when using RWD. See What Does Responsive Web Design Have to Do with Accessibility? http://www.ssbbartgroup.com/blog/what-does-responsive-web-design-have-to-do-with-accessibility/
|
Extends WCAG 2.0 | Yes | - |
| Makoto | 21 | Sometimes WCAG has a requirement but a "mirror image" requirement that is also an issue isn't as clearly covered. E.g., things that look like headings have to be marked as headings, but things marked as headings don't have to look like headings. | Blind (Other?) | I don't think this example is a "mirror image" requirement as it doen't prevent users from accessing content of the page. Having more marked headings than things that look like headings may be annoying for screen reader users who are using headings navigation feature. But they can still access the content of the page. We might need to seek any other examples of "mirror image" requirements. | Does not extend | N/A | Nothing. |
| Makoto | 22 | We will look at issues around form fields. For instance, issue 2766 speaks about a search form field with a submit followed by two radio buttons which further affect the search. This may disproportionately affect non-sighted users. | Blind | I can't uderstand that SC 4.1.2 has a relationship with this issue. The resolution says "what is the programmatically determined name for the text field?" The name can be provided by using title attribute. | Does not extend | N/A | Nothing. |
| Makoto | 23 | Let us work out ways to reduce the confusion about normative/informative. Particularly in relation to Failures/techniques etc. There is lack of understanding that we need to work on fixing. Firstly internally, the WG needs to be clearer on this, so we can then improve our messaging to the public. | General | Each page of "Techniques for WCAG 2.0" has a note at the bottom of the page which reads "If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance." I'd like to suggest adding "Note that Techniques for WCAG 2.0 is not normative document. Each technique and failure is just an informative and can be revised/removed without notice to be up-to-date if needed." Besides, this note is located in an obscure place. Why don't we emphasize it by making it bold or changing background color? | Does not extend | N/A | Figure out how to improve our messaging to the public. |
| Makoto | 24 | It is not clear whether links are controls in the sense of 3.3.2, and therefore whether 3.3.2 applies to links. Some think a link opening a new window needs to be warned under that SC, others think not because are not controls whose values change. See SC failure for opening new window without prior notice ? thread and 22 July 2014 WCAG discussion. | All | I don't think that SC 3.3.2 applies to links. This SC applies to "when content requires user input" as described in the SC."Intent of this SC" in Understanding WCAG 2.0 says "the controls in a form". And Guideline 3.3 says "Help users avoid and correct mistakes." Links won't cause any user's mistake. A link opening a new window needs to be warned under "SC 3.2.5 Change on Request" and it can also fail SC 1.1.1 if the icon is used to indicate it without ALT text. | Does not extend | N/A | Nothing. |
| Makoto | 25 | Concern around 2.4.4 with link text and whether that applies to buttons as well as links. See discussion: http://webaim.org/discussion/mail_message?id=26963 (and replies) | Blind/Low vision/Cognitive (Other?) | The discussion at WebAIM's E-mail List pointed out an issue which is not covered by WCAG 2.0. I think SC 2.4.4 doesn't apply to buttons as the SC is about links and buttons are not links. But undoubtedly this is an issue. | Extends | Yes | Add "buttons" to 2.4.4 in the extension. |
| MichaelC | 26 | Concern expressed by PDF/UA group that WCAG should include criteria for critical resources (in the case of PDF, embedded fonts). | robustness | AFAICT this is a proposal to require specific technology features at the guidelines level, rather than keep them at the accessibility supported techniques level. It is possible that there might be a requirement around readable fonts; don't think there can be a requirement around the author-intended font; certainly can't be a requirement requiring font embedding. | Extends | Yes | Nothing (low vision TF might want to take up readable fonts) |
| MichaelC | 27 | WCAG requires keyboard access -- some mobile devices don't directly support external keyboard access to all interactive content (iOS) but do support alternative methods of access to interactive elements. | mobile, technology support | In WCAG 2, keyboard support was viewed as the universal least common denominator for input access. This is apparently no longer true. It's a tough nut to crack, because if we drop that, can we be sure that the proposed least common denominator will in fact provide the broad accessibility intended? It might involve functional requirements that are very situation-dependent, and hard to predict all the necessary sufficient techniques for a given situation to provide broad enough accessibility coverage. Alternatively, the guidelines approach might simply be to pick a few things besides keyboard access as known least common denominator and say things like "... can be done via a keyboard interface or voice input or touch screen without requiring visual feedback". But each one of those alternatives that is allowed to be the only solution might exclude some significant group, and the more alternatives we provide the more groups get excluded. | Changes | No | Mobile TF should propose a solution in the mobile extensions. |
| Tim / MichaelC | 28 | There are no failures documented for requiring speech or biometric input/authentication (SC 2.1.1) | low vision / mobile | write failures / MichaelC: I don't see that requiring biometric input is specifically a failure of this SC | changes / extends (MichaelC: any failures created would not change the guidelines) | no | MichaelC: nothing, Tim: explore possibility of failure with this item |
| MichaelC | 29 | Some Research symposium research indicates meeting WCAG success criteria may not address accessibility of site for users with disabilities. | ?? | Yeesh - that's a really general comment on a big resource. To do anything meaningful with this, the specific concerns raised by the research report should be pulled out as separate suggestions. Whoever initially brought this up should do that, as on a quick skim of the document I don't see what issues that person might have identified.
|
?? | ?? | nothing |
| MichaelC | 30 | Noticed that the SC for Time Based media, refers to "Time-based Media: Understanding Guideline 1.2" and all of the 1.x items are guidelines and the 1.1.x or 1.2.x are Success Criteria. [1] Looking at how the other Guidelines and SCs are presented the two things (Guidelines and SCs) are jumbled up. No wonder it is hard to understand the difference - so I think in future this is something we can work on disambiguating and making clearer in future versions. | editorial | AFAICT this is a request for clarification of the structure of Understanding, and is just an editorial project. If it is actually a request to rejigger the arrangement of success criteria and guidelines, it would be a fundamental change that we would not do in an extension. | Changes | No | nothing |
| MichaelC | 31 | We have no way right now to make complex maps accessible. We've never had any serious discussion about them in 15 years. | low vision, blind, multimodal input | There are probably a lot of issues with how to make maps accessible. This would range from making maps adapt to the needs of people with low vision (the easiest one), make the map data meaningfully available to people without visual access, and coming up with good ways to interact with maps other than the mouse / touchscreen approaches that are predominant now. Probably tackling this would merit becoming a module all on its own to start. | Extends | No | Form a TF to explore the issues of maps, or put on list for a future major revision of guidelines
|
| - | 32 | WCAG 2.0 doesn't have any "severity" ratings for sites, which would be helpful. | - | - | - | - | - |
| Jonathan A | 33 | Confusion of success criteria. WCAG 2.0 guidelines are not adequate technical definitions for accessibility in all technologies. True technology independence means understanding that for broad effect the next-generation content accessibility guidelines must consist of principles, not technical statements. The guidelines should facilitate the development of compatible technical standards, not supplant them. | Techniques | Provide more technical standards. | |||
| David MacDonald | 34 | Jared's comments Remove Captcha. If a site provides both a graphical and an audio CAPTCHA, it passes. This, however, continues to exclude users that are deaf-blind, not to mention the difficulties that all users have with CAPTCHAs. CAPTCHA has failed. Automated processes can now bypass it faster and more accurately than actual users. WebAIM clients, even those in the highly secure financial services industry, are abandoning CAPTCHA. WCAG should do the same by removing it as an exception, or perhaps allowing graphical and audio CAPTCHA for Level A conformance but prohibiting all CAPTCHA at Level AA. | Blindness, deaf-blind | David: I think this will need to be a part of a larger strategy. Kathy and I put together the a paper on Captcha The best alternative so far appears to be Multi factor identification, texting a code to a cell which is input. I don't think we'll be able to push the envelope on captcha until a clear alternative emerges. | Changes | yes | Write technique that the best alternative so far appears to be Multi factor identification, texting a code to a cell which is input. (cannot forbid Captcha yet) |
| David MacDonald | 35 | Jared's comments Several of WCAG 2.0′s media guidelines include “…except when the media is a media alternative for text and is clearly labeled as such.” This means that text alternatives are not required if the video is an alternative version of the main text content of the same page (for example, a web page with the text of a speech that also presents a video version of that speech). This, however, is often misunderstood to suggest that if a transcript is provided, then captions or audio descriptions are not required. This could perhaps be clarified to indicate that if the main content of the page provides all necessary content of the associated media, then no other requirements (captioning, transcript, etc.) are necessary. | Deafness, blindness | David: I don't think we can say, if the content provides all the necessary information in text on the page that Captions are not required. It appears that there may be a misunderstanding of an media alternative, which is primarily for people with cognitive disabilities... and it ensures authors won't be punished for trying to create some visual aids to the text for cognitive users. | Changes | Yes | We'll have to manage this through education and perhaps rewording "media alternative to text" rather than changing the requirements. |
| David MacDonald | 36 | Jared's comments “Alternative for time-based media” is a confusing term for a descriptive transcript – a text transcript of the audio or video that provides all necessary auditory content (such as identifying laughter or an off-screen explosion) and visual content (such as a list of items displayed in the video that are not presented via audio). We simply use “descriptive transcript” instead and have found is much more easily explained and understood. If a user reads the descriptive transcript, they will get all of the necessary content conveyed in the audio or video. | Blindness, multimedia | David: I think this is a good suggestion. "Descriptive transcript" is better than "alternative to time based media", which is pretty clinical and hard to understand. Let's change it. | Does not extend | No | Change "alternative to time based media" to "Descriptive transcript" |
| David MacDonald | 37 | Jared's commentsIf an author provides a descriptive transcript to satisfy SC 1.2.3, then audio descriptions are required in SC 1.2.5 at Level AA. However, if an author provides audio descriptions to satisfy SC 1.2.3, then a descriptive transcript is not required until SC 1.2.8 at Level AAA. This latter case would render the media inaccessible to deaf-blind users at Level AA, because both captions and audio descriptions are inaccessible to these (and many other) users. | Deaf-blind | David: The Government of Canada and the Government of Ontario both provided exceptions for 1.2.5. These exceptions have passed largely unchallenged by the blind community. There has been some progress on the development of text based audio descriptions read by screen readers, but I haven't of heard much progress lately. If this doesn't become mainstream, I think audio description will continue to be an specialized art, that requires much money, much bandwidth, and much skill, and a recording studio to pull off. Therefore I would support this proposal. | Move audio descriptions to not be required until Level AAA SC 1.2.8 | ||
| David MacDonald | 38 | Jared's comments This is all compounded by the fact that if the video does not require audio descriptions (meaning all necessary visual content is presented in the audio of the multimedia), then SC 1.2.3 and SC 1.2.5 are satisfied. This means that for such video (e.g., a talking head), the author is not required to provide a descriptive transcript unless they are seeking Level AAA conformance. In other words, if a page contains only audio, it requires a descriptive transcript at Level A. But if you add a talking head video or simply add the audio to some video content, it doesn’t require a descriptive transcript until Level AAA. This surely is a weakness in WCAG 2.0 that should be addressed. | Deaf blindness | David: I think this is a stretch of the Success Criteria. 1.2.3 say: "An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, ... (Level A)" It doesn't say if it's a talking head then they don't have to do either. Now in general, if it is a talking head most of us have pastorally waved the Audio description requirement, but at level A there needs to be one OR the other, and therefore the waving off of the AD does not wave off the Transcript requirement. G203 is called "providing a text alternative to a talking head video" | Doesn't extend | No | Explore a separate requirement for transcript in an extension of WCAG next/ |
| David MacDonald | 39 | Jared's comments
Recommended restructuring: Confusion and limitations of the current guidelines could be addressed by structuring the guidelines as follows based on the media’s characteristics
This structuring would require audio descriptions or a transcript at Level A, but only if they are necessary for blind accessibility. At Level AA, all pre-recorded video would require transcripts. At Level AAA, video would require audio descriptions, if they are necessary due to visual-only content. Move audio descriptions to Level AAA (in WCAG 1.0, they were Level A). While they are the primary and preferred mechanism for providing multimedia accessibility to users with visual disabilities, one must balance their significant expense and difficultly to generate and the fact that transcripts provide equivalent content and are also accessible to a much broader audience (e.g., deaf-blind). Because a transcript will already have been generated in order to provide captioning, it seems more logical that the emphasis should be placed on providing a nearly universally accessible descriptive transcript, rather than on providing less usable and more burdensome audio descriptions. |
Deaf, blind, deaf/blind cognitive | David: I would accept this change IF audio description doesn't get easier or cheaper (automation, timed text descriptions etc.) | Changes | Yes | Move descriptive transcript to not be required until Level AAA SC 1.2.8 |
| David MacDonald | 40 | Jared's comments Adding a minimal contrast requirement (perhaps 2:1 and 3:1 for large text) at Level A would help address significant readability issues that could be found on Level A conformant sites. | Low vision | David: I agree with this. | Extends | No | Add a minimal contrast requirement (perhaps 2:1 and 3:1 for large text) at Level A |
| David MacDonald | 41 | Jared's comments We know that many users prefer text sizing over page zooming. This adds credence to my recommendation above for a 150% true text resizing requirement. | Low vision | David: I agree with this. | Extends | No | Explore a requirement for 150% text zoom OR Reflow (responsive) without clipping at Level AA, Both text zoom AND/OR responsive would conform |
| David MacDonald | 42 | Jared's comments While using text is always optimal for accessibility (and for other reasons), Level AA conformance should only require that the graphical text be replaced with true text when readily-available font face styling will suffice. In other words, authors should not be required to implement significant text styling to duplicate the graphical text’s presentation. SC 1.4.9 (Level AAA) already prohibits all presentation of text within images. | Low vision | David: I think this is is a misreading of the SC. It does not require the author to change his desired font. Maybe we need to word smith this better, but I think the understanding document is fairly clear. "If for any reason, the author cannot format the text to get the same effect, the effect won't be reliably presented on the commonly available user agents, or using a technology to meet this criterion would interfere with meeting other criteria such as 1.4.4, then an image of text can be used." I think the understanding document should be required reading. I don't recommend any change, except maybe we can make it clearer somehow in the SC. | No | No | Maybe clarify the SC, no fundamental change |
| David MacDonald | 44 | Jared's comments # This success criterion (2.4.1) would be more meaningful and understandable if it required at least two possible mechanisms, such as:
|
Keyboard, blindness | David: Currently, any ONE of these meet the WCAG, except HTML5 which we might want to add when we do HTML5 techniques. There is currently an active discussion about headings and landmarks not being sufficient for keyboard only users. I would like to hear from keyboard only users about their needs. So far in 17 years I've never met one who doesn't liberally use MouseKeys. | Extends, requires two methods which currently it requires only one. | No | Solicit feedback from keyboard only users (particularly keyboard only sighted users who don't use mouse keys) |
| David MacDonald | 45 | Jared's comments Link text that “can be programmatically determined” does not mean “IS programmatically determined”. This creates a situation where WCAG allows or requires something that does not actually result in any better accessibility. It also presents a situation whereby authors can’t know for sure if their content is actually conformant without knowing if assistive technology CAN do something. And which specific technologies or how many of them must do it before “can” means “can”? This is very akin to WCAG 1.0′s very confusing phrase “until user agents…”. This could perhaps be addressed by more specific details at the success criteria or techniques level that reflect actual assistive technology capabilities, rather than simply suggesting that potential support is sufficient. | Blindness | David:
The definition of accessibility supported sufficiently plugs the gap that Jared say "can be programmatically determined ..." leaves. I think the best way to address this is that we can now remove the "in context" exception. In the age of aria-labelledby, and aria-label, there is no longer any reason that Screen Reader links lists have to say "click here, more, learn more, read more" etc. because aria now works in both JAWS and NVDA to provide this information while not punishing the sighted user. |
Extends | No | Add a failure for link that is ambiguous that has no other programmatic association or fallback aria-labelledby, aria-label |
| David MacDonald | 46 | Jared's comments Require Keyboard Focus Indicators at Level A. A lack of keyboard focus indicators for navigable page elements – SC 2.4.7 (Level AA) – renders a page nearly entirely inaccessible for the large population of sighted keyboard-only users. This is one of the most significant and pervasive accessibility issues currently on the web (see The Plague of Outline:0). There is no reason why this should not be a Level A requirement. | Sighted Keyboard users | David: I would like to hear from keyboard only users about their needs. So far in 17 years I've never met one who doesn't liberally use MouseKeys. So maybe we have to solicit input from this user group. We've received one complaint in 8 years and it was not from a Keyboard Only user. | Extends | No | solicit input from this user group and drop if there is no substantial response |
| David MacDonald | 47 | Jared's comments Remove Parsing Requirement: While the intentions are noble, SC 4.1.1 (Level A), which requires that significant coding validation errors be avoided, has little impact on end-user accessibility and is next to impossible to evaluate. The areas in which coding errors impact accessibility are already sufficiently covered by other success criteria (such as proper form labeling, frame titles, table headers, etc.). I can’t think of a single instance where a significant coding issue would impact assistive technology specifically. The parsing requirement should be removed or perhaps changed to require strict validation at Level AAA. | Blindness primarily | David: On the blog where this was found there was quite a bit of blow back from this recommendation in the comments section. We arrived at our current requirement after careful consensus building. We came about as close to a formal objection for not requiring validation as we possibly could. We currently require a very small subset of validation tests for markup languages which include:
It is trivial using automated checking to test these and it is free using the validator NU if one doesn't want an automated WCAG check. I think we should leave this, if we don't want a long dirty war with standardistas. |
In the next version of WCAG we should ask the question about these parsing requirements, and see if it's a war and if we need to make the same requirement or not., this will involve researching if any of our parsing requirement are resulting in real world accessibility improvements. | ||
| Laura Carlson | 48 | Unclear link destinations. The Guidelines are only half of the story study found, "In 35.0% of problems in this category, the website had properly implemented SC 2.4.4 regarding the description of link purpose, and yet users still had problems determining where the links lead. This indicates that the sufficient techniques for this SC, which are primarily aimed at addressing the problems of blind, screenreader users, are in fact not sufficient." | Blindness Likely Cognitive |
As Detlev Fischer pointed out in a response to this paper "The study's conclusion that the sufficient techniques for SC 2.4.4 Link Purpose are in fact not sufficient at least for the group of blind users strikes me as valid. WCAG 1.0 recommended, in Checkpoint 13.1: "Clearly identify the target of each link. Link text should be meaningful enough to make sense when read out of context." WCAG 2.0 has relaxed this requirement by allowing authors to provide the purpose in the link's context. For blind users who rely on generated indices of headings, WCAG 2.0 is clearly a step backwards. As the lack of descriptive links will also contribute to other frequent problems such as "Content not found in pages where expected by users", it may indeed be worth rethinking SC 2.4.4 in future work on WCAG." | Changes | No | Laura: The WG may want to consider reinstating WCAG 1.0, Checkpoint 13.1. In addition input from the COGA TF could be helpful to ascertain if reinstating would have benefits to that user group. |
| Laura Carlson | 49 | Unclear relationship between usability and accessibility. The study, Guidelines are only half of the story presents several usability issues as accessibility issues. It calls out items such as: content found in pages where not expected, pages that load slowly, no alternative to document formats, complex information architecture, and broken links. | Potentially all | Laura: Expanding accessibility to include usability has previously occurred and is currently occurring in other venues including the United States Department of Education, Office for Civil Rights (OCR) resolution agreements. This raises broader questions such as is a tighter integration of usability and accessibility needed? Should the WAI consider furthering efforts in the area of Usable Accessibility and User Centered Design (UCD)? Consult Laura's review of the 2012 study for details.
|
Extends | No | Laura: The WG may want to consider what is in or out of scope. Some usability folks may be interested in a some type of a usability WCAG extension. ("Usable Accessibility", UCD ?) |
| Laura Carlson | 50 | A 2005 study, Forcing Standardization or Accommodating Diversity? argues that the test for whether a Web site is accessible is if people with disabilities can use it, not whether it conforms to guidelines. The study concludes that WAI should include usability within its remit and future versions of WCAG should include guidelines on best practices for usability. Consult Laura's review of the 2005 study for details. | Potentially all | Laura: WCAG 2.0 does not define accessibility. Regarding usability, Understanding WCAG 2.0 specifically states: "There are many general usability guidelines that make content more usable by all people, including those with disabilities. However, in WCAG 2.0, we only include those guidelines that address problems particular to people with disabilities. This includes issues that block access or interfere with access to the Web more severely for people with disabilities." As discussed in a similar review (see row 49) "accessible" has recently been expanded to include usability in United States Department of Education, Office for Civil Rights (OCR) resolution agreements. | Extends | No | Laura: Over the years a number of studies and articles have criticized WCAG for having an ambiguous relationship with usability, not having a framework that includes usability, or not having guidelines on usability best practices etc, etc. I reviewed two of the studies (row 49 study and row 50 study) for this page and there does seem to be a usability theme. As mentioned in row 49, WCAG's relationship to usability may merit Working Group discussion if it has not already been discussed. We may want to contemplate the question of what is in or out of scope. Some usability folks may be interested in an extension. Perhaps the authors the studies? I'm not sure. |
| Laura Carlson | 51 | Post-secondary digital instructional materials gaps, which could cause WCAG not to be used as a standard for instructional materials at US colleges and universities. Advocates for students with disabilities and major US organizations representing colleges and universities ( EDUCAUSE and AAU) have sparred (Good Intentions, Bad Legislation) and expressed concern over US Federal legislation: the TEACH Act, which would set voluntary accessibility guidelines for post-secondary digital instructional materials. |
Potentially all | Laura: In an answer to a question from Jon Gunderson on the EDUCAUSE IT ACCESS mailing list, which asked: "Are the voluntary guidelines considering WCAG 2.0 Level A and AA, or will it be something different?" Jarret Cummings of EDUCAUSE replied, "That's a question that the independent commission will have to consider, but we anticipate that a compromise bill will direct the commission to consider preexisting IT accessibility standards in determining what's needed to promote instructional materials accessibility." In the past WCAG has served as the standard to meet in legal settlements in higher education, for instance Penn State, University of Montana (PDF), Florida State, and Louisiana Tech agreements. It has a history. |
Extends | No | Laura: WCAG WG may want to consider if a digital instructional materials extension or other documentation may be in order to close any gaps. Perhaps talk with stakeholders (NFB etc).
If an extension or other documentation is in order, we may want to explore any synergies between this issue and the W3C Accessible Online Learning Community Group. Perhaps some of the CG members would want to be participants in an Instructional Materials Task Force.| |
| ? | 52 | Issue of whether labels and controls need to be associated explicitly if the technology allows it. https://github.com/w3c/wcag/issues/122 | Low-vision | ? | Extends | ? | |
| ? | 53 | ?? | ? | ? | Extends | ? | foo |
Articles to review and pull individual items from
| Assigned to | Row | Source | Related rows in above table |
|---|---|---|---|
| Makoto | 1 | Comments from The future of WCAG – maximising its strengths not its weaknesses (Jonathan Hassell, HassellInclusion, January 2013) | 1) each success criterion would be more useful if it gave an idea of which disabled audiences would benefit from conforming with the criterion. - MU: WG could address this issue by reviewing and enhancing "Specific Benefits of Success Criterion X.X.X" in Understanding WCAG 2.
2) a rough idea of how much it might cost to conform to it. - MU: None. It will be difficult. 3) the criteria could also be made easier to read. - MU: I agree with this. But we can't do anything. So we should keep enhancing Understanding 2 at least. 4) it would be useful to structure them via job-roles so it’s easy to know which member of a website creation team needs to deal with each criterion - MU: See "Accessibility Responsibility Breakdown"(http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown) 5) The Uni of York paper found that numerous problems that disabled people experience with web pages are not covered by WCAG 2.0. This is certainly true, especially for the needs of people with cognitive, learning and literacy difficulties - MU: We have Cognitive A11Y TF(http://www.w3.org/WAI/PF/cognitive-a11y-tf/) to address this issue. 6) WCAG 2.0’s success criteria will need to be frequently updated, because currently it just isn’t enough to do that. - MU: WG might be able to address this issue by developing the extensions. 7) Criterion 1.2.5 requires all pre-recorded video content to be enriched with audio description. What this means is that for a site that includes video to achieve AA it needs to include audio description on all its pre-recorded video. So, for example, a user-generated video sharing site like YouTube could never achieve AA without requiring all of its users to include that audio description themselves. - MU: Statement of Partial Conformance could be made, although it means non-conformance. 8) The number of people who benefit from captions being provided for video content is huge, and the cost is reasonable. Comparatively, the number of people who benefit from audio description (or an ‘alternative’ to video) is very small, and the cost is large. And yet none of this essential information is mentioned in the success criteria, and both are set at level A in WCAG 2.0. - MU: maybe 32? My understanding is that WCAG 2 put users benefits before the cost. And it would be difficult for WG to estimate both the number of people who will benefit from each SC and the cost of implementing each SC. 9) The problem with WCAG 2.0 isn’t that it’s not perfect; the problem is that it’s static and WAI are resistant to updating it, so its imperfections are argued over, rather than improved upon. - MU: WG might be able to address this issue by developing the extensions. |
| Marc J David MacD |
2 | Jared's comments
| |
| AWK | 3 | Comments from Measuring accessibility (Roger Hudson, DingoAccess, November 2011) | The article provided general commentary about expert review vs. user testing and didn't have specific changes for WCAG to offer. |
| AWK | 4 | Comments from Accessibility Barrier Scores (Roger Hudson, DingoAccess, November 2011) | 32 |
| Louis Cheng | 5 | Comments from Can checklist accessibility be harmful? (Vlad Alexander – Rebuilding the Web, June 2010) | - |
| Christophe S | 6 | Comments from Accessites.org - Jack Pickard | - |
| 7 | Comments from Accessibility Watch - Ken Nakata | - | |
| Laura Carlson | 8 | Comments from Guidelines are only half of the story: accessibility problems encountered by blind users on the web - Power/Petrie et al. See also Methodological flaws put question mark on study of the impact of WCAG on user problems | Row 48: One issue around 2.4.4 may be valid. Row 49: In addition the group may want to think about the broader questions raised as explained in Laura's review of this 2012 study. |
| Laura Carlson | 9 | Comments from Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World Brian Kelly: UK Web focus | The vast majority of the issues raised have been resolved by WCAG 2 or overcome by events. Row 50: However, WCAG's relationship to usability may merit Working Group discussion if it has not already been discussed. Please consult Laura's review of this 2005 paper. |
| Moe Kraft | 10 | Comments from Response to WAI’s Website Accessibility Conformance Evaluation Methodology 1.0 Working Draft | -This blog post provides a response to the October 2012 draft of the Website Accessibility Conformance Evaluation Methodology, http://www.w3.org/TR/WCAG-EM/ by Brian Kelly. Brian raises the following concerns:
1) It would be counter-productive for policy makers to mandate conformance through WCAG by following WCAG EM. 2) WCAG should be treated as a valuable set of guidelines whose use should be considered in context. 3) Organizations that may not fully comply to WCAG, may ironically fail to provide any accessibility support especially in the public sector. 4) The author suggests that document makes it clear that it would be inappropriate for policy-makers and legislators to enact legislation based solely on WCAG conformance. He proposes that it would be more appropriate to develop policies and legislation based on the processes surrounding the development of Web products as suggested in Accessibility 2.0: People, Policies and Processes, http://www.ukoln.ac.uk/web-focus/papers/w4a-2007/ This is somewhat related to item 23, Normative vs. Informative while WCAG EM is an informative document. As well, this relates to item #29 while the author indicates that the current WCAG guidelines do not address all disabilities. Response: WCAG EM is informative. It is suitable for different contexts self-assessment vs. 3rd party evaluation. It is useful in design and development stages of the process as well as test evaluation. WCAG EM encourages involving users and clearly states using this methodology alone does not result in WCAG 2.0 conformance claims. Going forward with our Post WCAG 2.0 activities, we need to be sensitive to the fact that some web authors may see WCAG as all or nothing and that they would prefer to deliver no accessibility support than attempt to comply due to cost. We need to find a way to encourage the process of incorporating accessibility in the development of web applications without making it all or nothing which would be couter-productive and not serving to PwDs. |
| Jonathan A | 11 | Comments from Common Look - Duff Johnson | 33 - |
| James N | 12 | Comments from Understanding WCAG levels - Karl Groves | - |
| MichaelC | 13 | Comments from WCAG 2.0 AAA - A Journey Not a Destination Mike Gifford – Open Concept | - |
| Josh | 14 | Comments from AccessIQ (Scott Hollier) -WCAG 2.0 sceptics: should we be afraid? | - This article references the thesis of André Pimenta Freire "Disabled people and the Web" and its conclusion that WCAG 2.0 compliance is ineffective when making the web accessible to blind and print-disabled users (blind, partially sighted, dyslexic). His thesis included an "empirical study of the problems encountered by 32 blind users on the Web. Task-based user evaluations were undertaken on 16 websites, yielding 1383 instances of user problems. The results showed that only 50.4% of the problems encountered by users were covered by Success Criteria in the Web Content Accessibility Guidelines 2.0 (WCAG 2.0). For user problems that were covered by WCAG 2.0, 16.7% of websites implemented techniques recommended in WCAG 2.0 but the techniques did not solve the problems. These results show that few developers are implementing the current version of WCAG, and even when the guidelines are implemented on websites there is little indication that people with disabilities will encounter fewer problems."
The author advocates moving from a problem-based approach towards a design principle approach for web accessibility. From Hollier's assessment of the thesis he finds:
Finally, this work has its basis in WCAG 1.0. If exclusively focussed on 2.0 - the results may be different. A take away from this research (suggested by Hollier) is that "this research shows that in particular circumstances, some particular disability groups face particular issues that standards do not always address". |
| KW | 15 | Comments from Disabled people and the Web: User-based measurement of accessibility | - |
| 16 | It really does appear as if WCAG 2.0 is moving in the direction suggested in the article. We could rethink levels, maybe make their motivation clear. The articles divide between boosters and detractors is silly. Even though I have criticized WCAG, I understood the early circle the wagons mentality. 2008 was flat out crazy. The fact that one could be a passionate defender and critic of WCAG was probably too subtle to sort out in this opinion piece.
One thing WCAG WG needs to consider carefully is this question. When does a usability issue become an accessibility barrier. I see two criteria that would ensure this classification: (1) The usability issue interferes with essential functionality, and (2) The burden of encountering the issue falls disproportionately on a well defined class of people with disabilities. Horizontal scrolling (HS) is an example. HS interferes with reading speed and comprehension. That is extensively documented in usability and psychophysical literate. Reading is an essential function. The burden falls heavily on users with partial sight who need print enlarged to 30 to 72 point font (say Verdana). In this range, one can fit whole words on a 13 to 15 inch laptop monitor. and get several lines on a page, and the horizontal scrolling interference with reading really becomes a barrier to reading. Why did I pick the magnification range I did. (1) It correlates well with the visual acuity range (20/60 to 20/120.. 1/3 to 1/6), most of the moderate low vision range. (2) It enables multiple lines per page. For larger enlargement the screen only has one line per page or is masked to do so. In this case horizontal scrolling is little different from vertical scrolling. In conclusion, by my definition of when a usability issue becomes an accessibility barrier, horizontal scrolling qualifies: (1) It significantly disrupts an essential function (reading), and (2) the burden falls heavily on people with moderate low vision. | ||
| 17 | - | ||
| 18 | - | ||
| 19 | - | ||
| 20 | - | ||
| 21 | - | ||
| 22 | - | ||
| 23 | - | ||
| 24 | - | ||
| 25 | - | ||
| 26 | - | ||
| 27 | - | ||
| 28 | - | ||
| 29 | - |