Post WCAG 2

From WCAG WG

Notes about things we might want to do post WCAG 2.0.

Articles and blog posts on WCAG 2.0

A checklist approach to a11y is bad. Automated checkers are faulty.

Is WCAG 2.0 less stringent than WCAG 1.0. The fact that WCAG 2.0 is apparently self-contradictory. Documentation is vastly over-inflated. Document is not in clear and concise language. The fact that not everything required to understand the success criteria is defined as part of the standard.

Are the conformance requirements too high?

This paper describes 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 paper closes by discussing the implications of this study for future research and practice. In particular, it discusses the need to move away from a problem-based approach towards a design principle approach for web accessibility.

And a critique of methodology and results of this research at University of York: Methodological flaws put question mark on study of the impact of WCAG on user problems

Since 1999 the W3C’s Web Content Accessibility Guidelines (WCAG) have provided a solid basis for implementation of accessible Web design. However it is argued that in the context of evaluation and policymaking, inappropriate reference to the WCAG may lead to serious practical difficulties in implementation and monitoring of an effective accessibility policy. There is a pressing need for a framework that guides appropriate application of the WCAG in a holistic way, taking into account the diversity – or homogeneity – of factors such as context of use, audience and audience capability, and access environment. In particular, the current promotion of W3C technologies at the expense of widely used and accessible proprietary technologies may be problematic, as is the apparent reliance of the WCAG on compliant browsing technology. In this paper, a holistic application of the WCAG is proposed by the authors, whereby the context of the Web resource in question and other factors surrounding its use are used to shape an approach to accessible design. Its potential application in a real world environment is discussed.

limitations of the WAI model (i.e. its dependencies of ATAG and UAAG) ; the need to address contexual factors and the need to address accessibility issues in a broader context including the context of use and purpose of the Web resource and the financial implications of conforming with the guidelines.

WCAG 2.0 isn't aging well. There's not much adoption outside of government and precious little (operationally) within. Experts still argue over what it means. What kind of update might trigger serious uptake in the commercial world, and really drive delivery of benefits to end users?

General confusion and lack of clarification over what ‘levels’mean vs priority

Nobody should be claiming WCAG 2.0 AAA.

For a website site with any complexity at all to it: • It takes a huge accessibility budget to maintain. It is very time intensive to run every page of the site through the quick reference provided by the WAI. Even running through it through WebAIM's simplified checklist is a lengthy process. • Some of the WCAG 2.0 AAA requirements can conflict with each other or other WAI guidelines. You have to know your users, and learn where to make compromises. • There probably aren't any examples out there of sites that are 100% compliant. Individual pages might comply, but will still need to be reviewed on a regular basis. The WAI is wisely focuses on broad objectives not on specific technology and the technology is perpetually changing. A user's browser or screen reader upgrade can easily break accessibility.

[...] Knowledge of what problems people with disabilities are encountering is quite low.

The aim of the work presented in this thesis was to conduct a study that characterises the problems that print-disabled users (blind, partially sighted, dyslexic users) are encountering on the web. [...] that are effecting users with print-disabilities.

A secondary goal was to investigate the relationship between user-based measures of accessibility and measures related to technical guidelines, especially the Web Content Accessibility Guidelines (WCAG) 1.0 and 2.0 from the World Wide Web Consortium (W3C).

This was done to both identify gaps in the current guidelines, as well understanding where technical guidelines are currently not sufficient for addressing user problems. The study involved task-based user evaluations of 16 websites by a panel of 64 users, being 32 blind, 19 partially sighted and 13 dyslexics and manual audits of the conformance of websites to WCAG 1.0 and 2.0.

The evaluations with print-disabled users yielded 3,012 instances of user problems. The analysis of these problems yielded the following key results. Navigation problems caused by poor information architecture were critical to all user groups. All print-disabled users struggled with the navigation bars and overall site structure. Blind users mentioned problems with keyboard accessibility, lack of audio description of videos and problems with form labelling often. However, beyond these seemingly low-level perception and execution problems, there were more complex interaction problems such as users not being informed when error feedback etc [...]

Comparisons between user problems and WCAG 1.0 and WCAG 2.0 did not show any significant relationship between user-based measures of accessibility and most measures based on technical guidelines. The comparisons of user problems to technical guidelines showed that many user problems were not covered by the guidelines, and that some guidelines were not effective to avoid user problems. The conclusions reinforced the importance of involving disabled users in the design and evaluation of websites as a key activity to improve web accessibility, and moving away from the technical conformance approach of web accessibility.

Metadata

Comments from Liddy Nevile:

(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).

(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.

Change of context after timeout

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.

Keyboard Navigation

  • Focus order vs programmatically determined reading order vs visual presentation order;
  • what keyboard users want/expect from initial focus placement,
  • strategies and standards for navigating around a page in ways other than tabbing through all controls
  • possible standards and conventions for keyboard access
  • User Agent and AT support that is needed to improve this experience for HTML and DHTML

Low Vision Support

See Wayne Dick's public comments and follow-up comments about his need for

  • modification of font-family based on element (tag) type,
  • enlargement of letter, word and line spacing for text and
  • variable enlargement linked to element type.

Low vision requirements are being gathered at Low Vision Requirements.

Adding Dynamic Content

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.

See Survey of LC 2744

Captcha

We have been collecting current and emerging Captcha techniques and alternative. It is a terrible problem and we haven't solved it yet. We need to work on this.

Color and Contrast

Raise SC 1.4.3: Contrast (Minimum) to Level A

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, WCAG Next (Jared Smith, Webaim, January 2012)

Contrast of Hover and Link Text States

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.

Makoto Ueki LC-2893 comment: If a color of link text is changed when a mouse cursor is hovering over a link (by using CSS, a:hover), does the changed color also need to have a sufficient contrast ratio to meet SC 1.4.3 and/or 1.4.6?

Proposed Change: I just want to make sure that the changed color of link text is also required to have a sufficient contrast (or not).

Response (at that time to Makoto): Thank you for your comment. The opinion of the working group is that the color-contrast ratio of the link text when focused or hovered does not need to meet 1.4.3/1.4.6. The goal of the color contrast success criteria is to ensure that content can be read by users, so as long as the links are sufficient contrast when not focused/hovered then they will meet 1.4.3/1.4.6. It is definitely preferred that focused/hovered link text also meet the contrast ratios as this enables users to re-read and verify the target of the link, but this represents more of a usability issue as the user can easily read the link text by removing focus or moving their pointer off the link.

See LC-2893 [1]

Contrast in Icons

There is a need for clarification on color contrast in icons. Discussed in LC-2762 on June 25, 2013 WG meeting

Captions in different languages

There is a need for some clarification in the area of captions. A comment was raised (https://www.w3.org/2006/02/lc-comments-tracker/35422/REC-WCAG20-20081211/2942) 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.

High Contrast Mode issue

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. My Cat) 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.

Cognitive

Discuss ways of adopting the outputs of the Cognitive TF, having greater interaction/co-ordination between task forces http://www.w3.org/WAI/PF/cognitive-a11y-tf/

Mobile

Discuss ways of adopting the outputs of the Mobile TF, having greater interaction/co-ordination between task forces http://www.w3.org/WAI/GL/mobile-a11y-tf/

The WCAG Principle 2: Operable currently focuses entirely on keyboard access. Touch input has become a major interaction mode, speech input is becoming more important too, and physical gestures (shaking a handset) and 3D gestural input are picking up. For reflecting these modes in WCAG, one possible solution might be to develop more mode-specific success criteria, e.g. 2.1.3 Touch, 2.1.4 Speech, etc. Another solution would be to ditch the mode-specific SC Keyboard for a mode-agnostic SC that might read, for want of a better name, 2.1.1 Accessible modes: Make all functionality available via modality-specific user interaction events. The question then still remains how different input modes can adequately be rendered as a testable WCAG Success Criterion, and what scope of functional operability across modes would be required to call some content conformant.

Techniques

  • 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
  • Document a series of techniques about CSS media queries and layout module to provide more flexible layout mechanisms that meet WCAG more elegantly.
  • Need techniques about CSS spriting issues. Cynthia has a PFWG action to submit some.

Misc

  • 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.
  • 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.
  • 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.
  • 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.
  • 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)
  • Concern expressed by PDF/UA group that WCAG should include criteria for critical resources (in the case of PDF, embedded fonts).

Open Questions?

  • 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.
  • There are no failures documented for requiring speech or biometric input/authentication (SC 2.1.1)
  • Some Research symposium research indicates meeting WCAG success criteria may not address accessibility of site for users with disabilities.

Presentation of Success Criteria and Guidelines in Understanding Doc

While preparing a survey today I just 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.

Josh

[1] http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv.html

Complex maps

We have no way right now to make complex maps accessible. We've never had any serious discussion about them in 15 years.

Retrieved from "https://www.w3.org/WAI/GL/wiki/index.php?title=Post_WCAG_2&oldid=5604"