Web Content Accessibility Guidelines (WCAG) 2.2 in Development
Author(s) and publish date
- By:
-
-
Alastair Campbell
-
- Published:
The Accessibility Guidelines Working Group (AG WG) is happy to announce the First Public Working Draft of the Web Content Accessibility Guidelines (WCAG) 2.2.
The structure and content of WCAG 2.2 is the same as 2.1 and 2.0. Version 2.2 will include new accessibility requirements, called “success criteria”.
Background
There were potential success criteria discussed during the development of 2.1 that needed more time or needed other specifications to mature. AG WG has continued to work on those potential success criteria. When a new success criterion is approved by the Working Group along with its supporting Understanding WCAG document and at least one Technique, then it will be added to the WCAG 2.2 Draft for wider review.
Side note: The AG WG is currently not planning to publish another version of WCAG 2, that is, not do a WCAG 2.3 — although that might change. We are working on a different accessibility standard. In-progress, un-approved requirements for the standard are available. We will announce when information is more stable on future web accessibility standards.
New success criteria
In this First Public Working Draft there is one new success criterion: “Focus visible (Enhanced)” at level AA. The “Focus visible” success criteria from WCAG 2.0 and 2.1 has been changed from level AA to level A.
We expect to add up to 12 more success criteria to WCAG 2.2. The new success criteria address user needs of people with cognitive or learning disabilities, users of mobile devices, and users of ebooks. Note that success criteria in the Drafts may change or be removed before the final WCAG 2.2 is published.
You will be able to review additional success criteria that AG WG has approved in the in-progress, unpublished “Editors’ Draft”.
Your Comments
Public feedback is really important to us. Based on this feedback, the proposed success criteria could be changed. We want to hear from users, authors, tool developers, policy makers, and others about benefits from the new proposed success criteria, as well as how achievable you feel it is to conform to the new success criteria. The main places to comment are on Github, and to the mailing list.
Schedule
Over the next couple of months, the AG WG will process other proposed success criteria, and input from the public. We plan to publish a final draft (W3C Candidate Recommendation) in June 2020, and hope to publish the final version of WCAG 2.2 as a “W3C Recommendation” web standard later in 2020.
To get announcements of updated drafts for review in e-mail, tweets, and RSS, see Get WAI News.
I'm a big fan of the new success criteria going from level AA to level A.
As an advisor on the national legislation on the Web Accessibility Directive on websites and mobile applications, it is my experience, that it is an important criteria - and an upgrade from AA to A will adress and underline that.
Sans serif font should be required for conformance not only as advisory. It is recommended as easier to read for persons with dyslexia among others. It is not widely known information so organisations especially using third party providers can have inaccessible fonts while still technically passing a WCAG conformance audit.
Hi Andre,
I appreciate there is an advantage for a lot of users, but it is not a universal finding. There are also 'good' serif fonts that can be better than a 'bad' sans-serif font, so it would be a very difficult requirement to scope properly.
What the guidelines did include in WCAG 2.1 is the text-spacing requirement. If users over-ride the font on a website, it should not break the layout or become unreadable.
I've added links above if you would like to make an issue in github or email the working group.
From my personal experience, especially to define when to meet the W3C criteria the following topics would need a more concrete specification:
- Landmarks: what is a must have and what not? The most common layouts for apps and websites should be provided with examples.
- Keyboard access: is an endless TAB sequence sufficient for keyboard access? I think no, a max. number for TAB key presses to reach a certain UI-component should be defined or at least a required alternative (e.g. a available landmark) to be able to quickly reach this UI-component.
- Keyboard access: at the moment advanced keyboard navigation like shown in the WAI-Aria Best Practices within components sound like a nice to have feature, but because the required amount of work - websites providing the option to use Home, End, Arrow keys e.g. to navigate in trees, listings are super rare. A clear definition when this is a must have e.g. if navigation contains more than 10 children would be helpful.
- Another ideas to simplify keyboard access patterns would be to introduce "subroles" for components like e.g. "navigation-child" and "navigation-parent" and then providing the above keyboard support via in-browser functionality, so Home, End, Arrow Keys would work even if the webpage does not provide the JS-Scripting for this.
The best place to make these sort of points is on the github repository, on those particular items:
- There is a technique for ARIA landmarks.
- There are so many types of site and experience, in a specification that aims to be universally applicable it is very difficult to include numerical limits of that type.
- Again, a strict number would be hard to define & support, it has to be a decision of equivalence. I.e. given the interaction used, what is the appropriate structure (1.3.1 info & relationships) and name/role/value (4.1.2).
- That sounds like a good idea, it would be something for browsers to implement (as part of the web-platform work I assume).
For focus enhance I would like to suggest you to please add, (do not focus non actionable item), do you think people who are using only keyboard they can try to click on focus items.
Please try to mention i found some sites they allow example dialog content focused without actionable.
and strictly add some guidelines for UX designers. I have mentioned you on twitter with example.
Hi Harnam,
I don't think adding something about non-actionable items would fit into the focus-visible criteria, but if you comment on github that could be added to requirements for the next update. (Link in the article.)
Sites with un-actionable dialogues would fail 2.1.1 keyboard operability.
Accessibility guidelines tend not to be the place for strict UX/design rules, they have to apply across different sites and contexts.
Hi Alastair ,
I just wanted to follow up on the conformance level for the Focus Enhanced it mentions that it has changed from Level AA to Level A . But I do not see the update in the Editor's draft . Is there a reason as to why.
The "Focus Visible Enhanced" criterion is new, and is at level AA.
The change noted in the blog post above is that the WCAG 2.0 criterion "Focus Visible" has moved from level AA to A:
https://www.w3.org/TR/WCAG22/#focus-visible