Building Accessibility That Lasts: Engineering Lessons from “Web Accessibility” by Jeremy Chinquist (drunomics GmbH)

Why it matters right now

We attended “Web Accessibility” by Jeremy Chinquist (drunomics GmbH) at a critical moment. The European Accessibility Act goes into effect “later this month,” and EU member states are set to start enforcement “in June of 2025.” Jeremy’s core message was simple and demanding: websites, products, and services must be accessible. He anchored the idea with the Cambridge Dictionary definition—accessibility is “the quality of being able to be entered or used by everyone, including people who have a disability.” The consequence is clear: a product must be usable “in the same quality or way” by people with and without disabilities.

It’s a powerful framing. Accessibility is a product quality attribute, not a cosmetic add-on. And as Jeremy stressed, turning that simple definition into a reliable reality “takes a lot of energy.”

The problem space: Equal quality, not just legal checkboxes

Jeremy positioned accessibility as an interplay of many “little things” that add up to a usable experience. These are measurable against the Web Content Accessibility Guidelines (WCAG), which provide levels and criteria. He also noted an important caveat: he is “not a lawyer,” and legal questions warrant consultation with one. Still, in his role as CISO, he must know which WCAG level their product needs to support.

That balance—owning the responsibility, selecting a target, and executing pragmatically—set the tone for a deeply practical talk. It’s not about patching isolated issues. It’s about making architecture, frontend, and ongoing product processes work together for accessibility.

The technical pillars: What websites must support, per the session

Jeremy enumerated the essentials that collectively form the baseline for accessible websites:

• Screen reader support: Pages must be readable by screen readers.
• Skip links: Users need to jump around the page efficiently via skip links.
• Well-structured h-tags: Headings should express page structure to enable comprehension and navigation.
• Focus order: Interactive elements must be focusable in a logical order.
• Alt tags for images: Images need descriptions for users who cannot see them.
• Color contrast: Content must be distinguishable from background—vital for users who are hard of seeing.

Each of these pieces “plays together.” Omit one, and you degrade the overall experience. As Jeremy underlined, these qualities are measurable through WCAG.

Architecture and tools: Plan early, choose wisely

The most cost-effective route to accessibility is to plan for it. Jeremy illustrated this with their product “Mossball,” built on the open-source content management system Drupal with a custom frontend using Nuxt. Two points stood out:

1) Drupal has planned for accessibility; it is “accessible” in its foundation.

2) Dronomics (as Jeremy framed his workplace context) planned for accessibility in the frontend too.

From an engineering vantage point, that becomes an actionable pattern: adopt a platform where accessibility is a first-class concern, then design your frontend so it preserves and extends that strength.

Internal auditing and continuous improvement: A sustained process

Jeremy described an internal audit led by Wolfgang Leitner, who has performed accessibility audits for other companies. The audit identified where Mossball could improve and how to “keep these improvements going over a longer period of time.”

Impact followed quickly: Mossball “became better.” When the product went live with several clients, those clients benefited from the accessibility that had been built in. And as further enhancements ship, they are “incorporated” back into existing clients. That turns accessibility into an ongoing maintenance promise, not a one-off task.

This sustained improvement loop is crucial. One-time fixes don’t survive content and UI changes. Jeremy’s phrasing—maintaining improvements over time—implies a product discipline: keep accessibility in the definition of done, in reviews, and in release cadences.

External validation and certification: The next milestone

Beyond internal audits, Jeremy laid out the next steps: pursue external auditing or certification as an accessible product, with the ability to place the “WCAG standard logo” on the product. That’s not only a trust signal; it’s also a mechanism to keep quality visible and accountable.

The legal frame: Responsibilities, timelines, and risk

The session provided a grounded view of the legal landscape—without replacing legal counsel:

• In the EU, member states are responsible for enforcing the European Accessibility Act.
• Enforcement is “supposed to start in June of 2025”—“in the next few weeks,” as Jeremy put it.
• In Austria, depending on “how your product meets accessibility standards or doesn’t,” fines can reach “about €80,000.”
• Existing websites have “about five years” before they must comply.
• If a website is launching or relaunching now, it “should actually be accessible from day one.”

The strategic message is straightforward: start early. Especially for new launches, accessibility isn’t something to layer on—it has to be part of the architectural and product decisions from the outset.

A product strategy in practice: Mossball

Mossball planned for accessibility from the outset—built on Drupal with a Nuxt frontend. The internal audit by Wolfgang Leitner served as a catalyst, illuminating improvement areas and setting up a long-run approach. Clients who launched on Mossball benefited immediately, and future clients get the latest changes. Crucially, improvements are rolled back into existing clients as well.

This plan–audit–improve–ship–sustain loop is the playbook we took from the session.

A practical guide for engineering teams (grounded in the session)

Without stepping beyond the talk, Jeremy’s points map cleanly onto an engineering-ready plan:

1) Create commitment

• Treat accessibility as a quality objective: same quality of use for everyone.
• Understand your legal context: European Accessibility Act, national enforcement, and timelines. (Jeremy’s caveat applies: consult a lawyer for legal questions.)

2) Choose architecture that supports accessibility

• Foundation: Use a platform that has accessibility planned in. Drupal was named in the session.
• Frontend: Build your custom layer—Nuxt in the example—so it preserves core requirements (screen reader support, skip links, heading structure, focus order, alt text, color contrast).

3) Use early planning as a cost lever

• Don’t bolt on accessibility later. Jeremy’s experience: planning early is the most cost-effective path.

4) Run an audit

• Internal audit: Engage experienced reviewers—like Wolfgang Leitner in the example—to identify improvements.
• Design for longevity: Implement changes in ways that “keep improvements going over a longer period of time.”

5) Ship improvements continuously

• New clients receive the latest state.
• Fold enhancements back into existing clients.

6) Seek external validation

• Move toward external auditing or certification to make conformance visible (including the option to place the WCAG logo).

Zooming in on the fundamentals

Let’s unpack the elements Jeremy highlighted—not to add new requirements, but to clarify their engineering implications:

• Screen readers: Content must be readable and structured so assistive technologies can traverse and present it reliably.
• Skip links: Users need a way to jump to primary content sections rather than navigating everything linearly.
• Heading structure (h-tags): Logical heading levels communicate document structure and enable understanding and navigation.
• Focus order: Interactive elements should follow an order that makes sense as users move through the page.
• Alt text for images: Images need descriptions so their meaning is available even when the image cannot be seen.
• Color contrast: Content should stand out from backgrounds; contrast is a key element for users with limited vision.

Each of these is individually comprehensible; the hard part is making them work together across templates, components, and content.

What we learned from the session

• Accessibility is a promise of equal quality, not only a legal necessity.
• The “little things” (screen readers, skip links, headings, focus order, alt text, contrast) collectively define the user experience.
• WCAG provides measurable criteria and levels; choosing a target level is both a product and compliance decision. (Jeremy noted he is not a lawyer.)
• Planning early is the most cost-effective path to accessible products.
• Combining an accessible base (Drupal) with a carefully designed custom frontend (Nuxt) is a strong architectural pattern.
• Internal audits create visibility and yield actionable, sustainable improvements.
• Improvements should be shipped continuously to new and existing clients.
• External audits and certification help build trust and keep quality visible.
• EU member states will enforce the act beginning “in June of 2025,” with Austria citing potential fines of “about €80,000” depending on nonconformance.
• Existing sites have “about five years,” but new launches should be accessible “from day one.”

Who should pay particular attention

• Product leaders who need to align quality and compliance.
• Engineering and frontend teams responsible for structure, navigation, and content presentation.
• CMS integrators who want to leverage platforms like Drupal for accessible-by-design foundations.
• Organizations planning a launch or relaunch where accessibility must be baked in.

Resources cited in the session

Jeremy pointed attendees to the following:

• Product: mossball.com
• Company site: dronomics.com

He also noted that a blog post on dronomics.com was featured in the Drupal Association’s newsletter “last week.”

Conclusion: Accessibility as an engineering principle

“Web Accessibility” by Jeremy Chinquist (drunomics GmbH) distilled a clear mandate: accessibility is the ability to be used by everyone, including people with disabilities, at the same level of quality. The path runs through fundamentals—screen readers, skip links, heading structure, focus order, alt text, and color contrast—measured by WCAG. It continues with process: plan early, audit, improve, and pursue certification. Legal timelines give urgency; product quality gives purpose.

Mossball is the concrete illustration: built on Drupal with a Nuxt frontend, internally audited, improved continuously, and aiming for external certification. Teams that adopt this loop deliver better experiences for everyone and are well-positioned as member states begin enforcement.

The clear takeaway echoed throughout the talk: if your site is launching now, it should be accessible “from day one.” Existing sites may have “about five years,” but starting now saves effort, reduces risk, and leads to products that simply work better for all.

• 

  

  Agile Development at drunomics

  Jeremy Chinquist von drunomics spricht in seinem TechTalk über die Grundgedanken der agilen Entwicklungsmethode, welche beim Developer Team im Unternehmen zum Einsatz kommt.

  Watch now
• 

  

  Professionelle Web Entwicklung aus Österreich

  Oliver Berndt von drunomics zeigt in seinem devjobs.at TechTalk die Kernkompetenzen von dem Unternehmen und wie sie mit Drupal arbeiten.

  Watch now
• 

  

  Security- und Risiko-Management

  Jeremy Chinquist von drunomics erzählt in seinem devjobs.at Interview darüber, wie das Unternehmen mit Security- und Risiko-Management umgeht und welche Standards eingehalten werden.

  Watch now
• 

  

  mossbo Cloud CMS Ecosystem

  Wolfgang Ziegler von drunomics gibt in seinem devjobs.at TechTalk einen Überblick über die grundlegenden Funktionen von mossbo und welche Benefits es im Vergleich zu anderen CMS' gibt.

  Watch now

• 

  

  Sinduri Guntupalli, Product Manager bei drunomics

  Sinduri Guntupalli von drunomics spricht im Interview über ihren technischen Background und das Besondere an der Arbeit mit Drupal.

  Watch now