Future directions for Drupal Accessibility in D8 and D9

andrewmacpherson's picture

A few weeks ago Mike Gifford reached out to me to ask if I would consider joining the team of accessibility maintainers for Drupal core... and after giving it some thought I said YES! I'm really stoked about being asked - I've been bouncing around my home a LOT since Mike asked me. There currently an open issue to update MAINTAINERS.txt.

Until now, I've mostly been active in the issue queues on D.O, and not so much here in the accessibility group, so I thought I'd write a little here about our future challenges and opportunities with accessibility, as I see them.

We've reached the point where accessibility is treated as a first-class concern for the project (i.e. we don't have to spend much time justifying it) and D8 provides a great basis for building accessible web sites. Our greatest challenges now are to keep innovating; to continue grow awareness and skills among contributors; and to find new contributors.

Short term goals (great for the 8.y.z releases):

  • Stabilize Inline Form Errors module. If this module doesn't reach a stable state, it's at risk of being removed from core.
  • Make use of the new Javascript testing feature!
    • The Mink driver lets us emulate keyboard and mouse actions distinctly, so it would be great to write tests which will guard against keyboard accessibility regressions when Javascript is refactored (we've had a few since the late D8 betas...). A cool bonus outcome of this would be that test writers learn about expected (conventional) keyboard behaviours.
    • We have various aria-* stuff which changes dynamically (e.g. our details/summary implementation, or the use of Drupal.announce() with the module filter). A headless JS test browser isn't the same as manual screen reader testing, but I think we can at least test for these things in the DOM.
  • Support MS Windows high-contrast mode. This could be achievable though small incremental tweaks (mainly CSS), to provide stronger equivalent affordances to the usual design. Even better, I think we can do this without (fingers crossed) changing the design of the Bartik and Seven themes. So far much of our effort has addressed screen reader users, and sighted keyboard-only users; supporting Windows' high-contrast mode lets us provide another assistive tech experience, which would be awesome.
  • Make more use of reliable ARIA patterns.
    • Vertical tabs could use the ARIA tabs properties. The vertical tabs implementation hasn't changed much since it was a proof-of-concept contrib module for D6, and ARIA support has advanced a lot since then :-) One interesting question here is that the ARIA Authoring Practices describe how the arrow keys behave for horizontal tabs. Should we swap the behaviour of left/right and up/down keys for a vertical tab panel?
    • The dropbutton pattern, which is scattered throughout the D8 admin UI, could describe it's current state using aria-expanded.

Longer term goals, with reference to the new initiatives that Dries introduced at DC New Orleans last week:

  • Various features mock-ups were presented as part of the Author Experience initiatives. For example the outside-in block placement UX showed a slide-in block palette, various pop-up messages, and a drag-and-drop method to put the block in the desired space. The data modelling and media management demos showed similar behaviours. These are areas where the accessible experience would need to be described and implemented. We already have Drupal.announce() and Drupal.tabbingManager - perhaps it might be time to include a drag-and-drop manager in core... does such a thing even exist yet?
  • The theme compenent library initiative is also one to watch, though I'm not worried about it much - we already have good semantic markup, and great front-end contributors. Hopefully this is something we just have to review, though it's not yet clear how many components might have dynamic behaviours.
  • The idea of adopting a front-end framework to a facilitate decoupled front-end, and a more application-like admin experience, is getting strong consideration. This wasn't named as one of the initiatives at DC New Orleans, but certainly affects accessibility. This might turn out the be a large challenge, as lots of current templates and behaviours would likely be re-written, and reviewed for accessibility.
  • Grow the number of contributors (developers, patch testers) who are confident at manual testing for accessibility, so patches can be reviewed quicker. One way to do this would be to provide training at sprints, camps, and conferences; help people take their first steps with a screen reader, for example.

I'll flesh out some of these in the D.O issue queues soon enough, and I'll try to start posting here in this group more frequently. Meanwhile, ask me anything :-)


Congrats, Andrew, core

RadinaMatic's picture

Congrats, Andrew, core maintainer team is lucky to have you! :)

Terrific Vision

mgifford's picture

Hey Andrew, so happy you're interested.

This is a terrific vision of where to go next. It's also really good to check out what the WordPress folks are doing. I love this approach to testing for Dragon NaturallySpeaking. They have in the last year really scaled up their efforts for accessibility (which is terrific). We can do more together!

Having better automated testing tools would also be good. I'd love to see QuailJS or Tenon.io integrated so that we could get nightly snapshots of the number of accessibility errors that automated tests find in 8.1, 8.2, etc.. This isn't a small undertaking, but hope we can build the infrastructure to do it.

I'd like to see a our ARIA usage reviewed as well. I think we may have added too much in Drupal 8.0. We want to strike the right balance, which we will be able to do when we have more screen reader users involved in giving us feedback.

Finally we need more folks involved and enthusiastic about the work we can to together. Accessibility is a massive problem. My belief is that it is only something we'll be able to effectively address if we collaborate. Fortunately, open-source communities are good at this.