Mike Gifford: Accessibility Must Move Upstream in Public-Sector Open Source

Public institutions can reduce recurring accessibility failures by contributing fixes upstream in the open-source projects they rely on, Mike Gifford, senior strategist at CivicActions, said in an interview with The DropTimes after UN Open Source Week 2026.

Mike led the Maintain-a-thon session “Governments, Open Source and Accessibility: Contributing to a Common Solution” at UN Open Source Week 2026, held at the United Nations Headquarters in New York from 22–26 June 2026. The interview opens a five-part Open Source Week series examining how public institutions can make accessibility part of shared open-source maintenance. The conversation places Drupal’s accessibility history within public-sector debates over procurement, regulation, AI-supported development, and sustainable open-source maintenance.

The regulatory context is also shifting. The European Accessibility Act required EU Member States to incorporate the directive into national law by June 2022, while the FY 2025 Governmentwide Section 508 Assessment in the United States has renewed attention on governance, procurement, testing, remediation, and accountability in federal digital accessibility.

Accessibility and public-sector open source

TDT [1]: In your Maintain-a-thon workshop, “Governments, Open Source and Accessibility: Contributing to a Common Solution,” you focused on helping organisations build more inclusive and sustainable digital services. What do public institutions often misunderstand about accessibility when they enter open-source policy conversations?

Mike Gifford: Digital teams often understand either open source or accessibility, but rarely both. One of the goals of my workshop was to show that, while accessibility is a broad and sometimes complex field, getting started is not. The fundamentals are straightforward: use automated testing tools, perform manual testing, and involve people with disabilities throughout the design and development process. The session was designed as a practical introduction for people interested in open source who wanted to understand how accessibility fits into building better digital services.

I also wanted to challenge a common misconception. Like proprietary software, open source projects have accessibility issues. The question is not whether bugs exist, but how a project identifies, prioritizes, and resolves them. Evaluating an open source project means looking beyond the number of open accessibility issues. It means asking whether accessibility is built into the project’s governance, development practices, testing processes, documentation, and community culture.

One advantage of open source is that governments are not limited to reporting problems or purchasing workarounds. They can contribute fixes, improve documentation, fund maintainers, and help strengthen the software for everyone. That is one of the reasons open source is such a powerful model for building accessible and sustainable digital public infrastructure.

For people interested in learning more, I have published additional notes from the workshop at https://ox.ca/p/7.

TDT [2]: Accessibility is often treated as compliance work at the end of a project. What would it look like if governments treated it as part of procurement, design, development, testing, and maintenance from the start?

Mike Gifford: There is a well-established concept in software engineering called shift-left. The idea is simple: identify and fix problems as early as possible, when they are less expensive and easier to resolve.

You May Like

Interview

The Drupaler-Therapist Who Diagnoses More Than Code

Interview

The Drupaler-Therapist Who Diagnoses More Than Code

Accessibility is too often left until the end of a project. By then, the budget has been spent, the architecture is fixed, and teams are forced to apply temporary workarounds instead of addressing the underlying problems. Compliance becomes an expensive exercise rather than part of building quality software.

Open source provides an opportunity to shift accessibility much further left. Instead of fixing the same issue separately in dozens or hundreds of government deployments, agencies can contribute improvements to the upstream project. A single accessibility fix in a widely used open source project can benefit thousands or even millions of websites when they upgrade. Those improvements are also more likely to be maintained over time because they become part of the project’s normal release process.

A single accessibility fix in a widely used open source project can benefit thousands or even millions of websites when they upgrade.

Accessibility should not belong to a single specialist or be treated as a final compliance review. The W3C’s Accessibility Roles and Responsibilities Mapping (ARRM) shows how accessibility can become part of everyone’s job, from procurement and product management through design, development, testing, content creation, and ongoing maintenance. When every role understands its responsibilities, accessibility becomes part of the definition of quality rather than a separate activity.

Procurement has an important role in making this possible. Governments should evaluate not only whether a product meets accessibility requirements today, but whether vendors have mature accessibility practices, contribute improvements upstream where appropriate, and have a credible plan for maintaining accessibility over time. The recent Governmentwide Section 508 Assessment reinforces this approach, recommending stronger governance, better procurement practices, continuous testing, and accountability throughout the acquisition process, rather than relying on end-of-project compliance reviews.

Regulation, Drupal, and AI

TDT [3]: The European Accessibility Act came into effect on 28 June 2025, while the EU Web Accessibility Directive already applies to public-sector websites and mobile apps. How should open-source projects respond to this stronger regulatory environment without reducing accessibility to a checklist?

Mike Gifford: It is important to remember that the European Accessibility Act is not a single, uniform law across Europe. It is an EU Directive that each Member State has implemented through its own national legislation. While the overall objectives are shared, the enforcement mechanisms, penalties, and regulatory approaches vary from country to country. Vendors working across Europe should assume that they may need to satisfy the requirements of multiple national authorities rather than treating compliance as a one-time exercise.

The legislation is also not tied directly to WCAG. Instead, it references the European standard EN 301 549, which in turn incorporates WCAG and is expected to be updated as accessibility standards evolve. That means accessibility is not a fixed target. Organizations need to monitor changes in both technical standards and national legislation over time.

For open source projects, this is another reason to build accessibility into normal engineering practices rather than treating it as a compliance checklist. The United States and European markets are both increasing the legal, financial, and reputational risks of shipping inaccessible software. Development teams should receive accessibility training, integrate automated accessibility testing into their CI/CD pipelines, perform regular manual testing, and involve people with disabilities throughout development.

Perhaps most importantly, organizations need to demonstrate continuous improvement. Regulators, customers, and procurement teams increasingly want evidence that accessibility is part of an organization’s governance, development process, and quality assurance practices. Open source projects are well positioned to provide that transparency through public issue trackers, documented testing, open governance, and a visible history of ongoing improvements.

Related Drupal context is available in the Drupal Association article “A New Era of Digital Accessibility: The EAA and Its Implications for Drupal.”

TDT [4]: What can Drupal’s long accessibility history teach public institutions about building digital services that are trustworthy, inclusive, and maintainable?

Mike Gifford: Drupal’s accessibility history shows that inclusive software does not happen by accident. It requires leadership that consistently treats accessibility as a core measure of quality, even when that means delaying other priorities. Throughout its history, the Drupal community has repeatedly chosen to fix significant accessibility issues before releasing new versions. That sends a clear message that accessibility is not optional or something to address later.

Drupal has also shown that the biggest advances come when people with disabilities are active participants in the community. Standards such as EN 301 549 and WCAG provide an essential foundation. Design systems, automated testing, and accessibility experts all play important roles. But none of these replace the insights that come from people with lived experience. Building inclusive software starts with building inclusive communities.

Governments can learn from this approach. Accessibility should not depend on a single specialist reviewing work at the end of a project. It should be embedded throughout procurement, design, development, content creation, testing, and maintenance. Frameworks such as the W3C Accessibility Roles and Responsibilities Mapping (ARRM) help define what each role contributes, making accessibility part of everyone’s responsibility rather than one team’s job.

AI will become an increasingly valuable tool for identifying issues, reviewing code, and supporting developers, but it cannot tell us whether a service is genuinely usable or empowering. Digital services should remain human-centred. That means combining standards, testing, and automation with continuous feedback from people with disabilities. Technology can accelerate accessibility, but people must continue to define what accessible experiences look like.

TDT [5]: Your workshop description connects open-source tools, AI, inclusion, and sustainable digital services. Where can AI help accessibility work, and where can it introduce new risks?

Mike Gifford: AI is a tremendous amplifier. It can help us build software faster, review more code, summarize reports, explain accessibility requirements, generate documentation, and even identify patterns that humans might overlook. Used well, it has the potential to make accessibility work more efficient and more widely adopted.

The same amplification creates risks. AI can also generate inaccessible code, misleading advice, poor alternative text, and inconsistent recommendations at a scale we have never seen before. If teams rely on AI without appropriate oversight, they can produce inaccessible software much more quickly than before.

That is why guardrails matter. Accessibility guidance, coding standards, design systems, and reusable prompts help AI produce better results. Resources such as ACCESSIBILITY.md guidance and the accessibility-skills project are designed to give both developers and AI assistants a stronger foundation for producing accessible software.

Just as importantly, we should continue to rely on deterministic testing wherever possible instead of asking an AI to make decisions that established tools can verify objectively. Tools such as axe-core have become trusted across the accessibility industry because they produce repeatable, testable results. AI should complement those tools, not replace them.

AI should complement those tools, not replace them.

The next opportunity is combining those mature testing tools with AI. Projects like a11y-meta-skills demonstrate how automated accessibility testing can be enriched with AI to explain results, prioritize issues, identify patterns across large codebases, and suggest practical next steps. That allows AI to add value where human judgement is needed, while leaving objective testing to tools that have already earned the community’s trust.

Testing, authoring tools, and collaboration

TDT [6]: Automated accessibility scanners are useful, but they miss many real user barriers. How can government teams and open-source communities build lived-experience testing into normal development workflows?

Mike Gifford: Automated testing is an essential part of accessibility, but it can only identify certain types of issues. It cannot tell you whether a process is understandable, whether a screen reader workflow is efficient, or whether someone with a cognitive disability can successfully complete a task. There are many ways to use and configure assistive technology, and automated tests can’t cover all of these. Those insights come from people.

The first step is building more inclusive teams. Organizations should make it clear that they value the lived experience of people with disabilities and actively encourage them to apply for roles within your organization. Many disabilities are invisible, and many people choose not to disclose them because they fear discrimination. Creating an environment where accessibility experience is recognized as an asset helps bring those perspectives into everyday design and development decisions.

The second step is recognizing that lived experience has value and should be compensated. Governments and organizations should budget for accessibility testing by people with disabilities, just as they budget for security reviews or usability research. Whether through formal research engagements or smaller honoraria, people should not be expected to volunteer their expertise. As Dries Buytaert recently reflected, “Free time is a privilege, not an equal right.” If we want more inclusive software, we need more inclusive participation.

Finally, accessibility testing should become a normal part of procurement and delivery. Governments should ask vendors how they involve people with disabilities throughout design, development, and testing, and they should budget for that work from the beginning. U.S. guidance from the Office of Management and Budget called for strengthening Section 508. M-24-08 recognized the importance of incorporating feedback from people with disabilities into accessibility programs. Lived experience should be treated as an essential part of quality assurance, not as an optional nice to have.

Automation, standards, and AI all have important roles to play. But none of them can replace listening to the people who use these services every day.

TDT [7]: What is one practical accessibility contribution a public agency could make upstream instead of solving the same problem privately?

Mike Gifford: Governments should start by improving the software they already depend on every day. Nearly every digital service relies on open source components, and many of those include user interfaces used by public servants to create and manage content. Rather than maintaining private patches, agencies should contribute accessibility improvements upstream so that every organization using that software benefits.

One area where governments could make a particularly important contribution is improving authoring tools. Standards such as the Authoring Tool Accessibility Guidelines (ATAG) recognize that accessible websites depend on accessible authoring environments. Most content authors are subject matter experts or communications professionals. They are not accessibility specialists, and they should not be expected to memorize accessibility requirements. The tools they use should guide them toward producing accessible content by default.

Despite ATAG having been a W3C Recommendation for more than a decade, there are still very few tools that comprehensively evaluate or support it. This represents an opportunity for governments. They could fund better testing tools, improve widely used content management systems such as Drupal, and invest in features that help authors create accessible content as they work. Those improvements would benefit thousands of public sector organizations and millions of content creators.

Governments can also reinforce this through procurement. Contracts should encourage vendors to contribute accessibility improvements upstream and demonstrate how those contributions strengthen the wider open source ecosystem. Organizations such as Germany’s Sovereign Tech Agency have shown how public investment in shared digital infrastructure can produce benefits far beyond a single project. Similar investments in accessibility could have an equally broad impact.

The European Commission’s We4Authors initiative demonstrated the value of involving authors themselves in evaluating the tools they use. We need more research and more investment in authoring experiences because accessible digital services begin long before a page is published. They begin with giving authors the support they need to create accessible content from the start.

TDT [8]: If governments, OSPOs, funders, and open-source communities could take one concrete step together before the next UN Open Source Week, what should it be?

Mike Gifford: The most important step is surprisingly simple: spend more time working together.

Governments, OSPOs, funders, researchers, accessibility experts, and open source communities all face many of the same challenges. Too often, they solve them in isolation. We need more opportunities to share what works, what failed, and where we can invest together instead of duplicating effort.

That means governments should make participation in communities and events part of their digital strategy, not an optional activity. Events such as UN Open Source Week, EU Open Source Week, MozFest, DrupalCon, and regional open source gatherings are where partnerships form, ideas are challenged, and shared solutions emerge. The value is not just in the presentations. It is in the relationships and trust that develop between people working on similar problems around the world.

We also need more local collaboration. Bringing together governments, universities, nonprofits, open source maintainers, accessibility professionals, and people with disabilities helps communities identify shared priorities and pool resources. Small, regular local events can often have as much long-term impact as international conferences because they create lasting networks of people who continue working together.

The challenges we face, from accessibility and AI governance to digital sovereignty and sustainability, are too large for any one organization to solve alone. Open source succeeds because it enables collaboration across institutions and across borders. The more we invest in those relationships, the stronger our shared digital infrastructure becomes.