On October 12, 2016, the World Wide Web Consortium (W3C) published a blog post exploring a possible update to the Web Content Accessibility Guidelines (WCAG) 2.0 standards. This new iteration—WCAG 2.1, as it will be known—will build upon its predecessor, which is already considered the gold standard of accessibility guidelines for the web.

WCAG 2.0 was released in December 2008 and has been widely adopted across the globe. Due to recent advances in technology, the team responsible for developing the guidelines announced its intention to create a dot-release update to build upon WCAG 2.0. WCAG 2.1 is meant to address special topics areas, including (but not limited to) mobile devices, cognitive impairments and learning disabilities, and low vision. The goal of WCAG 2.1 remains the same as that of 2.0—promoting the accessibility of web content to all individuals.

We reached out to the WCAG Working Group (WG) spearheading the update effort to ask a few questions regarding the proposed update, and they were kind enough to respond. Below are the responses we received.

w3c

User1st: How does the WCAG WG decide when it’s time to start planning an update to accessibility standards?

WCAG WG: The WCAG Working Group has continued to provide support for WCAG 2.0 ever since it was released. This support was in the form of continued maintenance and updates to the support resources “Understanding WCAG 2.0” and “Techniques for WCAG 2.0,” documenting a small set of errata for WCAG 2.0, responses to questions received by the Working Group, as well as via participation and presentations at various industry conferences.

The Working Group’s efforts in this area have kept it aware of the state of guidelines implementation and the areas where additional guidance might initially be needed.

For the first several years after WCAG 2.0 was finalized and adoption spread around the world, the issues raised mainly could be addressed by improving the support materials. In recent years, as technology has evolved, opportunities to improve the core guidelines became more evident. In particular the Working Group began work and created task forces to explore how to address the needs of people with cognitive and learning disabilities, for people with low vision, and on mobile devices.

As this work matured, the working group developed plans to incorporate these new requirements. Different plans were openly discussed between participants of the working group, with member organizations of W3C, and with members of the public at different occasions, until the current approach emerged.

The Working Group now proposes to develop an updated called WCAG 2.1, which will build on but not supersede WCAG 2.0. it will have a restricted scope, be as similar to WCAG 2.0 as possible, and be fully backwards compatible. While WCAG 2.1 will be available to organizations that wish to follow updated advice, WCAG 2.0 will not be retired.

Beyond this near-term work on WCAG 2.1, the Working Group also has begun work on a more substantial update to the accessibility guidelines. The name of this set of guidelines is not set but has been code-named “Silver”. This will be a longer-term project carried out at first in parallel with the WCAG 2.1 update to allow it to balance the process of addressing near-term needs and longer-term goals.

User1st: Can you describe a bit of the process of developing updates for the WCAG? 

WCAG WG: The Working Group collects issues from a variety of sources, such as comments that were filed on WCAG 2.0 and its support materials over the years, issues raised within the Working Group, review of publications and conference proceedings produced by various organizations, proposals developed by Working Group participants, and comprehensive submissions prepared by the topical task forces of the Working Group.

These inputs will be reorganized into guidelines that are generally applicable. For example, overlapping requirements for small mobile device screens and for people with low vision may be better addressed together rather than with separate requirements; or requirements related to simplified layout for mobile devices and for people with cognitive disabilities may be combined.

To ensure backwards compatibility, proposed guidelines will also need to meet the Requirements for WCAG 2.0 which require the success criteria can be understood, realistically implemented, their success verified, and provide real benefits to users with disabilities. The Working Group will also document requirements for WCAG 2.1 to help ensure fair consideration of the various proposals.

Proposed guidelines go through several rounds of review and refinement before they become part of the official standard. The WCAG Working Group brings together people representing a variety of stakeholder groups to consider the various impacts of a proposed guideline and refine the wording. A series of Working Drafts will be published to collect wide review of the emerging set of guidelines. When the draft guidelines have stabilized they go through testing and ratification phases in the W3C, as described in How WAI Develops Accessibility Guidelines through the W3C Process.

User1st: What are some of the challenges that arise when making changes to such a widely used and impactful set of guidelines? 

WCAG WG: Stability versus evolution is one of the critical challenges. It is important that the guidance web developers follow remain stable over time, so developers don’t have to relearn the guidance and to ensure that different sites are following the same guidance. On the other hand, technology is evolving rapidly and needs to be addressed continually. Determining the right time and way to update guidance is a big challenge.

When writing guidelines it is important to ensure that they meet the requirements of general applicability, usefulness, distinctiveness, etc. Yet the needs of users with disabilities are not always expressed so easily. It is difficult to balance the impact of specific requirements to certain groups of people versus the practical aspects of implementation.

User1st: Moving from WCAG 1.0 to 2.0 took nearly 9 years, how much time will the change from 2.0 to 2.1 take to be complete and ready for implementation? 

WCAG WG: The change from WCAG 1.0 to 2.0 was a complete redesign and rewrite of the guidelines and its entire model. WCAG 2.1, while an ambitious project, is by design a more constrained update, a “dot-release”. The Working Group intends to follow a strict timeline. While this timeline cannot be guaranteed and will involve trade-offs between timeliness and content, it is important to ensure that robust normative guidance is made available reasonably quickly. Once WCAG 2.1 is completed, the Working Group will evaluate the need for subsequent guidelines, including “Silver” project and potentially additional dot-releases in the interim.

User1st: The update is meant to work in harmony with WCAG 2.0 and to build off its guidelines. Are there any ideas or concepts in WCAG 2.0 that are not as relevant today as they were 9 years ago? 

WCAG WG: WCAG 2.0 was designed to be technology-agnostic and has been quite successful in this regard, so it continues to be a solid base for web accessibility. Changes in technology have created some needs for new guidance that is additional to WCAG 2.0, but not that supercedes WCAG 2.0. The key example is a requirement for keyboard interface support in all content, which does not by itself provide the intended accessibility benefits on devices that primarily use a touch interface. Therefore there is a need for touch accessibility guidance, but the keyboard interface relevant is still relevant as a fallback accessibility measure.

User1st: Will any existing techniques be removed from the updated guidelines? 

WCAG WG: Techniques are complementary to the WCAG standard, to provide developers with more situational and technology-specific guidance, for example on how to provide form labels in a particular version of HTML or other web technology. They are informative (not normative standards), and follow a slightly different W3C process. This allows them to be updated more easily and more frequently. The WCAG working group has been updating the Techniques and Failures every six months. This includes adding new ones, removing obsolete ones, and updating others to provide more clarity. This maintenance is expected to continue with WCAG 2.1, with new Techniques and Failures for the newly added requirements.

User1st: Is the W3C WG going to base the WCAG technique changes mainly on semantics such as aria attributes, or is it planning to add new attributes? Example: instead of tags like <h> it might be asking to use attributes such as <h aria-disabled=”true”>. Generally attributes are a major changes from tags, and is considered to be a semantic change, even though HTML5 has some semantics as tags name as <header>, <main>, which is the main section of the page etc. 

WCAG WG: When new accessibility features become available, such as new semantics in HTML 5 and WAI-ARIA, the WCAG working group tries to reflect these improvements in new or updated Techniques, and welcomes submissions from the public to help develop and update Techniques. New Techniques normally are added to the suite alongside existing ones. Usually there are several ways to meet requirements, and the Techniques document some of the possible ways for meeting requirements. In many circumstances it is still appropriate to follow older techniques even when newer ones are available. It is up to the developer to select the most appropriate implementation, depending on their particular context and the available accessibility support in web browsers and assistive technologies.

The WCAG Working Group does not create attributes or other content technologies. It documents and recommends approaches to meet the requirements of WCAG when using various technologies. When using HTML, it is generally recommended to use the native elements and attributes of HTML5 where possible, and to use features of WAI-ARIA to enhance accessibility where needed.

User1st: We’re very excited to see dedicated sections focusing on cognitive and learning disabilities. Can you give us some information on how WCAG 2.1 will address these particular topics?

WCAG WG: This field has been evolving rapidly in recent years. This includes new research, tools, and awareness about the relevance and importance to address. The Cognitive and Learning Disabilities Accessibility Task Force has been very active in collecting research and documenting issues. It published Cognitive Accessibility User Research that describes the needs of people with various cognitive and learning disabilities, and will soon publish a set of issue papers (unofficial draft) that comprehensively explains how these needs intersect with various situations. It has also proposed a set of additional semantics to allow authors to enable custom user agent support; this has been taken up in the ARIA Working Group as Personalization Semantics (unofficial draft). These materials are being used in a gap analysis of accessibility requirements and proposal for new WCAG guidance.

User1st: At what point did you realize the need for separate mobile guidelines? 

WCAG WG: The need to provide additional guidance has emerged over the years as the group continued to receive questions about how to make content accessible that is primarily viewed on a small screen and interacted with via a touch interface. This need coalesced into the decision to create the mobile accessibility task force in 2013.

The aim of this work, however, is to incorporate mobile accessibility requirements rather than to create separate guidelines. The web is becoming ever more ubiquitous, with no clear boundary between one type of device and the other. For example, many laptops, ticket machines, and home appliances are now equipped with touch screens, in addition to mobile devices. Sensors, cameras, and gesture interaction is also not limited to mobile devices. So it is not likely that there will be Success Criteria in WCAG 2.1 exclusively for mobile. They would more likely be formulated more broadly, such as requirements for touch screens, gesture interaction, or responsive design, which would then apply to any device and end-user.

User1st: Can you give us some examples of issues that WCAG 2.0 couldn’t address but 2.1 will be able to? 

WCAG WG: At the time of WCAG 2.0 development, touch screens were generally not as widespread and not considered to be accessible. Advances in sensors, operating systems, and decrease of the cost of touch screens entirely changed the landscape of computing. Also the increased use of gestures and detection, for example a television screen recognizing that you are looking at it and waving your hands to switch the channel, was not mainstream computing back then. Today it is, and WCAG 2.0 does not provide full clarity on some of these aspects. We hope that much of these challenges we know of today can be addressed in WCAG 2.1.

User1st: Moving away a bit from the specifics of the WCAG 2.1 update—individuals who use assistive devices are in a unique position regarding digital interfaces—if the assistive device doesn’t work on a particular site, completing a flow may be difficult or impossible. Are there any plans to address testing best method practices any time soon, or to build a task force for this? 
WCAG WG: The WCAG working group recently created the Accessibility Conformance Testing (ACT) Task Force. The goal of this task force is to first develop a standardized format and validation method for accessibility testing procedures, to facilitate the development of testing procedures according to this a common standard. Initially there will be a stronger focus on automated testing but also semi-automated testing is in scope of this new work. We welcome participation in this effort too.

User1st: How, if at all, will the updates being developed for WCAG 2.1 help governments, lawmakers, and/or companies adopt accessibility standards more willingly or easily?

WCAG WG: Addressing some of the known issues in WCAG 2.0 will help implement accessibility more consistently. Many of the questions that currently cause confusion for developers and website owners will be clarified through new requirements and improved accompanying materials such as the Techniques. This will make it easier for organizations to adopt and implement the standard.