Drupal has made great advances in accessibility over several major releases, and nowadays ranks as a leading implementation of web accessibility standards. This session will encourage contributors to look ahead at future challenges and opportunities for accessibility during the faster 8.x (and 9.x) release cycle. In particular, it aims to discuss the impact of the new strategic initiatives proposed in the keynote at DrupalCon New Orleans earlier this year.
What has been happening in Drupal accesibility since the 8.0.0 release?
Regressions caught, bugs fixed.
Features backported to Drupal 7.
Important problems which are still outstanding.
New features, such as bringing the CKEditor accessibility checker component into core.
Future work
Automated accessibility testing using headless browser drivers. Can we confirm the expected behavior of keyboard controls, and check dynamic ARIA properties in the DOM?
Supporting more interaction modes, such as Windows' high-contrast mode, and speech-driven control.
Review our use of WAI-ARIA properties. Does it match recommended practices? Have we used too much?
The challenges of finding new contributors; encouraging familiarity with screen readers and other interaction modes for quicker patch reviews.
End-user testing for accessibility - are we building the right features?
Impact of the New Strategic Initiatives for Drupal Core
Several stratgic initiatives are still at early stages of concept and planning, but we can already prepare for the accessibility challenges and opportunites they wil bring.
More application-like interfaces are shown in the vision mockups for the blocks and layout, media, and data-modeling initiatives. Various UI interactions are presented without full-page refreshes: sliding panels, autofocus, live result filters, drag-and-drop, wizard-like progress steps, pop-up success messages, live previews, and role impersonation. The accessiblity of these must be addressed, and suitable ARIA patterns already exist for many of them.
The theme component library initiative will involve much refactoring of how Drupal produces output. Preventingn accessibility regressions is a key concern, but there is also an exciting opportunity to build more accessible components in line with ARIA authoring patterns.
API-first and Cross-channel initiatives: Drupal's APIs, SDK, and other output formats should provide all the information needed for use with platform-native accessibility APIs, such as text alternatives, accessible roles, labels, and descriptions.
Getting of the Island, and Proudly-Found-Elsewhere
During the time it took to release Drupal 8.0.0, the whole topic of web accessibility moved on. There are lots of ways that our community could learn from, and contribute to, other accessibility projects.
New developer tools and testing frameworks are available.
Browsers and screen readers support for web standards (HTML5, ARIA) improved.
More accessibile design patterns and components have emerged. The Drupal community already working with the CKEditor developers on accessibility issues.
The Wordpress accessibility project is catching up with us :-) Seriously though, they are dealing with many similar accessibility issues as we are.
Drupal was one of the key implementations being tracked during the W3C standardization process for ATAG 2.0 (authoring tools accessibility guidelines). Drupal could continue to play a role in shaping accessibility practices and standards, such as ARIA 1.1 and ARIA authoring practices.
Experience Level
The session is aimed at an intermediate level:
As a core conversation, it assumes broad knowledge of Drupal's features, especially the admin/editor interface.
Not intended to be code-heavy, but some short code snippets may be used for illustration
Does not assume specialist knowledge of accessibility issues.