I Made Accessibility Fixes—and Never Looked Back: Kat Shaw

The internet is for everyone.

That’s the promise. Or at least, it’s supposed to be. But in practice, that promise frays quickly, especially when you look at how many people are still locked out of basic digital experiences.

Accessibility isn’t some niche concern or feel-good feature. It’s the difference between inclusion and exclusion, participation and silence. And yet, most of us rarely think about what it actually takes to build a site that works for everyone, not just the majority.

This is where things get real. Accessibility lives in the details—in the overlooked corners of interface design, in unlabeled buttons, in broken keyboard flows, in alt text that either says too much or nothing at all. It asks sharp questions: Can a screen reader user get through checkout? Can someone without a mouse navigate the nav bar without getting stuck? These aren’t edge cases. They’re real users. Real stakes.

But here’s what I’ve always wondered: how do platforms like Drupal—huge, open-source, sprawling—actually manage accessibility? With so many hands in the code, who makes sure accessibility doesn’t slip through the cracks? What happens when an issue is spotted? Who fixes it, and how? What does it really look like to audit and remediate a Drupal site? And with community efforts like A11yTalks energising the space, how does that momentum turn into measurable progress? What are the persistent pain points, the ones still hanging around despite all the good intentions?

To get real answers, I turned to someone who’s been deep in this work: Kat Shaw, whose name continues to resonate in the Drupal and broader digital accessibility communities. With her team at Lullabot, Kat has been quietly—yet decisively—reshaping how we think about accessibility in the open-source space.

Let’s get into that conversation—and see how digital accessibility, in the hands of the right people, becomes a living standard, not a footnote.

TDT[1]: You’ve been in web development since 1999 and started working with Drupal in 2012. What drew you to Drupal specifically, and what has kept you engaged with it over the years?

Kat Shaw: At the time, I worked for Douglas County, Kansas, as their Webmaster. I was a one-stop shop who handled everything for their sites. Does anyone have the job title of “Webmaster” anymore? But I digress.

At the time, my employer was Douglas County, Kansas. They worked exclusively with Microsoft. With that, I developed in .NET, and was working to create a custom .NET-based CMS. I belonged to a user group in Kansas City called Kansas City Metro Area Web Professionals (KCMagWeb). Several members were huge advocates of Drupal. (Unfortunately, the user’s group has since disbanded.)

You May Like

Interview

Building Community-Driven Drupal Solutions: JD Leonard on Member Platform and Open Source

Interview

Building Community-Driven Drupal Solutions: JD Leonard on Member Platform and Open Source

During one meeting, I mentioned some of the struggles I was having with this custom setup. Several members, who were Drupal advocates, mentioned that I should switch to Drupal.

One of those members is a longtime friend and colleague, Eric J. Gruber. He worked for the City of Lawrence, Kansas at the time, and offered to demo the admin side of Drupal. Once I saw that, I was very impressed, and immediately started my initial work with Drupal.

There were two things that have solidified my use and advocacy of Drupal all these years. First is the Drupal community. There’s nothing like it. I’d never worked in open-source, but once I did, I became a huge advocate for it. The Drupal community has a certain kind of magic that other communities don’t have. The second is how Drupal has put accessibility first, starting with Drupal 8. Other CMS’s don’t properly handle accessibility, or at all, and this is a huge differentiator for me.

TDT[2]: Before your focus on accessibility, you earned recognition with the Digital Government Achievement Award. Could you share more about those government-focused projects and what you learned from that experience that still influences your work today?

Kat Shaw: When working at Douglas County, Kansas, I was a one-woman web team. I developed custom sites and applications in ASP and .NET at the time. Two applications received awards from the Centre for Digital Government.

The first award in 2005 was for our “Property Search” application. They awarded us the 2005 Digital Government Achievement Award in the Government-to-Citizen County category. With this application, online users could search for properties located in Douglas County. Information included property details, assessed and appraised values, and tax details. This application was by far the most popular application in the entire county.

The second award in 2009 was for our “Voter Registration Search” application. They awarded us the 2009 Honourable Mention for the Digital Government Achievement Award in the Government-to-Citizen County category. With this application, online users could view their voter registration details. Details included their personal information, representatives, districts, and voting sites. I also incorporated a sample ballot into this application.

Before leaving Douglas County in 2015, I moved these applications to Drupal. They remained highly successful with our users.

In addition, while at Lullabot, I was a member of the teams for two projects that won the 2024 Government Experience Award for “Overall State Government Experience." The Commonwealth of Massachusetts won 1^st place, and the State of Iowa won 2^nd place, respectively. I worked on the MyMassGov project for Massachusetts and the DX platform for Iowa. Thankfully, both projects put accessibility first from the start.

TDT [3]: How did your transition from developing government apps to specialising in digital accessibility begin? Was there a specific moment or project that sparked this shift?

Kat Shaw: I’d been making accessibility improvements to our sites for years without knowing it. I did this by making our content readable, structured, consistent, and reusable. My “aha” moment came during another KCMagWeb meeting in March of 2012. A wonderful man named Dan worked for the CIO’s office of the GSA’s Section 508 and Accessibility. He presented on accessibility from the point of view of a blind user.

TDT[4]: As a CPACC-certified professional, what do you see as the most misunderstood or overlooked aspect of digital accessibility in today’s development workflows?

Kat Shaw: A common refrain I hear is, "If that issue is not in the WCAG or Section 508 conformance standards, we don't need to fix it". The conformance standards don't define every accessibility and usability issue. Instead, they work on defining common barriers to people with disabilities. It's our job to create sites and apps that allow all users to access and use our content in an effective way.

Common examples I've experienced include:

• Flashing and blinking content
• Small or unreadable font styles
• Disabled button styles with poor colour contrast
• Image alt text that isn't meaningful
• Adding ARIA to elements for screen reader users

One in four people reports having some form of disability in the United States. One in six reports having a disability globally. Not all users will report their disabilities, and most have more than one disability. When I mention "all users", that should always include users with disabilities.

TDT[5]: You’ve contributed to accessibility testing for the Olivero and Claro themes. What were some of the key challenges or decisions in those projects that made a lasting impact on your approach?

Kat Shaw: With the Olivero theme, working with the National Federation of the Blind (NFB) had the greatest impact. Mike Herchel asked if I'd like to head up the testing with the NFB, and I enthusiastically accepted. They performed excellent testing with real users of assistive technology (AT). They then sent their reported findings along with videos of what they experienced. Accessibility research and usability testing with real-world AT users was a profound experience.

With Olivero and Claro, I performed accessibility testing of their designs. Both sets of designs were in Figma, which I hadn't worked in before. I adapted by using manual accessibility testing techniques, and Figma plugins when available. I continue to test designs for Lullabot and Drupal for accessibility issues to this day. For me, it's an enjoyable experience, as I love working in a collaborative way.

TDT[6]: What are some Drupal-specific challenges that make accessibility remediation more complex compared to other platforms?

Kat Shaw: For me, Drupal contribution through the issue queue is very difficult. I'm not a backend developer. I'm a frontend developer who specialises in accessibility. I love the idea of the Tugboat preview, but it's not always active on issues. When I build the ddev version of Drupal, it doesn't include Git, which is needed for contribution. I wish I could go to one page, run through clear instructions, and have a ddev-based Drupal site with Git integrated. It can be a very frustrating process. I believe that improving that process would be a huge improvement for current and potential contributors, especially those in the accessibility community.

TDT[7]: Your keynote at DrupalCamp Ottawa focuses on ARIA and its role in web accessibility. What do you think are the most common misconceptions developers have about using ARIA, and how can the Drupal community better approach its use to avoid doing more harm than good?

Kat Shaw: As the Five Rules of ARIA state, the biggest mistake with using ARIA is its overuse. It's very important to always default to native HTML, and use ARIA only when necessary. Knowing the purpose of ARIA helps know how to use it. Users of AT, keyboard-only users, and users with cognitive disabilities rely on ARIA. It assists with making navigation, forms, alerts, and so much more available to these users. Without it, 25% of your users can't navigate or take in your content.

TDT [8]: Your project ClassA11y introduces accessibility awareness directly into Drupal admin tools. What motivated you to build this, and how has the community responded to it?

Kat Shaw: I was working as a Frontend Developer & Web Accessibility Specialist for Promet Source at the time. I worked with colleague and friend Lisa Harrison (lisarae).

We were using the Classy theme as our base theme on several projects. We found that we were making regular improvements to it to make it accessible. With that, we joined a team including Steven Wilmes (swilmes), and Aaron Couch (acouch). Our goal was to incorporate our improvements to Classy, with the end goal of the ClassA11y theme. At the time, it worked great. Now that Stable is the default base theme, and the Classy theme has been deprecated, the work on it has stopped over time. My focus moved to the Drupal Accessibility Team to focus on a11y issues for Drupal as a whole.

TDT [9]: On your site, you mention working closely with teams to remediate accessibility issues. Could you walk us through your typical process when auditing and fixing a Drupal site's accessibility?

Kat Shaw: Luckily, I'm able to collaborate with different teams here at Lullabot. That starts with our Design team with audits of design mocks and full design iterations. It then continues on during development with testing components, patterns, layouts, and pages. Storybook is a big part of this part of testing, as we use its accessibility plugin for testing each element.

As we create pull requests (PRs), automated testing is always incorporated. These tests verify that accessibility issues aren't missed, and new ones aren't created. During that process, the PR creates a Tugboat for us to view an instance of the site or app with our changes. That's where we perform a11y testing using tools like browser extensions and bookmarklets.

On request, we also perform whole-site manual audits to catch any missed a11y issues. We then report them using various reporting systems like DubBot and Editoria11y. Then we send those reports to our clients as deliverables.

Incorporating a successful accessibility process into their organisation should focus on:

• Cross-collaboration
• Shift-left methodology
• An always-expanding accessibility program

These steps will result in a layered approach for any accessibility process.

TDT [10]: You help organise A11yTalks, a community-driven event series. What inspired your involvement with this project, and what do you hope attendees take away from each session?

Kat Shaw: Thankfully, my former colleague April Sides recruited me into A11yTalks. The core group had been looking to expand to make things easier for everyone and to add some new faces to the group. I hopped on that train pronto and haven't looked back. The core team of Carie Fisher, AmyJune Hineline, and Donna Bungard were extremely welcoming to the crew of newbies. And our crew thankfully just keeps growing.

I've taken on a lot of the recruiting and people management duties. I work towards finding new and experienced voices alike in the accessibility community. Once they've agreed to speak, we get the ball rolling to record their talk and air it live on YouTube Live. Our goal is to have a mix of technical and general talks for our audience. Some examples of talks we like to have include:

• Show practical A11y testing tools & techniques that they can use daily to fix issues
• Teach about disabilities they may not have experience with
• Help them to think in ways they may not have thought of before
• Explain a11y best practices, standards, and guidelines in a digestible way

We now offer a $100 honorarium that they can keep, donate back to A11yTalks, or donate to a charity of their choice.

TDT[11]: Based on your experience organising events and community spaces like KC Metro Area Government Webmasters and A11yTalks, what’s your advice for fostering inclusive, productive tech communities?

Kat Shaw: It is key to include welcoming communication for your potential and existing speakers. This will create a relationship with your speakers from the beginning and let them know that they are now part of your community.

It's so important to be an inclusive environment, especially for newcomers. That's the only way your community, big or small, is going to grow. With KCMagWeb, we changed our meetings each month so that we met in two areas of Kansas City. This made it easier for everyone to commute to the meeting locations. It also made it easier for bosses to take this time away from the office.

With A11yTalks, we put a great amount of focus on having a diverse group of speakers. We also like to have a diverse group of topics to keep things fresh. Having new speakers is always a goal, as we like to give new speakers new opportunities. Having experienced speakers is wonderful as well. They are always able to share their deep knowledge with our audience.

To have a productive tech community.:

• Delegating responsibilities between team members
• Communicating when you're feeling overwhelmed
• Remember your shared goal
• Keep open communication

It's all a balance, and these steps will almost always result in a happier team.

TDT[12]: Looking at your Drupal.org sandbox and module contributions, such as ClassA11y and others, are there any lesser-known tools or experiments you're especially proud of?

Kat Shaw: There are several Drupal.org projects, groups, and contributions I'm especially proud of being a part of including:

Contribution to core and contributed modules, including:

• Drupal CMS
• Drupal core
• External Links
• Navigation
• Date
• Menu Item Fields
• Webform
• Module Filter
• Taxonomy Views Integrator

I'm also grateful to be part of the following projects now and in the past:

• Drupal contribution through accessibility testing for the Olivero and Claro themes. This includes leading the Olivero theme's assistive technology testing project with the National Federation of the Blind (NFB).
• Working with the Drupal Accessibility Team on Drupal accessibility issues and improvements.
• Giving presentations at Drupal camps and conferences in the U.S. and globally.

I like to keep busy. So, having the opportunity to be a part of all of these various projects “fills my cup” as my friend and colleague Marissa Epstein commonly says. She’s an amazing Content Strategist and a go-getter.

TDT [13]: What’s unique about how Lullabot supports or prioritises accessibility in its projects, and how do you contribute to that culture as a Lead Engineer?

Kat Shaw: Instead of having one Subject Matter Expert (SME), Lullabot has several SMEs. Several are CPACC-certified through the International Association of Accessibility Professionals (IAAP).

With this approach, we're able to:

• Consult with clients on a11y issues they're experiencing
• Chat with internal teams on the best way to remediate issues
• Share our knowledge during internal calls and events
• Give webinars on digital accessibility

Our shift-left methodology incorporates accessibility at every step in a project's life cycle.

TDT [14]: What’s a major accessibility issue or area in Drupal you’d love to see tackled next?

Kat Shaw: These are my top issues I'd love to see tackled specifically by Drupal core:

• Tables: headers and captions aren't required, no handling of responsive tables
• Headings: heading levels skipped, empty headings
• Inline Form Errors: It isn't enabled by default, and I strongly believe that it should be. It adds inline form field errors for each field, as well as a summary of errors above a form. Errors listed in the summary link to each field.

Following standards, guidelines, & W3C accessibility tutorials would help Drupal to be even more accessible.

TDT[15]: If you had the opportunity to build a dream accessibility-first web project—no constraints—what would it be and who would it serve?

Kat Shaw: This would be an exciting prospect, and it's something I've been thinking about. I'd love to build an accessibility-first Drupal starter kit. It would contain a design system that includes components, patterns, templates, and layouts.

I'd likely start with something like the W3C Design System. Although it still uses Sass1, it matches up well with Drupal's use of Symfony and Twig. I'd add and connect Storybook, Single Directory Components (SDC), and Figma to each other. I'd also integrate Editoria11y Accessibility Checker as well.

This is what I'd include for each:

• Figma: Plugins for accessibility testing, states for all focusable elements, & annotations for everything. Style guide containing breakpoints, colors, layouts, headings, fonts, etc.
• Storybook: Accessibility add-on for per-element testing. Base set of accessible components, patterns, templates, and layouts to start a new project.
• Single Directory Components (SDC): A Set of templates seamlessly connecting Storybook components to Drupal. Example components showing how best to set each type up in an efficient and effective way.
• Editoria11y Accessibility Checker: Accessibility dashboard. This is where you can review automated issues, and add manual testing results (in the future?). In-page automated checking, including in CKEditor, is also included. This is invaluable during all steps of development and content entry.
• I'd also have a home for a suite of testing tools, including those listed in my article How Cool Accessibility Tools Can Make Your Life Easier.

This setup would allow for an accessible starting point for any Drupal site. You could use basic HTML, CSS, and JavaScript, as well as ReactJS if that interests you. Separating Sass from the W3C Design System would be the only pain point in this plan, but I think it's doable. I like the challenge.