Implement new Success Criteria from WCAG 2.1

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

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.

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.

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

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

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

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.

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.

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.

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

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.

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

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 :-)

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

#2910102: Improve icon colour contrast for WCAG 2.1

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

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.

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.

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

@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:

• Conventional controls, fields, and links - Log In and Log Out
• Conventional controls, fields, and links - Search

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.

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)

The Plain Language SCs were removed several working drafts ago.

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.

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

The graphics contrast SC changed it's name AGAIN. Now it's called Success Criterion 1.4.11 Non-text Contrast.

WCAG 2.1 reached another milestone this week. It's moved from Candidate recommendation to Proposed recomendation.

An important thing about this milestone is that none of the new success criteria are considered "at risk" any more.

"Non-text contrast" is staying! So that means we should now classify some of Drupal's mediocre focus styles as bugs.

A good write-up of the new stuff in this blog article from Deque - WCAG 2.1: What is Next for Accessibility Guidelines. A really useful thing n this article is how it uses personas to illustrate who benefits from the new success criteria.

Some new success criteria names and numbers have changed, so the issue summary needs updated here.

I've been thinking about 4.1.3 Status Changes (it went though several other names and numbers in earlier drafts). So far, I think our existing Drupal.announce() already conforms to this (emphasis mine):

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

As of May 2018, the Understanding Status Messages supporting docs are still a work-in-progress. In that document, the techniques are about using the role attribute (alert, status, etc) which declare an aria-live region implicitly. Our Drupal.announce() doesn't use a role, but instead declares the aria-live property explicitly.

The wording of the success criterion says you can do it though roles OR properties, so I think this means Drupal.announce() is already conforming.

Updated issue summary, fixed various name/number changes to match the April 2018 proposed recommendation.

This is a really great article about the new "Label in Name" criterion: Improving web navigation for speech recognition users.

It's given me an idea for how we do a review of our existing codebase for this. Basically, we need to look at ALL instances where we use aria-label, aria-labelledby, and class="visually-hidden" to see if there are any discrepancies between the computed accessible name vs what's actually displayed. There are lots of these which will need to be checked, but I think we can do it methodically.

WCAG 2.1 is now a full W3C Recommendation.

I think we should now officially target WCAG 2.1 for all new features coming into Drupal core. It's very handy timing for us, as we're just kicking off the work for #2957457: Proposal: Modernize the look/feel of the Seven admin theme.

For existing modules, themes, etc, we need to assess what retro-fitting will need to be done. We already have a number of child issues focused on some of the new success criteria. I think having a task issue to assess core for each new SC would be a way to organize this. For example #2958654: Assess JavaScript behaviours for WCAG 2.1 Pointer Cancellation. Some of these might have children of their own, to fix specific instances that are identified.

I'll dig though the final changelog and update the issue summary if needed.