Drupal core gates

Core changes must pass through a series of "gates" to ensure their quality is up to standards. Gates are essentially "checklists" that can be used to evaluate a patch's readiness, by both developers and patch reviewers/core committers.

The purpose of gates is two-fold:

• Focus on only the most important items in each category (try to limit to 5 or fewer), so that the process is neither too complex nor too overwhelming for developers to follow.
• Do not create additional burden on the respective individual teams. Rather, have well-documented resources so that developers have what they need to write gate-satisfying code, and reviewers can easily check for gate satisfaction.

The following gates (identified during Dries Buytaert's keynote during DrupalCon Chicago) will be used for assessing Drupal core patch readiness.

Looks scary, right? Please note the "When is this needed?" column. Not all patches need to pass all of these gates, but they are all documented here in one place so there are no surprises.

Contents

• Documentation
• Performance
• Accessibility
• Usability
• Testing

Documentation

Performance

Discussion: Defining the Drupal 8 performance gate

Accessibility

Discussion: Defining the Drupal 8 accessibility gate

Usability

Testing

Discussion: http://groups.drupal.org/node/158774

Frontend

These are still being discussed: https://www.drupal.org/project/drupal/issues/3002762

Appendix: Additional information linked from above tables

Minimum requirements for in-code documentation

When a patch changes code behavior, all code that is added or updated must have:

1. Documentation blocks for all files, interfaces, classes, methods, class members, functions, hooks, and constants, which must contain:
   • A one-line summary (80 characters or fewer).
   • Typed @param, @return, @var, and @throws (with descriptions on param/return) where required by the API documentation standards.
   • Longer explanations for anything complicated.
2. Inline comments to explain the code flow.

The documentation must be clear and complete. Typos, verb tenses, formatting, and the like may be cleaned up in follow-up issues for large patches where it would hold up progress, at the committer's discretion.

More about Drupal core conformance and UI patterns

The accessibility goal for Drupal core is WCAG 2.0 and ATAG 2.0 Level AA. We want to reduce barriers to ensure that sites are Perceivable, Operable and Understandable, and Robust (POUR), and provide for the use of a variety of assistive technologies. It is important to think about accessibility when developing new user interfaces and to become familiar with successful and conforming implementations.

UI Patterns. Following existing user interface patterns already used in Drupal core will reduce the opportunity for accessibility or usability problems. New user interface patterns will likely require review by the accessibility and usability teams.

Problem Patterns. There are known patterns in core that are highly likely to cause accessibility problems, for example modal dialogs or interactive jQuery calls. If your patch includes one of these known patterns please check with accessibility team by tagging the issue with "needs accessibility review".

Testing is very important when introducing or redeveloping a UI pattern. If you are still unsure after running through the basic testing procedures, please check with accessibility team by tagging the issue with "needs accessibility review". The earlier a new or changed pattern is checked for accessibility the easier it can be corrected.

More about Automated Checking

Automated checkers do not guarantee accessibility and do not check all WCAG 2.0 criteria. Some criteria require human review and problems may be raised in the issue queue.

The WAVE Toolbar is a recommended checker. Other popular checkers include: the WAVE web app, FAE and its Firefox add-on.

Running the automated check before and after applying a proposed patch is important. Some parts of Drupal core cause errors or warnings in WAVE and other tools. New patches should not introduce additional errors.

More about Contrast

See http://drupal.org/node/464500 for background information and other color contrast tools.

More about #title and #title_display

In the Drupal Form API, the new #title_display property allows you to choose the proper location for a form label to be displayed. It prints the label in the chosen location or makes it invisible off-screen while still preserving its accessibility.

See the Form API documentation for #title_display.

It is not accessible to remove the label by emptying the #title property: unset($element['#title']) ... or by using CSS display: none. Both of those techniques were used in Drupal 6 and earlier when there was no built-in support for locating form labels off-screen or as tool-tips.

More about JavaScript Accessibility

Keyboard accessibility is a major concern when creating Javascript-based widgets, UI interactions, and AJAX functionality. "Keyboard only" is when you only use the keyboard to interact with the user interface. Many disabled users cannot use a mouse or other pointing device. Try using each feature of a new interface without using a mouse or trackpad. Problems with keyboard only operations will quickly identify areas to focus on.

Another kind of JavaScript accessibility problem is the visibility of content that is dynamically loaded or updated by AJAX calls. Using existing UI patterns is encouraged to avoid accessibility problems. New user interfaces of this type will likely require design and collaboration with the accessibility and usability teams. Contributors are encouraged to seek design assistance as early in the design cycle as possible by tagging any issue with "needs accessibility review".

Drupal core includes numerous examples of UI patterns that have been made accessible with JavaScript and/or ARIA markup. These include: drag-n-drop tables, vertical tabs, the password strength checker, and auto-complete fields.