Problem/Motivation

The W3C is preparing an update to the Web Content Accessibility Guidelines. A working draft of WCAG 2.1 is available, and it proposes new Success Criteria. Our current accessibility gate aims to satisfy WCAG Success Criteria at levels A and AA. This looks like a very significant expansion of WCAG, so we can expect it to affect Drupal in a lot of challenging ways.

The WCAG 2.1 timeline sets December 2017 as the target for a Candidate Recommendation stage, graduating to a full Recommendation in mid-2018.

An update to the WCAG supporting documents ("Understanding WCAG") is also proposed (this is where the longer details, examples, testing notes, and techniques live).

Confirmed new WCAG Success Criteria

As of 7th December 2017, the following new Success Criteria (at level A and AA) are confirmed.

Level A:
Level AA:

Note that some new Success Criteria are also being introduced at level AAA, but since our target is level AA it is not essential that we address these.

Level AAA:

Proposed resolution

Drupal 8 is already leading the way as an accessible CMS. Let's hold on to this achievement :-)

  • Discuss the impact, and come up with approaches!
  • File child issues for anything we know we must address. (For tracking our progress, please use this issue as the parent and/or the "wcag21" tag.)
  • Get off the island, and contribute to the W3C process? The new success criteria are being refined in GitHub issues at w3c/wcag21.

Remaining tasks

  • Monitor the progress of the new success criteria, and refine our approaches as they mature.
  • It's probably OK to wait until individual criteria have been finalized, before coming up with our approaches.
  • Some proposed Success Criteria are proving controversial, so it makes sense to wait for the Candidate Recommendation stage, and implementation consensus in the wider accessibility community. Update: as of the December 2017 working draft, the list of new Success Criteria is supposedly finalized (according to the WCAG 2.1 Timeline).

User interface changes

YES. UI and theme changes are expected, e.g.

  • SC 1.4.11 Graphics Contrast - some of our focus styles don't pass this.
    • Pale blue halo around a blue button
    • Mild background colour change when drop-button arrow is focused.
  • Some proposed success criteria address cognitive accessibility at A and AA levels. There may be a need to improve some of our UI text to satisfy SC 2.4.12 Label In Name.

@todo: Flesh this out when we know more, especially when it reaches the candidate recommendation stage

API changes

None expected, as yet.

Data model changes

None expected, as yet.

Further Reading

Comments

andrewmacpherson created an issue. See original summary.

andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

Just putting this into play. I don't know the schedule for bringing WCAG 2.1 to full recommendation status.

andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

Several of the new success criteria amount to making our CSS theming more robust for when a user employs built-in browser features like enlarging text, changing fonts, or using Windows' high-contrast themes:

Resize content
Printing
Adapting text

More manual testing will be needed for this.

Pipe dream: I wonder if headless browsers and visual linting tools can simulate text enlarging? I know it's possible to set a viewport size with PhantomJS for instance.

andrewmacpherson’s picture

Target size formalizes an established practice for touch screens. We already made this an aspect of the D8 mobile first initiative, so it'll be interesting to see if we already meet the requirements.

andrewmacpherson’s picture

We are certainly going to have to update our style guide to meet User Interface Component Contrast (minimum).

Among other things, this will require our focus and hover styles to have strong colours. Our "blue-halo" around buttons currently doesn't meet the proposed SC (as I read it).

andrewmacpherson’s picture

Good news! I believe our custom tooltips from Shortcut module already satisfy Popup Interference:

For informational content that appears on hover or focus, one of the following is true:

Turn Off
The informational content can be turned off
Not obscure
The informational content does not obsure the triggering content

mgifford’s picture

This is great! Thanks so much @andrewmacpherson...

It's nice to have a comparison for how these things are changing going forward. I'm trying to draw this outline for the migration from the old 1997 USA legislation to the "new" 2008 WCAG 2.0 guidelines.

https://github.com/mgifford/section508-to-wcag2aa

Ultimately people need to be aware of the changes and keep working for an ever-evolving internet.

mgifford’s picture

yoroy’s picture

Thanks for tracking this. When you feel there's enough clarity on what we should work on (esp. relating to Seven theme visual changes) it could be useful to present this during one of the Drupal UX meetings: https://calendar.google.com/calendar/embed?src=jhj7p0u7link8vvjdqqsqr5qt...

andrewmacpherson’s picture

Issue summary: View changes

Updating the issue summary:

  • A new working draft is of WCAG 2.1 is out (19 April 2017).
  • Added some examples in the UI changes section.
  • I found the WCAG 2.1 Timeline. They are aiming for a Candidate Recommendation in Dec 2017. We can probably wait until then before making detailed plans of our own.
  • So far the Working Draft only covers the update to the core WCAG recommendation. The "Understanding WCAG" document will also be updated, but this has just been started. It's where the longer explanations for each Success Criterion will live (including examples, code snippets, techniques, and known failures).
andrewmacpherson’s picture

Also, I've been digging through the w3c/wcag21 GitHub issues to get a better feel for what's coming. Lots of parties have provided feedback.

It still feels like early days for this; the really useful stuff will be in the extended "Understanding WCAG" documents. The User Interface Component Contrast (minimum) SC has a quite a lot of this already.

andrewmacpherson’s picture

mgifford’s picture

Issue tags: +wcag21

Have to start a WCAG 2.1 tag.

andrewmacpherson’s picture

The latest WCAG 2.1 working draft (16 August 2017) is out, and it's a milestone draft because it finalizes the list of new success criteria (which have sufficient consensus).

I'll update this issue soon-ish, but in the meantime here is a nice article summarizing the new success criteria: WCAG 2.1: The final list of candidate Success Criteria is here.

UPDATE: I think I misunderstood the WCAG 2.1 timeline, and the September working draft will finalise the list of new success criteria. The David MacDonald article I linked here includes a few SCs which are due to be included in the September draft, or are awaiting approval. Still, we can start looking for stuff which is actionable and spin out new issues.

mgifford’s picture

Have to add these two links from this weekend:

Video from DrupalNorth - https://www.youtube.com/watch?v=FbStEVeQ8g4
David MacDonald's summary - http://davidmacd.com/blog/wcag-2.1-quick-guide.html

andrewmacpherson’s picture

Issue summary: View changes

Yes, I'm looking forward to watching that video.
We both found the David MacDonald article; he's been updating it over the last few months. So little has been published about WCAG 2.1 outside of the W3C mailing lists and GitHub issues.

@mgifford I'd like to hear your thoughts about any parts of Drupal core this might impact. In particular:

  • Which parts do you think are going to present the greatest difficulty?
  • Likewise, do you see any quick wins?
  • Do any SCs need a particular skill-set that we're lacking, or we need to ask other maintainers for help with?

This is a must-highlight issue for the accessibility core conversation at DrupalCon Vienna. The WCAG 2.1 timeline says we can expect a final list of success criteria about a week before DrupalCon. That's perfect timing, for starting a wider discussion about this Drupal core plan.

I've been thinking about how the WCAG 2.1 timeline relates to the Drupal 8 release cycle, and our accessibility gate. Here's how I imagine our plan:

  • Our accessibility gate currently calls for WCAG 2.0 level AA.
  • Presumably, we will update our accessibility gate to target WCAG 2.1 level AA.
  • Let's assume WCAG 2.1 keeps to it's timeline, and becomes a full W3C recommendation in mid-2018, around the time we are preparing an alpha release of Drupal 8.6.0 ...
  • ... Does this mean we have to hurry to meet WCAG 2.1 in time for the stable release of Drupal 8.6.0?
  • NO. When WCAG 2.1 reaches Recommendation status, our accessibility gate will still target WCAG 2.0.
  • Now the hard fun begins. Officially (press release sense) we'll be extending our WCAG coverage to adress the new Success Criteria in WCAG 2.1.
  • Once we feel we have reached a sufficient level of WCAG 2.1 coverage, say 90% confidence, then we can raise the accessibility gate behind us, with much fanfare: official announcements; podcast interviews; blog articles; the works. This would coincide with a D8 point release, hopefully sometime between the 8.7.0 and 8.9.0 milestones.

I'm comfortable with the idea that our the WCAG 2.1 work will be spread over a year. We can aim for enough coverage to raise the accessibility gate over 2 minor releases, say.

Accessibility holds the place of a quality assurance gate in our project governance, rather than a bold-new-features strategic initiative. However I feel the WCAG 2.1 update is sufficiently important that we should consider this plan at the level of the Drupal Core Product Goals issues, because accessibility has become a key product differentiator for Drupal.

andrewmacpherson’s picture

Issue summary: View changes

Issue summary still needs an update, for the new SCs which have reached consensus since April.

mgifford’s picture

Thanks @andrewmacpherson - this will be an interesting one.

It will be interesting to see what their "Purpose of Controls" definition list is. Trying to take what elements are in Core and standardizing could be interesting. I don't know how big this would be.

I added a tag for visual zoom. There are places we aren't meeting 200% let alone 400%:
https://www.drupal.org/project/issues/search?issue_tags=visualzoom

I don't think we'll have any way to deal with "Graphic Contrast".

Some things like "Adapting Text" really won't be something we can easily review until there are automated tools to check out Core.

I've spent a bit of time thinking about this today. Definitely need to break it down into what we can accomplish in Core.

andrewmacpherson’s picture

Another way of looking at the timeline. Let's prioritise the WCAG 2.1 level A changes first...

  • Autumn 2017 - D8.4.0 release
  • January 2018 - WCAG 2.1 Candidate Recomendation
  • Review new level A success criteria, start Drupal issues.
  • Spring 2018 - D8.5.0 release
  • July 2018 WCAG 2.1 Recomendation
  • Work towards addressing new WCAG 2.1 level A success criteria, for D8.6.0 and D8.7.0
  • Review new level AA success criteria, start Drupal issues.
  • Autumn 2018 - Drupal 8.6.0 release
  • Work towards addressing new WCAG 2.1 level AA sucess criteria, for D8.7.0 and D8.8.0
  • Spring 2019 - D8.7.0 release
  • Hopefully we've done the WCAG 2.1 level A success criteria, and now we're working on the remaining level AA stuff.
  • Autumn 2019 - D8.8.0 release. Raise accessibility gate to WCAG 2.1 level AA.
andrewmacpherson’s picture

andrewmacpherson’s picture

I've mentioned this WCAG 2.1 plan in the wider "product goals" plan at #2905741-57: *DRAFT* Proposed product goals for Drupal 8.5/8.6(+) core

webchick’s picture

Component: Proposed Plan » Active Initiative
Priority: Normal » Major

Talked to the other product managers. Since we pretty much have to do this stuff in order keep our WCAG AA target, I'm moving this to a "major", "active initiative."

andrewmacpherson’s picture

Title: Prepare for new Success Criteria in WCAG 2.1 » Implement new Success Criteria from WCAG 2.1
Issue tags: +Needs issue summary update

Thanks @webchick! This recognizes a continuing commitment to accessibility in Drupal, and provides important assurance for anyone using (or evaluating) Drupal.

Addressing WCAG 2.1 is now a case of "when, not if". You've seen my musings about the timeline for this plan - are those OK for an active initiative?

The Sept 2017 working draft is out now. As I understand the upstream W3C-WAI roadmap, this month finalizes the new success criteria. From here on the WAI activity us about refining a candidate recommendation and updating the supporting documents (understanding WCAG, techniques, and known failures).

TODO: update the issue summary to reflect the new SC list. I'm conference-hopping right now, so this might have to wait to my post-Vienna catch-up time.

We are now ready to spin-off some task issues for this plan.

I'll be speaking about WCAG 2.1 in the DrupalCon Vienna accessibility core conversation session.

I think this plan deserves a more determined-sounding title now :-)

webchick’s picture

January 2018 is code freeze for 8.5 (see dates https://www.drupal.org/core/release-cycle-overview), so "Review new level A success criteria, start Drupal issues" at that point sounds a bit late in the game. Ideally, we should try and do as much exploration in advance of code freeze (or, like, now) as we can, I think, in case some of this stuff requires new libraries, new features, new APIs, etc. that can only go in minor releases. I don't know the W3C process well enough to know if we do this exploration at "working draft" stage if we'll end up wasting time chasing rabbits, or if a working draft is pretty darn close to what the final thing will be, though.

However, in general, there's no problem with an initiative taking multiple years (they're major hunks of work :)), especially when there are external factors like with this one.

Let's catch up in Vienna!

yoroy’s picture

yoroy’s picture

Another issue where it would be good to clarify how it relates to this one: #2893640: Modernize ARIA usage, in line with ARIA 1.1 and the ARIA Authoring Practices guide.

andrewmacpherson’s picture

We have our first reasonably-scoped child issue for this plan!

#2910102: Improve icon colour contrast for WCAG 2.1

andrewmacpherson’s picture

@yoroy - The other two issue are pretty broad plans in their own right, and would be worth doing regardless of WCAG 2.1, but they both kinda overlap with this one. So let's say they are related issues, not child issues.

Re: #27 - #2894237: Make core themes more robust in Windows High-Contrast mode

WCAG 2.1 brings in a new success criterion for contrast of UI elements, as well as an broader emphasis on adaptable content in general. WCAG 2.0 only addressed text contrast.

The sort of thing we can do for Windows' High Contrast which relates to WCAG 2.1 is making more robust use of borders. For example see the images in comment 3 of #2894237-3: Make core themes more robust in Windows High-Contrast mode. Update (20 Nov 2017): The relevant WCAG 2.1 success criterion is 1.4.12 User Interface Component Contrast (Minimum). It's not clear if a border around a dialog would be considered "essential" but it could certainly help.

The goal of the Windows High Contrast plan, as I see it, is to make Drupal work well with yet another well-known (and predictable, yay!) piece of assistive technology, rather than just "address WCAG". This is similar to how the Inline Form Errors module makes Drupal much easier to use with a screen magnifier, where the proximity matters.

Re: #28 - #2893640: Modernize ARIA usage, in line with ARIA 1.1 and the ARIA Authoring Practices guide.

This is more concerned with other W3C recs than with WCAG particularly. ARIA is really just a technique that can address various WCAG success criteria, the means rather than the end. The point of the "modernize ARIA" issue is that ARIA is itself moving forward, in terms of the specification, browser and AT implementations, and best practices.

In terms of WCAG 2.1, ARIA can help to address (among others) SC 1.3.4 Purpose of Controls AA and SC 1.3.5 Contextual Information AAA.

Update (18th Oct 2017): using ARIA will be an important technique for addressing 3.2.7 Change of Content (AA) too.

andrewmacpherson’s picture

Issue summary: View changes
Issue tags: -Needs issue summary update

Updating the list of new SCs per the September 2017 WCAG 2.1 working draft. Hopefully this is the final list.

I've organized them by A/AA level here. Also included the new level AAA ones for completeness,even though our accessibility gate won't require us to implement them. It's worth knowing that there are "Target Size" SCs at level AA and AAA, for instance.

andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

We already have a bunch of issues aimed at extending use of Drupal.announce() to cover all of the filterable lists in Drupal core. For example #2805499: Provide screen reader feedback when Views List is filtered by name or description.

As far as WCAG 2.0 goes, filtering like this might count as a "change of context" under SC 3.2.2 On Input (level A), but it's kind-of borderline IMO. It does rearrange some content, but doesn't significantly change the meaning of the page.

Looking at the new WCAG 2.1 SC 3.2.7 Change of Content (level AA), it's a clear match for our filterable lists. It sounds like we certainly need to provide feedback for dynamic list filters. The supporting docs ("understanding SC 3.2.7") are still being devised, but the main text defining the Success Criterion is clear enough. It formalizes something that the accessibility community has been recommending for a few years now, which is exactly why we built Drupal.announce() in the first place.

So I think we can now re-classify these filter-list announcement issues as bug reports under WCAG 2.1. Many of them are close to being ready - so we're already addressing this new success criterion!

I'll set this issue as the parent for these issues, to spread some awareness of WCAG 2.1 amongst contributors.

andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

@webchick Re: #26,

I don't know the W3C process well enough to know if we do this exploration at "working draft" stage if we'll end up wasting time chasing rabbits, or if a working draft is pretty darn close to what the final thing will be, though.

Me neither - we've certainly started early though. I'm currently looking at it this way:

  • Each success criterion has a "short definition", which appears in WCAG 2.0 (and 2.1) Recommendation document.
  • Each success criterion also has a set of supplementary material: commentary, personas, examples, techniques, known failures, testing procedures, etc.. These live in the Understanding WCAG and Techniques for WCAG documents, which have the W3C status of "Note".
  • As of the Sept 2017 working draft, the list of new criteria is finalized, and the short definitions are (hopefully) stable. This is enough for us to start identifying child issues for this plan now.
  • For implementing those child issues, in many cases we probably want to wait for the understanding/techniques material to mature. Currently, some success criteria are further developed than others.
  • For some issues, the short-definitions may be enough for us to get started immediately. The child issues around extending Drupal.announce() coverage are goods examples of this, per #33.

I've updated the issue summary with the new SCs grouped by priority. Some child issues have been identified.

andrewmacpherson’s picture

@mifford - re: #20

The working draft has lists of conventional names for "Purpose of Controls", grouped as buttons/controls, form fields, and links.

I made some comments about these in the w3c/wcagG21 GitHub issues:

andrewmacpherson’s picture

I've just noticed that as well as the new success criteria, the WCAG 2.1 working draft is also bringing in some errata for existing WCAG 2.0 success criteria.

From the WCAG 2.1 changelog:

2017-05-24: Added "color" to WCAG 2.0 1.3.3 Sensory Characteristics, and removed note about color from that and 1.4.1 Use of Color, to reflect a WCAG 2.0 erratum.

Hopefully the WCAG 2.0 stuff will not change much. It seems like these errata are just minor clarifications.

David_Rothstein’s picture

Issue tags: +needs backport to D7

It would be nice to tag individual child issues for backport also (where possible/appropriate).

andrewmacpherson’s picture

Issue summary: View changes

The Dec 2017 working draft is out. This is the "last call" draft, with the Candidate Recommendation scheduled for late January 2018.

Some new SCs have changed name and/or number. One has changed conformance level (to AAA, less urgent). One has been merged into another.

  • 1.3.4 Purpose of Controls -> 1.3.4 Identify Common Purpose
  • 1.4.10 Zoom Content -> 1.4.10 Reflow
  • 1.4.12 User Interface Component Contrast has been removed/merged into 1.4.11 Graphics Contrast. This was expected, older drafts said so.
  • 1.4.13 Adapting Text -> 1.4.12 Text Spacing
  • 1.4.14 Content on Hover or Focus -> 1.4.13 Content on Hover or Focus
  • 2.4.12 Accessible Name -> 2.4.12 Label In Name
  • 2.6.1 Device Sensors -> 2.6.1 Motion Actuation
  • 3.2.6 Accidental Activation -> 2.5.2 Pointer Cancellation
  • 3.2.7 Change of Content -> 3.2.6 Status Changes
  • 2.5.4 Target Size (No Exception) -> 2.5.4 Target Size (Enhanced)
  • 2.5.2 Concurrent Input Mechanisms (AA) -> 2.5.5 Concurrent Input Mechanisms (AAA)
andrewmacpherson’s picture

Issue summary: View changes

The Plain Language SCs were removed several working drafts ago.

andrewmacpherson’s picture

Issue summary: View changes

There's a nice introduction to WCAG 2.1 at WCAG 2.1 and Silver (AG): What is Next for Accessibility Guidelines. It includes persona quotes for each of the new success criteria.

andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

WCAG 2.1 reached the Candidate Recomendation stage today. I'll read the change log and update the issue summary here with anything important.

mgifford’s picture