Accessibility Always a Focus in Drupal!

As the release of Drupal CMS version 1 approaches on January 15, 2025, The DropTimes sub-editor Alka Elizabeth sat down for a virtual conversation with Gareth Alexander, Senior Drupal Developer at Zoocha and the Accessibility Tools Track Lead for Drupal Starshot. With over 16 years of experience in the Drupal ecosystem and a background in inclusive web development, Gareth brings unparalleled expertise to the forefront of accessibility in Drupal. The conversation reminds us that Accessibility is much beyond ticking boxes, it's a need for all.

In his role as Track Lead, Gareth has been instrumental in shaping the Accessibility Tools Track for DrupalCMS, ensuring that the platform continues to champion inclusion and accessibility. During the interview, Gareth shares insights into the development process behind key accessibility features, such as the EditoriA11y module, and discusses how the tools empower content creators to build accessible websites effortlessly. He reflects on the challenges of balancing technical innovation with user-friendly design and highlights the community’s role in advancing accessibility.

The conversation also explores the potential of DrupalCMS to broaden its appeal to a wider audience, offering intuitive features that address the needs of both developers and content creators. Gareth also shares his thoughts on the European Accessibility Act, the evolution of Drupal’s commitment to inclusion, and the collaborative efforts that make accessibility a core priority in the Drupal community. This insightful exchange is a must-read for anyone passionate about creating a more accessible digital world.

Gareth also extends his heartfelt gratitude for all the cooperation,

" Just a huge thank-you to everyone involved so far. The Drupal Core Accessibility team has been amazing and incredibly supportive. If anyone wants to join, we’re always open to new contributors, and we’ll help you find the best way to get involved. "

This insightful exchange is a must-read for anyone passionate about creating a more accessible digital world. And if you prefer watching the video recording of the conversation over it's text version, scroll down the page. We have embedded the video from YouTube. 

TDT [1]: Let’s start at the very beginning. Can you share how you first discovered Drupal and what your initial experience with the platform was like?

Gareth Alexander: I was working as an IT manager for a deaf-blind charity, and part of my role was managing their website. As the internet started gaining traction, more people began asking me to add more information and make updates to the website. I found it increasingly time-consuming to handle all the edits they wanted.  

To address this, I initially built a CMS for them, trying to keep it updated, secure, and functional. However, I quickly realized that maintaining it was a significant task on its own, and I was likely reinventing the wheel. So, I explored several CMS options at the time and rebuilt their website using four different platforms to evaluate what worked best for me and what the end users found comfortable.  

You May Like

Blog

Celebrating a Year of Growth and Community: The DropTimes 2023 in Review

Blog

Celebrating a Year of Growth and Community: The DropTimes 2023 in Review

In the end, Drupal stood out, and I instantly took a liking to it. Eventually, I left the organization to focus solely on becoming a Drupal developer, which turned out to be a great decision.

TDT [2]: And here we are. So, you've been active in the Drupal ecosystem for quite a long time now. How many years has it been?  

Gareth Alexander: Since then, it’s probably been about 16 or 17 years.

TDT [3]: That's a long time—16 or 17 years! And you've seen the platform evolve over all these years. Can you give a brief overview of how Drupal has evolved during this time?  

Gareth Alexander: The first site I built was impressive back then. The user interface was always very user-friendly, and it’s always been developer-friendly as well. However, that site was built using Drupal 5. At the time, Drupal 6 was available, but I felt it didn’t offer much more, and I was at an in-between stage, unsure whether to use Drupal 5 or 6.  

One constant throughout the years has been the question: should I move the site to the next version? For instance, I had sites on Drupal 6 and wondered if I should move them to 7. Later, there was an even bigger jump when many sites were on 7, and the question arose about upgrading to 8.  

Moving to Drupal 8 required a lot of retraining. It was a significant step up, requiring developers to move beyond the basics they might have learned on their own, such as coding in their bedrooms, and adopt a more structured, professional approach. That was the biggest change I witnessed and experienced personally.  

I saw some developers I knew decide that moving to Drupal 8 was a step too far, while others embraced it, finding it fantastic because it required them to learn proper programming.  

Now, Drupal feels like one of the big players. It’s very well built, and I think this evolution has transitioned Drupal from a tool for hobbyists to a serious contender in the industry.  

TDT [4]: Everyone is talking about Drupal Starshot. Drupal CMS is coming out in less than a month. What do you say about that? How do you feel about this transition?  

Gareth Alexander: I’m really excited. As I’ve mentioned, the transition from version to version has brought a lot of changes. Features were a significant addition, and config management has been another major development.  

Recipes are particularly exciting. They offer a middle ground between distribution, installation profiles, and config management or feature management. It’s a blending of several exciting elements, and it feels like we are finally going to properly address that area now.  

I’m also excited about the potential for Drupal to compete more directly with WordPress. WordPress powers a large portion of the web, and I think Starshot, or DrupalCMS, will push us further into that space. It will make Drupal more attractive—not just for hardcore developers but also for designers who often choose WordPress because it’s easy to install and quickly get a site up and running.  

I’m hopeful that DrupalCMS will achieve the same ease of use—the idea that you can install it and have something functional and well-designed straight out of the box.

TDT [5]: The Drupal.org homepage was recently updated after a long time. What are your thoughts on the new design?  

Gareth Alexander: It had been the same for a long time, so any change can feel a bit surprising at first. I was looking at it about five minutes ago, and I think it’s good—I like it. Everything feels bold and impactful, and it really grabs attention.  

TDT [6]: Accessibility is a very important topic in the web today, and everyone is talking about it. Drupal has always championed inclusion and maintained a strong focus on accessibility. With the Accessibility Tools Track in Starshot, what do you envision for the track?  

Gareth Alexander: As you mentioned, Drupal has always prioritized accessibility. As developers, we aim to build highly accessible websites, but when handing them over to others, challenges can arise. I remember my first web development job, where I was asked to add a WYSIWYG editor to a text field. I gave the users full control, and when I revisited the site a week later, they had changed some text to bright pink and made another section flash at the bottom of the page. I realized then that with great power comes great responsibility. 

Drupal offers so much flexibility that it’s easy to lose sight of the core goals and focus on making things flashy. The accessibility tools we’re providing aim to remind users of the broader considerations. For example, rather than adding flashy elements, they need to ensure that their design works for everyone.  

The EditoriA11y module we’ve implemented addresses these needs. For instance, if someone selects a font color with poor contrast values, it will notify them to reconsider their choice. Similarly, if headings are not structured correctly—for example, jumping from an H4 to an H6—it will alert the user to correct the hierarchy. These tools are designed to nudge people in the right direction and help them make accessibility-conscious decisions.

TDT [7]: When Dries announced Drupal Starshot at DrupalCon Portland, there was a very short window for DrupalCMS version 1 to be released. As the Track Lead for Accessibility Tools, what were some of the strategic goals you set to create a roadmap for the track's development?  

Gareth Alexander: I primarily focused on the WebAIM 1 Million Project, which highlights the most common accessibility errors found on the top websites. This project examines the homepages of one million websites, and consistently, issues like missing alt text and poor color contrast appear as top problems.  

There are also some site-level issues, such as not having the correct language set, but those can often be addressed during the initial setup and then left as is. Drupal already handles many of these site-level issues well, which alleviates some of the burden.  

However, the three main problems are content-related. Using the WebAIM data, I aimed to address the most frequent issues with the idea that solving even the top six problems would lead to significant improvements. While Drupal only represents a portion of those one million websites, tackling the areas we can control will still make a big impact.  

I prioritized ensuring that content editors have tools to help them address these critical issues. While I also wanted to include additional tools like automated scanning, my primary focus was on creating solutions that directly assist editors in fixing high-priority accessibility problems.

TDT [8]: A few months ago, I came across a survey about the Drupal Starshot Accessibility Track where you were seeking feedback from the community. How did it go? Did you receive any surprising responses or ideas?  

Gareth Alexander: I've been involved in accessibility for longer than I’ve been working with Drupal, so there weren’t any major surprises. However, I did learn about a few tools that others were using, which I wasn’t previously aware of. The idea of integrating or offering a way to incorporate those tools into Drupal was certainly a positive takeaway.  

Overall, the feedback was very supportive of the vision I had. Accessibility is something that needs to be considered during the process—whether you’re writing content or building a website—rather than addressing it after the fact. Doing it upfront makes the experience far easier and more effective.

TDT [9]: We are now approaching the release of the first version. How would you describe the current progress? Has it aligned with the roadmap you initially set?

Gareth Alexander: Absolutely. The EditoriA11y (Drupal Module) module has been fantastic—it has actually exceeded my expectations. It provides a site report feature, which I didn’t know it could do when I started. I was aware it could help while fixing content, but I didn’t realize it would also track errors across other pages and present a comprehensive view.

This was something I had wanted to include, and I initially thought it would require a separate tool. Part of the earlier survey was to explore what that tool might be. Although I wasn’t able to find an additional tool for this purpose, discovering that Editorially already offers this functionality has been a pleasant surprise. It fulfills a key feature I hoped for, so I’m not disappointed that we didn’t need to add something extra.

TDT [10]: Integrating tools like EditoriA11y into DrupalCMS is obviously a technically complex process, and there’s also the challenge of maintaining a high-quality user experience. Have you faced any specific obstacles or challenges in balancing these aspects within the track?

Gareth Alexander: My involvement in this track coincided with those very challenges. Recipes, for instance, is a brand-new feature that has been on the roadmap for some time, but it hadn’t been fully ready until now. As DrupalCMS was being developed, I realized it was the right time to get involved. It’s always better to align with the development process early rather than waiting until much later and trying to figure out how everything works and fits together.

I started learning about Recipes early on and explored what I could create using it. That’s when I decided to focus on adding accessibility tools, as it was an area that wasn’t yet addressed. Coincidentally, as I was learning how to use Recipes, the new installer, and the Project Browser, the call for Track Leads was announced. I realized I was already working on something relevant, so it felt like the perfect opportunity.

It has been an exciting and rewarding process to learn these new features and contribute to their development.

TDT [11]: You mentioned being involved with accessibility long before working with Drupal. Accessibility has only recently become a major focus, gaining significant traction in the web world. So why accessibility? What drew you to the concept of inclusion and accessibility on the web?  

Gareth Alexander: I think it started with a job I had 20 years ago, working as an IT manager for a deafblind charity. My role involved supporting users by ensuring their computers were functioning properly, but I also helped their clients. Many of them would come to me and say, “I have a computer, but it doesn’t meet my needs.” For example, someone might say, “I’m blind—can I have a Braille display?” or “Is there a way I can access a keyboard that works for me?”

This introduced me to assistive technology before I even fully understood the concept of accessibility. Part of my role involved visiting the University of Edinburgh, which had a large library of assistive technology. There, I could borrow tools like switches, Braille displays, and other devices to help individuals who were partially sighted or had other challenges in accessing technology.

I learned how to use these tools myself, which naturally led me to think about their needs when building websites. I wanted to ensure the content on the sites I developed could be accessed by these tools. In fact, I was creating accessible websites even before I started using Drupal.

When I eventually decided to work exclusively with Drupal, accessibility was a significant factor in my decision. Drupal made it easier to build and maintain accessible websites, so I decided to focus entirely on it and make accessibility a core part of my approach.

TDT [12]: While going through your profile, I noticed you’ve spoken at events like DrupalCon Barcelona and participated in sessions such as the one with Paul Sebborn, which revolved around accessibility. How do you think events like DrupalCons or the Drupal community coming together impact your projects or contribute to your personal and professional growth?

Gareth Alexander: I’ve never really thought about it before, but I suppose it’s nice to take a step back and reflect on what you’ve achieved. These events give you the opportunity to do that retrospective: What have we accomplished? What have we done?

Sitting down to analyze your work and approach often provides insights you might not get otherwise. When preparing for a talk or a presentation, you look at your work with a critical eye. Instead of simply repeating what you’ve done in the past, you start to assess: What did we do well? What could we improve?

This process helps refine and hone your methods, making these events not only an opportunity to share knowledge but also a chance to grow and improve.

TDT [13]: I did the coverage on your particular talk in DrupalCon Barcelona. We published an article about that session, and there was a quote from Paul Sebborn which said, “Accessibility compliance is not merely a box-ticking process.” When it comes to DrupalCMS and the Accessibility Tools Track, how does it encourage a deeper understanding of what accessibility stands for?

Gareth Alexander: It’s challenging because many steps taken to improve accessibility for one group of people may not necessarily help another. For example, some believe decorative images shouldn’t have alt text, which can help visually sighted users quickly ignore those images. However, for someone solely using a screen reader, omitting alt text as recommended means the image won’t be read at all. At the same time, partially sighted users who notice the presence of an image might get frustrated if it doesn’t provide any descriptive information.

There’s a guiding principle: design for tools, not for users. Focus on ensuring compatibility with visual browsers, screen readers, keyboard navigation, and switch devices. Instead of trying to cater to every possible user experience, aim to create a platform that supports the tools people use, as that provides broader accessibility.

TDT [14]: Speaking of accessibility, I’ve noticed accessibility overlay tools on websites. There’s a lot of debate about their effectiveness. Some argue they help, while others say they create more issues. What’s your stance on this?  

Gareth Alexander: I firmly believe that if you build an accessible website, you don’t need an overlay. These overlays often make changes to the DOM or the structure of your website that their developers believe are improvements. However, if someone is already using a screen reader, they don’t need another layer that might conflict with it. That’s where problems can arise.

In practice, these overlays rarely improve accessibility for the people who genuinely need it. They might help pass automated checks, but if you test the website with real users relying on assistive technology, those tools often fail to provide meaningful improvements. Overlays tend to be a box-ticking exercise rather than a genuine solution.

TDT [14]: The success of open-source communities like Drupal heavily relies on contributions and support from the community. How can Drupalers support the Accessibility Tools Track? Are you looking for feedback, participation, or contributions?

Gareth Alexander: There are several ways the community can get involved. For instance, there’s an office hours meetup where Drupal Core Accessibility volunteers discuss ongoing work. Anyone interested is welcome to join.

We also hold a weekly Starshot Accessibility Tools Track stand-up to discuss issues, and everyone is welcome to participate. On Slack, there’s an Accessibility channel with information, and there are pages on Drupal.org that provide further details.

Right now, we’re auditing all the modules included in Starshot to identify any accessibility issues or areas for improvement. Drupal Core has an accessibility gate that ensures any new commits either improve or maintain existing accessibility standards. We’re working to extend this to include the extra modules in DrupalCMS as well.

If you’re interested, you can check the issue queues for DrupalCMS under the tag "A11Y" (short for accessibility). There are tagged issues specific to DrupalCMS, and we’d love for people to help identify and fix them. There’s also room for new tools—if anyone has ideas or wants to contribute modules, we’re open to including them in the track.

TDT [15]: There’s a European Accessibility Act coming into force in 2025. How does the Accessibility Tools Track prepare DrupalCMS to meet these legal requirements, and what does it mean for the future of Drupal users?

Gareth Alexander: Drupal already follows best practices for creating accessible websites and ensuring the platform itself is accessible. The Accessibility Tools Track is designed to help content editors learn about accessibility. The tools we’ve included not only flag issues but also explain why they matter and provide guidance on how to fix them.

By using these tools, users become more aware of accessibility considerations and how to address them effectively. I’m hopeful this will lead to increased awareness and better practices across the board.

TDT [16]: With DrupalCMS version 1 almost here, what are the standout features in the Accessibility Tools Track that Drupalers should watch for?

Gareth Alexander: While there’s nothing groundbreaking, the Accessibility Tools Track is a well-designed and intuitive tool. I would recommend it to anyone writing content for the web. It pairs nicely with modules like SEO Yoast, which provides tips for improving SEO. Similarly, this tool gives tips and guidance for improving accessibility.

I’ve been speaking with the maintainer, and there are many exciting improvements planned. These will be automatically included as they become available, so it’s something to look forward to.

TDT [17]: Beyond compliance and DrupalCMS version 1, how do you foresee accessibility evolving within DrupalCMS?

Gareth Alexander: I don’t think accessibility will ever be a problem that’s completely solved. It’s something we’ll always need to consider. The Accessibility Tools Track is meant to serve as a constant reminder to think about accessibility—just like we consider SEO or writing engaging content. Accessibility should be one of the thought processes that content editors go through every time they create something.

TDT [18]: Finally, considering your long involvement with Drupal, what is one of your proudest contributions to the community?

Gareth Alexander: I’m particularly proud of mentoring others throughout my career. Helping teach people how to use Drupal and grow their skills has been incredibly rewarding. I was involved in Drupal Scotland, where we ran training programs for new developers, and I’m proud to have played a part in that. Growing the community and giving back has always been important to me.

TDT [19]: That’s wonderful. Is Zoocha planning to host a DrupalCMS launch party?

Gareth Alexander: I’m not sure if Zoocha itself will host a launch party, but I know they’ll likely be involved in the London CMS launch party. Personally, I’m working on organizing an Edinburgh-based launch party. Since Zoocha has many remote workers, I think there will be involvement at local levels wherever our team members are based.