NOTE: D8 Core gates are now posted.
Background
Dries suggested in his keynote that accessibility, usability and performance would all the "gates" that new Drupal 8 core patches should pass before being accepted. In a later follow-up question, he said he is looking for input on what accessibility standards should guide these decisions.
This wiki page contains ideas about what the accessibility standards for Drupal 8 should be. Feel free to edit the wiki or post suggestions in the comments.
Accessibility Guidelines
Our goal is that new patches and features in Drupal 8 core will at least maintain the current level of accessibility or will improve Drupal's accessibility.
Patches should meet the following guidelines:
- Meet W3C WCAG 2.0 Level AA
- Meet W3C ATAG 2.0 Level AA
- All form fields must have a descriptive
<label>or #title (and using #title_display can control whether it is on-screen or off-screen) - Related fields must be grouped with a
<fieldset> - Every
<fieldset>must have a descriptive<legend> - WAI-ARIA markup must be included when Javascript/AJAX alters the page with new information
- Javascript, jQuery, and AJAX should be keyboard-accessible
If any patches do not meet these guidelines, the accessibility group is eager to make recommendations so that developers can meet these guidelines.
Process
New initiatives and patches going into Drupal 8 must meet the accessibility "gate" guidelines as well as the other gates.
The "Accessibility Gate Contact(s)" would be one or two people chosen to act as an owner and point of contact for the accessibility gate. The Accessibility Gate Contact(s) would facilitate the communication about whether a new patch meets the gate guidelines or how to best meet the guidelines. They would be a point of contact to leverage the skills and expertise of all the other members of the accessibility team. It is possible that the Accessibility Co-Maintainers, Everett Zufelt and Brandon Bowersox, may be willing to act as Accessibility Gate Contacts.
Any initiative owner or patch author can get in touch with the Accessibility Gate Contacts at any time in their development cycle to request an accessibility review or input - the earlier the better. It is also recommended that each initiative have a position responsible for internally reviewing patches before they are submitted to core's Accessibility Gate Contact(s).
The Accessibility Gate Contact(s) would be in contact with the initiative owners, the other gate contacts (such as the usability team), and working with the entire accessibility group. Members of the entire Drupal accessibility group will be needed to review patches, suggest best practices, and give advice to initiative owners and patch authors.
At the Accessibility BoF we started discussing explicit roles and structure for the accessibility team.
Exceptions
There may be cases where meeting a Level AA requirement may not make sense given the particular context and the trade-offs. Developers can get in touch with the Accessibility Gate Contact(s) to request an exception to the gate guidelines. The Accessibility Gate Contacts would be expected to evaluate the specific situation, pull in other experts from the accessibility group, and make a final recommendation about whether to approve the exception.
The exception would be documented in the issue queue with a clear explanation of the reason for the exception, any other alternatives considered, and the pros and cons. The Project Lead, Dries, would make the final decision based on this recommendation about whether to allow an exception by committing code that does not meet the gate guidelines.
Usability, Accessibility and Performance
Accessibility solutions should not significantly harm usability or performance. At that same time, usability and performance improvements should not significantly harm accessibility.
Our approach will be to make the primary user interface accessible. As a last resort if that is not possible, we will create a secondary "mode" or a secondary interface that is more accessible. Examples would include the "show weights" mode toggle for table drag in Drupal 7. Another example would be the disabling of the overlay in order to allow users to access the non-overlay administration screens. If we are unable to make the primary interface accessible, we will use consistent patterns to help users locate the help text or the toggle or navigation to get to the secondary interface.
Drupal 8 must be at least as good as Drupal 7 for performance, usability, and accessibility. We want Drupal 8 to be significantly better in all of these areas.
orked out, it has some potential for summer of code work.[#1071830]
Next Steps
This wiki is a working suggestion for Accessibility Gate Guidelines and process, subject to change. Once the guidelines are more final, we need to post official documentation of the guidelines. In addition, we need to provide documentation of the "why" and the "how" aspects, as discussed at the Accessibility BoF. That would include sample code, explanation of techniques, and testing instructions. That will give Drupal 8 developers a clear framework for knowing what to do and how to do it.
Related Code and Modules
I believe we can get the d7 version of accessible helper module; accessible content module; and automated testing setup to support accessibility guidelines for drupal 8. The work would largely be:
- Restructure accessible and accessible_content to have a base api.
- Bring some of that into core for automated bot testing for drupal 8
- Include a preferences configuration page in the api with a "drupal 8 accessibility guidelines" option
The current maintainers of these modules are hit or miss on development time, so after a structure was w