This is going to be a tracker for all issues covering (not just obeying) ATAG 2.0 conformance, sorted by ATAG 2.0 norm.
This tracker should help us achieve the stated goal of WCAG 2.0 and ATAG 2.0 level AA conformity for Drupal core.

Please help adding relevant, preexisting issues to this list, before creating many new issues that no one takes care of and that end up not being manageable!

Section A: Make the authoring tool user interface accessible

A.1. Authoring tool user interfaces must follow applicable accessibility guidelines

A.1.1. Accessible web-based UI

A.1.1.1 (A-AAA) Web-Based Accessible (WCAG)

A.1.2. Accessible non-web-based UI - irrelevant to Drupal

A.2. Editing-views must be perceivable

A.2.1. Make alternative content available to authors

A.2.1.1 (A) Text Alternatives for Rendered Non-Text Content

#2034999: [meta] Comply with WCAG 1.1: Text Alternatives

A.2.1.2 (AA) Alternatives for Rendered Time-Based Media

A.2.2. Editing-view presentation can be programmatically determined (UI)

A.2.2.1 (A) Editing-View Status Indicators
A.2.2.2 (AA) Access to Rendered Text Properties

A.3. Editing-views must be operable

A.3.1. Provide keyboard access to authoring features (UI)

A.3.1.1 (A) Keyboard Access (Minimum)
A.3.1.2 (AA) No Keyboard Traps
A.3.1.3 (AA) Efficient Keyboard Access
A.3.1.4 (AAA) Keyboard Access (Enhanced) - Not aiming for AAA
A.3.1.5 (AAA) Customize Keyboard Access - Not aiming for AAA
A.3.1.6 (AAA) Present Keyboard Commands - Not aiming for AAA

A.3.2. Provide authors with enough time (UI)

A.3.2.1 (A) Auto-Save (Minimum)
A.3.2.2 (A) Timing Adjustable
A.3.2.3 (A) Static Input Components
A.3.2.4 (AAA) Content Edits Saved (Extended) - Not aiming for AAAv

A.3.3. Help authors avoid flashing that could cause seizures (UI)

#2036293: [meta] Comply with WCAG guideline 2.3: Seizures

A.3.4. Enhance navigation and editing via content structure (UI)

A.3.4.1 (A) Navigate By Structure
A.3.4.2 (AAA) Navigate by Programmatic Relationships - Not aiming for AAA

A.3.5. Provide text search of the content (UI)

A.3.5.1 (AA) Text Search

A.3.6. Manage preference settings (UI)

A.3.6.1 (A) Independence of Display
A.3.6.2 (AA) Save Settings
A.3.6.3 (AA) Apply Platform Settings
A.3.6.4 (AAA) Multiple Sets - Not aiming for AAA

A.3.7. Ensure that previews are at least as accessible as in-market user agents (UI)

A.3.7.1 (A) Preview (Minimum)
A.3.7.2 (AAA) Preview (Enhanced) - Not aiming for AAA

A.4. Editing-views must be understandable (UI)

A.4.1. Help authors avoid and correct mistakes (UI)

A.4.1.1 (A) Content Changes Reversible (Minimum)
A.4.1.2 (A) Settings Change Confirmation
A.4.1.3 (AAA) Content Changes Reversible (Enhanced) - Not aiming for AAA

A.4.2. Document the user interface including all accessibility features (UI)

A.4.2.1 (A) Describe Accessibility Features
A.4.2.2 (AA) Document All Features

Section B. Support the production of accessible content

B.1. Fully automatic processes must produce accessible content

B.1.1. Ensure automatically specified content is accessible

B.1.1.1 (A-AAA) Content Auto-Generation After Authoring Sessions (WCAG)
B.1.1.2 (A-AAA) Content Auto-Generation During Authoring Sessions (WCAG)

B.1.2. Ensure accessibility information is preserved

B.1.2.1 (A-AAA) Restructuring and Recoding Transformations (WCAG)
B.1.2.2 (A-AAA) Copy-Paste Inside Authoring Tool (WCAG)
B.1.2.3 (A) Optimizations Preserve Accessibility
B.1.2.4 (A) Text Alternatives for Non-Text Content are Preserved

B.2. Authors must be supported in producing accessible content

B.2.1. Ensure accessible content production is possible

B.2.1.1 (A-AAA) Accessible Content Possible (WCAG)

B.2.2. Guide authors to produce accessible content

B.2.2.1 (A-AAA) Accessible Option Prominence (WCAG)
B.2.2.2 (A-AAA) Setting Accessibility Properties (WCAG)

B.2.3. Assist authors with managing alternative content for non-text content

B.2.3.1 (A-AAA) Alternative Content is Editable (WCAG)
B.2.3.2 (A) Repair of Text Alternatives During Authoring Sessions
B.2.3.3 (A) Repair of Text Alternatives After Authoring Sessions
B.2.3.4 (AAA) Save for Reuse

B.2.4. Assist authors with accessible templates

B.2.4.1 (A-AAA) Accessible Template Options (WCAG)
B.2.4.2 (AA) Identify Template Accessibility (Minimum)
B.2.4.3 (AA) Author-Created Templates
B.2.4.4 (AAA) Identify Template Accessibility (Enhanced) - Not aiming for AAA

B.2.5. Assist authors with accessible pre-authored content

B.2.5.1 (AA) Pre-Authored Content Selection Mechanism
B.2.5.2 (AAA) Pre-Authored Content Accessibility Status

B.3. Authors must be supported in improving the accessibility of existing content

B.3.1. Assist authors in checking for accessibility problems

B.3.1.1 (A-AAA) Checking Assistance (WCAG)

http://quailjs.org/

B.3.1.2 (A) Help Authors Decide
B.3.1.3 (A) Help Authors Locate
B.3.1.4 (AA) Status Report
B.3.1.5 (AA) Programmatic Association of Results

B.3.2. Assist authors in repairing accessibility problems

B.3.2.1 (A-AAA) Repair Assistance (WCAG)

B.4. Authoring tools must promoted and integrate their accessibility features

B.4.1. Ensure the availability of features that support the production of accessible content

B.4.1.1 (A) Features Active by Default
B.4.1.2 (A) Option to Reactivate Features
B.4.1.3 (AA) Feature Deactivation Warning
B.4.1.4 (AA) Feature Prominence

B.4.2. Ensure that documentation promotes the production of accessible content

B.4.2.1 (A-AAA) Model Practice (WCAG)
B.4.2.2 (A) Feature Instructions
B.4.2.3 (AAA) Tutorial - Not aiming for AAA
B.4.2.4 (AAA) Instruction Index - Not aiming for AAA

(see latest version of Implementing ATAG 2.0)

per module / subsystem:

CKEditor

#1879430: [meta] Find and report any accessibility issue of CKEditor and its Drupal integration

Views

#1802678: [META] Views: accessibility review
#1806278: Test whether Views conforms to WCAG 2.0 and ATAG 2.0

See also:

#2034915: [meta] Track progress in WCAG 2.0 conformance

Comments

Pancho’s picture

Issue summary: View changes

Link to WCAG

Pancho’s picture

Issue summary: View changes

Restructure table of reference flattening hierarchy. Also adding the individual success criteria.

Pancho’s picture

Issue summary: View changes

Adding a missing criterion. Also marking WCAG level dependent criteria as "(A-AAA)"

Pancho’s picture

mgifford’s picture

Issue summary: View changes

add link to atag

mgifford’s picture

This is an amazing start @Pancho - I'll alert folks at the W3C who are working on this and looking for examples.

Just putting up link to related GDO wiki for reference https://groups.drupal.org/node/164389 but it's out of date at this point.

This discussion for D8 should be done here in this new thread.

mgifford’s picture

Issue summary: View changes

spelling.

Pancho’s picture

My current research on WCAG and ATAG leads me to the following assessments:

  1. Currently it looks like D8 is on a very good track to AA-level WCAG-compliance. A number of hard cases have been solved with some more remaining, and a lot to be checked or double-checked. But this seems possible by release date.
  2. But even though there is some duplication between WCAG and ATAG, a number of specific requirements will make it hard, I'd say, quite impossible to comply with ATAG 2.0 at all.
    See for example #2036293: [meta] Comply with WCAG guideline 2.3: Seizures: The two WCAG requirements are probably already met, at least no larger problem.
    But ATAG doesn't only require our UI not to display any flashes. It requires us to take care content added by the author or any other author can be specifically paused or generically disabled, if it could potentially contain any flashes. Even more, some other ATAG guidelines require us to support authors in taking the right decisions while creating content.
    That opens up cans of worms which I don't imagine we can get closed until release.

So while we should aim for AA-level WCAG-conformance by the release date, AA-level ATAG-conformance would be worth aiming for by, say, Drupal 8 + 1 year, if all of the changes can be backported from the D9 branch.

And I think that's alright. It's not like WCAG wouldn't be worth it without ATAG:

  • When passing WCAG, we can at least state that Drupal 8 core out-of-the-box enables anyone to produce accessible, level-AA WCAG-compliant static websites. For most organizations, companies, governments allowing only for a limited set of user interaction, that's absolutely enough. Others additionally would have to make use of contrib modules and/or some custom code.
  • When passing ATAG, we could additionally state that Drupal 8 out-of-the-box itself is a WCAG- & ATAG-compliant CMS-framework that out-of-the-box enables anyone to implement an accessible, level-AA WCAG- & ATAG-compliant CMS application, community site, interactive site, whatever...

What do you think?

mgifford’s picture

I think we can start formally advocating for ATAG 2.0 AA in Core when the standard is approved:

"Currently, ATAG 2.0 is a mature draft and we expect that it will not change significantly. We recommend that you use the ATAG 2.0 draft in most cases, understanding that it might change."

The draft is pretty solid so I don't think much will change. I am also hopeful that Drupal 8 will be a good source of case studies for ATAG 2.0.

I do think that for ATAG compliance we need to start looking at adoption of http://quailjs.org/ in Core. It's great to see Testswarms of Core http://drupala11y.org and that is going to help a great deal to do the automated tests of new patches. This library can also be used against content in Drupal so that user generated content can be verified.

I'm wary about claiming WCAG 2.0 AA compliance. I'd really like to see a 3rd party audit done on Core before claiming that it will allow anyone to produce a WCAG 2.0 AA site. It's complicated and there's a real danger of oversimplifying it. I think it's totally safe to say that the Drupal community continues to lead the way in ensuring that it is as easy as possible to produce an site that is WCAG 2.0 AA compliant.

We can informally embrace ATAG 2.0 AA ideas in D8, but let's formalize that for D9.

mgifford’s picture

Pancho’s picture

I agree with everything you say in #3.
ATAG 2.0 is definitely out of reach for D8, no question about that. But if we want D9 to comply with it, we should keep working and implement as much as we can in D8, especially all low hanging fruit.
However, AA-level WCAG 2.0 compliance still seems to be doable, and it seems a good idea to concentrate on that. Certainly this would have to be tested and audited, before we can make any claim. And even if positive, the exact wording of the claim needs to be further discussed.

mgifford’s picture

Sounds great!

Hanno’s picture

I'm happy to see this issue here. FYI some time ago we started a quick scan for Drupal compliance on ATAG: https://groups.drupal.org/node/164389

ATAG seems still far away indeed, but let's try to use this as part of the architecture of D9 :)

jessebeach’s picture

Issue tags: +Spark

Putting this on our radar.

jessebeach’s picture

Issue summary: View changes

quail

Code X’s picture

Copy paste - email sent to WAI Interest Group members today.

"W3C WAI is pleased to announce the publication of Authoring Tool Accessibility Guidelines (ATAG) 2.0 as a W3C Candidate Recommendation. An updated Working Draft of the supporting Note Implementing ATAG 2.0 is also published.
ATAG 2.0: http://www.w3.org/TR/ATAG20/
Implementing ATAG 2.0: http://www.w3.org/TR/IMPLEMENTING-ATAG20/

ATAG defines how authoring tools should help developers produce accessible web content that conforms to Web Content Accessibility Guidelines (WCAG) 2.0. ATAG also defines how to make authoring tools accessible so that people with disabilities can use them. Authoring tools include content management systems (CMS), learning management systems (LMS), HTML editors, blogs, wikis, social media, and development environments.
ATAG Overview: http://www.w3.org/WAI/intro/atag
ATAG at a Glance: http://www.w3.org/WAI/intro/atag-glance

Candidate Recommendation (CR) is a major step in the W3C standards development process; it signals that there is broad consensus in the Working Group and among public reviewers on the technical content of ATAG 2.0. The W3C Process stages are described in: How WAI Develops Accessibility Guidelines through the W3C Process at . For more information about the CR status of ATAG 2.0, including the "exit criteria" for completing CR and the features at risk, see: "Status of this Document" section of ATAG 2.0 at http://www.w3.org/TR/2013/CR-ATAG20-20131107/#status

The purpose of the Candidate Recommendation stage is to ensure that ATAG 2.0 can be implemented in the real world and to document that different types of authoring tools meet ATAG success criteria. *WAI encourages a broad range of authoring tools to use ATAG 2.0 at this stage*, and share implementation experience. During this CR stage, we are developing an implementation report listing tools that meet each ATAG success criteria.

*Would you like your tool listed in the ATAG 2.0 CR implementation report*? If you might be interested in sharing how your tool implements ATAG, please let us know by *7 December 2013* via e-mail to public-atag2-comments@w3.org or Jeanne Spellman : jeanne@w3.org .

*A unique opportunity to get experience working with ATAG*: We are looking for accessibility specialists and specialists in specific authoring tools to help the ATAG Working Group with testing. If you might be interested in testing ATAG, please contact Jeanne Spellman : jeanne@w3.org .

While the focus of this CR stage is to collect implementations, comments are still welcome at: public-atag2-comments@w3.org "

kattekrab’s picture

To all of you who have been working on this... Thank you so much.

Tuesday next week is International Day of People with Disability (IDPwD)
http://www.idpwd.com.au/

It would be great if we could get our act together - and report back to WAI on where we're at with ATAG - even better if we could step up to be listed in the implementation report.

In Prague, Lisa Welchman called on us to engage in the broader governance issues in our field. I think this is one of those areas that really matters, and one that makes a difference to real people.

It also sets Drupal apart from the competition.

So again - I'm quite sincere - thank you for working on Drupal's ATAG conformance. I went to the OZeWAI conference yesterday and it was great to be able to proudly talk about Drupal in that context.

But I don't think it's enough to focus on WCAG - unless we're giving authors with a disability the right and freedom to create content too, we're only solving half the problem.

mgifford’s picture

Issue summary: View changes
mgifford’s picture

Issue summary: View changes

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

kattekrab’s picture

This issue hasn't seen an update in a while. It might be worth revisiting and seeing what progress has been made, and bumping this up to get more eyeballs and awareness again!

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.