For open source developer Mike Gifford, founder and president of OpenConcept Consulting Inc., any mention of Drupal accessibility after his name is redundant. He has spent the better part of 10 years improving and cementing accessibility in Drupal, enough to earn the role of official core accessibility maintainer for the project.

Accessibility awareness has grown considerably in the Drupal community, but the Internet changes rapidly and the software needs to keep up to remain relevant. Recent press on the trend of decoupling Drupal—including the milestone post by project founder Dries Buytaert himself—tends to skirt the issue that so-called headless configurations can blot out accessibility functions designed for the theme layer.

Gifford is aware of this and other roadblocks on the path to a native, front-to-back assistive solution. Ahead of his talk at DrupalCon New Orleans, he shared some of his thoughts on Drupal accessibility and more.

Give us an overview of your DrupalCon New Orleans talk How Drupal 8 makes your website more easily accessible. Why should someone attend? What are the major takeaways?

I can’t give you the takeaways! What’s the point of coming to the talk if I tell you the punchline here?

But seriously, I’ll be defining accessibility in the Drupal context, explaining the role of the community in keeping up with changes and best practices, highlighting some of the more exciting elements that we’ve brought into Drupal 8, and also talking about some of the contributed modules in Drupal 8 that can make your life easier.

How do semantics help assistive technology users (e.g., ARIA and HTML headings)?

Semantics are key for providing meaning and context to any blind user. Whether you are a Googlebot or someone using the open source NVDA screen reader, the site’s structure can be interpreted more deeply. ARIA (Accessible Rich Internet Applications Suite) has a lot of ways to build in semantics. The most obvious are landmark roles that play a complementary role to HTML headings. Elements like aria-label, aria-labelledby, and aria-describedby also help tie form elements together. These act as stepping stones for people with disabilities to navigate a site’s structure, much like what a table of contents does for a book.

Tell us how you rely on centralized tools in module development.

The easiest, of course, is the replacement for CSS display: none that we implemented in Drupal 7. We’ve since updated it in Drupal 8 to include hidden, visually-hidden, visually-hidden.focusable, and invisible. By leveraging these common classes, we are able to have a centralized place to manage how content is presented to screen reader and keyboard-only users.

Drupal.announce() is of course very useful when content changes on the screen based on user input. With sites becoming more dynamic, this is a huge deal. Likewise, the Drupal.TabbingManager is very useful in ensuring that keyboard-only users do not find themselves caught in a loop that doesn’t allow them to navigate the website properly.

What’s missing from Drupal 8? What are the next steps?

There is a lot missing. We keep fixing accessibility errors, but the accessibility tag on Drupal.org keeps growing as people use modules in new ways. Accessibility requires constant vigilance.

I think the top concern for me is fixing the remaining issues with new inline form errors so that it can move from an optional, experimental module to just the default response. Some work needs to go into CKEditor Tables so that figure/summary elements are defined properly in HTML5. We need better support still for Language of Parts. Complex views still don’t have a means of presenting images with contextual alt text.

We really need an automated way to check accessibility; it doesn’t matter if it is QuailJS, Tenon.io, or something else. It just needs to be easily integrated with open source development, particularly for modules.

I’d also really like to see more support for people who use tools like Dragon Naturally Speaking and Windows Speech Recognition. Users leveraging these tools make up a much larger share of the Internet than screen reader users, but generally there isn’t testing/support to make their UX better.

Can you explain ATAG and the authoring experience?

ATAG is the Authoring Tool Accessibility Guidelines from the W3C. It really comes in two parts for content authors:

1. Is the web editor itself accessible? Does it meet WCAG 2.0 AA?
2. What can be done to help the author create more accessible content?

Drupal has been building to WCAG 2.0 AA since Drupal 7, so we’re almost halfway there. We’ve known that people with disabilities shouldn’t have barriers to create the content. The new piece is what can we do to make it easier for content authors. We’ve done a few things in Core:

• Alt text is required by default within CKEditor and default image field types.
• Help text for modules describes what the accessibility features we’ve added are (CKEditor, Image, Views, Telephone).
• In 8.1 there is now a language of parts button to allow users to more easily define text in alternate languages and also enabled the browser’s native spell checker for CKEditor.
• Headers are now allowed by default in the Filtered HTML text format.

What about testing accessibility with users?

We haven’t done enough of this. We’ve had some people with disabilities evaluating pieces of Drupal 8, but there just haven’t been enough people involved. This is a really critical step of the process. Fortunately there are many ways to get involved and provide feedback to the Drupal community through the issue queue.

I do hope that more DrupalCamps take on the challenge of testing and evaluation with Drupal 8.1 moving ahead. The Web and how we use it is changing. We need to have opportunities regularly with people with different disabilities to engage in evaluating this technology and provide structured feedback on how to improve Drupal.