Accessible Forms and mass pdf - a Talk with Markus from axes4

In this episode, I speak with Markus Erle, CEO of axes4, one of the largest service providers for accessible PDFs. We talk about their product lineup and, in particular, new tools for creating accessible forms directly from Word and automatically generating accessible PDFs within existing workflows. This text has been optimized with AI; all errors and inaccuracies are my own.

Domingos: Hello and welcome to a new podcast on digital accessibility! Today, I have another exciting guest with me: Markus Erle from axes4. First of all, thank you so much, Markus, for taking the time to join the podcast.

Markus: Thanks for the invitation, Domingos. I'm really glad to be a guest on your show.

About Markus

Domingos: The pleasure is all mine. First question—for the few people who might not know you yet: Could you briefly introduce yourself?

Markus: Sure, happy to! I’ve been involved in digital accessibility for a very long time—not just PDF accessibility, but overall. It’s been over 22 years now. I originally came from web accessibility before we discovered the topic of PDF accessibility.

Back then, my agency for web accessibility won three Biene Awards. The older listeners among us will remember what that was. I think the last Biene was awarded in 2008 or 2010. In the German-speaking region, it was a very important accolade for accessible websites.

I believe "Biene" stood for „Barrierefreies Internet eröffnet neue Einsichten“ (Accessible Internet Opens New Insights)—or something along those lines. Exactly. It was launched back then by Aktion Mensch and the Digital Opportunities Foundation.

There were always great parties. That’s probably where we met for the very first time, right Domingos?

At some point, I realized: Web accessibility is great, and there are people who handle it quite well now. But heaven forbid you click a download link and fetch a PDF. Digital participation comes to a screeching halt because you suddenly end up with an inaccessible PDF. And nobody was taking care of it.

Working with Adobe Acrobat isn't much fun either. We always say: Having to tag PDFs in Acrobat is like being sent to a Siberian labor camp—or needing a support group afterward if you’ve tagged too often. It’s just ridiculously complicated, files get corrupted constantly, and so on.

How I originally got into accessibility: My roots are actually in usability, and funnily enough, already related to PDFs. Sitting here, it almost feels like a confession: Back then, we had the strange idea to build interactive PDFs and optimize their usability. Imagine something like a website made out of a PDF.

That was actually a trend at the time. We thought, "Come on, let’s try this out." Fortunately, that led me into accessibility because I reconnected with a former university colleague. I had lost track of him, and we bumped into each other by chance. We knew each other from studying literature and theater. By trade, I’m a communications scientist, philosopher, and Latin Americanist—a humanities scholar. Both of us had studied that and met again years later.

He was already fully immersed in the accessibility community, and I immediately caught the bug. It’s a fantastic community!

22 years ago, we helped each other acquire knowledge because neither of us was an expert back then. We tackled the subject together.

And Domingos, you joined the scene relatively early, too. You still remember how it was. It was a great community, and it still is today. It has grown larger, and we need young talent to carry it forward. So that was my entry into digital accessibility.

Why did it hook me so intensely? Very simple: I have a bit of a "genetic flaw"—I must do meaningful work. I want to make the world a better place, I need purpose in what I do, and I saw that right there.

It was immediately obvious to me that we aren't just designing for an ideal user. There are people with diverse requirements and perceptual needs. We must keep people with disabilities in mind and implement solutions accordingly.

The Challenge of Accessible PDFs

Domingos: What makes documents and PDFs so different compared to web accessibility?

Markus: Well, for one thing, at a certain point, plenty of people started caring about web accessibility, whereas PDF accessibility was treated like a stepchild. I think there was barely any knowledge about it. The crazy thing is: At its core, it’s very similar to websites. You simply need semantic information, the markup—this is a heading, this is a paragraph, here’s a blockquote, here’s a link, a list with three items, a table with rows and columns—all these extra pieces of structural information. There’s a huge overlap.

However, PDF is a completely distinct format. It wasn't invented for accessibility; it was created so that a file looks visually identical regardless of the screen or printer used to render it.

Back then, that was revolutionary. If you printed a Word document or sent it to a friend to print, you could bet it would look different on their end. PDF fixed the layout.

Now we can see right away that this is almost the exact opposite of accessibility requirements. Accessibility requires content to adapt to a user's perceptual needs—meaning you want an adaptable layout, not a fixed one.

With PDFs, a technical solution was introduced relatively early on. An invisible structure layer was created inside the PDF, which is somewhat comparable to HTML code. It uses tags and similar concepts.

The fascinating part is that you essentially have two layers. You have the visual layer—what everyone sees, what gets printed or viewed on a screen. And you have the structural layer—what gets read out by assistive technologies.

It’s crucial that the visual content and the structural information match 1:1. If a blind user talks to a sighted user and says, "Go to page 5, second heading," both should actually arrive at the exact same heading.

Additionally, PDFs have requirements inherent to the format itself—bounding boxes and extra attributes, for example. The logic is entirely different from HTML.

Because of this, people who know HTML well often struggle with PDFs. Knowing HTML helps you grasp the concept of tag structures, but web logic doesn't get you very far with PDF. There are many quirks.

PDF is naturally a page-based format. There is a content stream and a pointer to the tag structure. But going into specific challenges might get too technical. The bottom line is: If you have good software, those complex technical details are handled for you automatically.

That was our niche. It’s why we founded axes4 twelve years ago. As CEO of axes4, we specialized completely in PDF accessibility. We realized that mainstream providers like Adobe and Microsoft weren't addressing PDF accessibility adequately, making the creation of accessible PDFs overly complicated. We wanted to drastically simplify that process. That was essentially the birth of axes4.

Domingos: Exactly, that’s a great segue. axes4 is indeed one of the few global champions in accessibility—most companies in this space come from the US. From the DACH region, I believe you are the only ones having such a broad impact.

Markus: Oh, thank you! That’s lovely to hear. Yes, that’s true. I often say you can count on one hand the companies worldwide that truly understand PDF accessibility inside and out.

We are represented on all key committees and help develop standards further. We know the industry very well. Even within the PDF Association—the trade group where the PDF industry meets and every major player is a member—our expertise on PDF accessibility is actively sought after and valued. That feels great, of course.

About axes4

Domingos: Maybe you could give us a brief overview of your current software product lineup?

PAC - PDF Accessibility Checker

Markus: Sure! I'll walk through it chronologically. When I first got into PDF accessibility, my first question was: How do you actually know if a PDF is accessible?

We needed good, free testing tools. At the time, Adobe Reader had a very rudimentary accessibility check, but it wasn't meaningful at all. It was tailored strictly to Adobe features, leading to many false positives for things Acrobat simply couldn't handle or that needed to be solved differently.

So, about 16 years ago—before axes4 properly existed—we released PAC, the PDF Accessibility Checker. That was our first product, and it’s still around today. It is even funded by the German Federal Ministry of Labour and Social Affairs (BMAS), which we are very proud of.

We recently released the beta version—currently still an alpha version—of PAC 2027, featuring a fully optimized and accessible user interface. Previously, we supported accessibility by hooking into standard APIs, but that wasn't enough.

We had to switch technologies to web tech, which allows us to integrate maximum accessibility natively. That’s how the new PAC will be structured.

So that was our first product—a tool to at least check whether a PDF is accessible.

I'd recommend this to anyone listening who hasn't worked with PDF accessibility yet: Download the free PAC tool and test a PDF to get an initial overview.

PAC offers automatic checks as well as additional inspection views. In theory, you could evaluate all requirements with it. The automated checks give an initial direction, though they aren't enough for a final compliance verdict on their own.

It also offers a screen reader preview. You can inspect the structural layer inside the PDF that is normally invisible, rendering the content and its underlying attributes.

That means PAC allows you to inspect files in depth—all with a free tool. It’s a great asset.

axesPDF

We eventually realized: It’s nice to test files and find out they aren't accessible, but there has to be an easy way to make them accessible.

At first, we used internal tools for our own tagging service to simplify the process, because doing it in Adobe Acrobat was a pain in the ass, to put it bluntly.

From that internal toolbox, we created axesPDF. Think of it as a professional version of PAC: You can inspect files, fix errors, and resolve issues, down to basic tagging.

We are expanding its capabilities further. Ultimately, axesPDF is intended to replace Acrobat so that users don't need another tool. Not just checking, but creating and remediating accessible PDFs—that is axesPDF.

axesWord and axesSlide

In parallel, we noticed that public sector agencies are required to produce accessible PDFs. Where do they create them? In Microsoft Word, mostly.

That’s where my background as a trainer for accessible PDFs came in. You know me, Domingos: I always try to bring energy and fun into it, much like you do.

I always think: If people laugh, the information sticks better than if everything is deadly serious.

During my training sessions back then, everyone was enthusiastic at the start and through lunch. But by the end of the day, people were frustrated because it was so complicated.

I would tell them, "Do everything correctly in Word, convert it, and then fix the remaining errors manually." Their faces would just fall.

So I said: We need a tool that rewards users when they do things right in Word, allowing them to create an accessible PDF at the push of a button.

That was the birth of axesWord, our second product.

Around that time, I met Samuel Hofer, our CTO at axes4. Markus Riech from the "Access for All" foundation, who was managing director at the time, introduced us.

Interestingly, he introduced us at an Adobe-hosted roadshow at the World Trade Center in Zurich.

That’s where we met for the first time. Markus Riech brought us together, and we started developing solutions. When we felt the technology was mature, we decided to launch a company. That’s how axes4 was born.

We launched with two main products: axesPDF and axesWord.

Then came demand from users asking, "Do you have something like this for PowerPoint?" So we developed axesSlide (formerly axesLite). The strategy remained the same: Do everything right in PowerPoint, and get rewarded when converting with axesSlide.

With both axesWord and axesSlide, we added extra capabilities for authors. We expanded the accessibility offering so you can set accessibility properties directly within Word or PowerPoint using the extended features our tools provide.

Just one example: In native Word, you cannot properly mark up complex tables. You simply don't have the control. With axesWord, you gain that control, making even complex tables fully accessible without hassle.

axesFlip

In recent years, we added axesFlip—a workflow system designed to make large volumes of PDFs accessible all at once.

There's a backstory here: Ahead of the European Accessibility Act and the national implementations, we asked our corporate clients, "What does the market need to offer accessible documents quickly and easily?"

Companies generate invoices, quotes, and similar documents at scale. Online shops must be accessible. These documents are generated automatically out of workflow systems.

We thought: If the PDF is generated automatically, it should be possible to make it accessible automatically as well. The layout information exists somewhere in the system—within templates or configuration files—because the PDF visual layout is already defined.

To be honest, our initial plan was to generate accessible PDFs directly from raw data. But when we asked our clients, "Do you want us to build accessible PDFs from raw data or from existing PDFs?"

Their response was: "Keep your hands off our core systems! You get the PDF. Give us a software module that takes the generated PDF and turns it into an accessible document without us having to overhaul our entire workflow."

And that is precisely what we built with axesFlip.

axesFlip is modular. It uses different nodes to map out various deployment scenarios.

The key takeaway: When a PDF comes out of an automated system, axesFlip can make it accessible using a template-based approach.

We are also working on an AI node, but AI brings its own trade-offs, which we can touch on later.

In its core version, axesFlip doesn't require AI to make automated PDFs accessible—using AI for structured templates would be overkill.

The template approach is resource-efficient, reliable, and deterministic. We can guarantee the output quality and result, which isn't as straightforward with AI.

To summarize: We started with PAC, followed by axesWord, axesSlide, and axesPDF, and most recently axesFlip for mass production of accessible PDFs.

Accessible Forms from Word

Domingos: Let’s look at a few features that are relatively new.

Starting with the capability to create accessible forms directly in Word: Most people don't realize that standard Word forms aren't accessible and that fillable form fields don't convert properly into PDFs via standard export.

So this is a very useful feature. Tell us a bit more about how that came to be.

Markus: Exactly. As you mentioned, Word has a legacy feature for adding form fields, but it’s essentially deprecated and doesn't convert into accessible PDF forms.

We received endless inquiries about this: "Why can't I convert forms into accessible PDF forms using axesWord?"

That was one driver. The other was that whenever we plan new features, we ask our customers where their main pain points lie.

Creating forms from Word was by far the biggest pain point and gap. People told us, "We want to build forms directly out of Word."

So we said, "Alright, if that's what you need, we'll build it."

We approached it with the same philosophy as axesWord: keeping it straightforward for the author.

You can set up accessibility features directly in Word, including default values and standard form field types you know from Acrobat.

The first version doesn't support custom scripts yet, though that’s on our roadmap. We wanted to release a reliable version within a reasonable timeframe. The initial release already covers 80% of common use cases: defining the visual presentation in Word, supporting various field types, and even signature fields. The feedback has been overwhelmingly positive.

What touched me personally: At the ICT Forum in Linz during the second week of July, we hosted our annual PDF accessibility panel. Gerhard Nussbaum presented the new axesWord form features. Gerhard uses a wheelchair, has no movement in his arms, and operates Word using a mouth stick. He demonstrated how a person with a disability can independently create accessible forms using Word combined with axesWord.

That really resonated with me. Ensuring people with disabilities can consume documents is crucial, but it should be equally natural for people with disabilities to create accessible content themselves. I call this Equal Production—not just Equal Access, but Equal Production. That needs to be possible, and we support it through our software.

axesWord is certified—its user interface passed the BITV software test for accessibility compliance. We applied the same standard to the new form features. People tell us, "Wow, this is even easier than using InDesign."

InDesign used to be the default choice for building form layouts. While InDesign allows for more complex graphical layouts than Word, Word works great for standard forms. You can use layout tables and linearize them properly afterward—another native axesWord feature.

It’s designed for quick, simple to moderately complex forms—like setting up an internal event registration form quickly within a company.

Automating Document Accessibility from Workflows – axesFlip

Domingos: Definitely a great feature that addresses high demand.

Another interesting area is batch processing, which you touched on earlier—eliminating the need to manually remediate identical, high-volume documents. Manually remediating every bank statement, invoice, or notice—thousands of which are generated daily—would require immense effort. Could you elaborate on that?

Markus: Exactly. Industry statistics from Adobe suggest that roughly 80% of all PDFs originate from automated workflows rather than being authored manually in Word or similar desktop applications. They are generated automatically by billing systems, ERPs, or financial software.

These are often "invisible documents"—files sitting behind paywalls or user logins, like downloading a utility bill from a customer portal or an invoice from an e-commerce platform.

There was a major gap here: These automated documents must be accessible as well.

We designed a solution compatible with any underlying system. If a PDF comes out of an automated workflow, it can be made accessible automatically.

If we want to achieve true digital participation, accessibility must become an invisible part of the digital infrastructure—Accessibility by Design or Accessibility by Production. PDFs should be accessible by default.

It has to scale. That reflects the core vision of axes4: We want to reach a point where accessibility isn't an afterthought or optional step—it's just the default.

We are transitioning from a desktop software provider into a deep-tech provider for PDF accessibility. We offer software modules that other vendors can integrate directly into their solutions and processing workflows, moving away from manual remediation and retrofitting.

Manual PDF remediation is often outsourced to regions with lower labor costs, like India, where people tag PDFs by hand. But that doesn't scale well and remains costly.

To make digital inclusion sustainable, the marginal cost and effort per document must be minimal, integrating seamlessly into existing document generation pipelines.

That's what axesFlip does. It operates on a template basis without requiring AI. This works reliably when processing structured, repetitive document types like invoices or account statements.

It handles multi-page documents and complex tables smoothly. Table accessibility is one of our key specialties.

However, if you're handed a mixed pile of completely arbitrary PDFs from different sources, a template-based system like axesFlip isn't the right fit on its own.

We are currently building solutions for that scenario. We have a prototype doing proof-of-concept testing using an AI node for initial baseline tagging, combined with our validation and remediation features from axesPDF.

AI will play a role for unstructured content—simple documents can be processed well, though complex documents still require human review and correction.

Will AI ever deliver 100% fully compliant documents autonomously? It's possible, though I remain cautious for now. That’s why we advocate hybrid systems and small, highly specialized AI models.

In PAC, for instance, we integrated a specialized local model. Rather than relying on a single monolithic model, high-quality results require specialized models focused on single tasks—such as one model dedicated solely to table grid detection, and another to assigning table headers (`TH`) versus data cells (`TD`).

Specialized models focused on dedicated features are key to achieving high reliability.

Artificial Intelligence in Accessible PDFs

Domingos: Speaking of AI, you integrated an AI-based checker into PAC in 2026 that runs entirely locally.

Markus: Yes, we are very proud of bringing that to life.

Domingos: What possibilities and limitations do you see with local models, and why is data privacy so critical here?

Markus: PAC has been around for 16 years as a free tool and is widely used across public sector organizations globally.

Because of where it's deployed, sending document data to external servers or telemetries was out of the question—that would immediately disqualify PAC from being used in sensitive government environments.

We strictly adhere to maximum data privacy: no internet connection required, operating 100% locally on the user's machine.

While collecting user document data could help us train models faster, keeping PAC fully local and privacy-respecting is a principle we remain committed to.

This constraint meant any AI features integrated into PAC had to run locally on the client machine.

We then evaluated where AI could provide the most practical value. Automated structural checks against PDF/UA and WCAG were already handled well by PAC's rule engine.

However, semantic appropriateness usually requires human judgment.

We noticed instances where documents passed automated rule checks with all "green lights," yet the semantic structure was completely missing or nonsense—for example, marking all visible content as background artifacts.

Everything is marked as an artifact." I don't want to reveal too much here to avoid giving people with criminal energy any ideas about how to fake PDFs. But these cases actually exist.

In those cases, all content is simply tagged as an artifact, making it an easy win for automated machine checks. However, the actual content is missing from the structure tree altogether. There are literally PDFs where people claim, "This is accessible now," even though they've marked every single piece of content as an artifact. The structure tree ends up empty, but the automated checks report: "Great job, green checkmark!"

So we thought: We need to do better here. We have to support people in spotting this.

Secondly, we know that many users don't even look at the screen reader preview. We always recommend: "At least check the screen reader preview—just a quick glance." You would immediately spot if everything was marked as an artifact and no content was rendered.

So I said: We need something that supports users with this. And that's how we arrived at this semantic check model.

It’s an AI model designed specifically to evaluate semantics. We trained it on our massive archive of fully accessible documents built over many years through our remediation service.

We used these PDFs to train the model. The model’s sole function is to estimate what kind of tag would make sense at a given position—for example, "Is this a heading?"

It then compares its prediction against the actual tag tree: Is the element it identifies as a heading actually tagged as a heading in the document structure?

The model runs this comparison. Naturally, that makes it much easier to spot those "black sheep" documents.

We always emphasize: It is meant to support humans, not replace them. A human must make the final call, because the AI model naturally won't catch everything either.

Still, it’s a tremendous help. It makes it much easier for non-experts to spot fraudulent or poorly remediation-tagged PDFs. That was one of its primary purposes.

Speaking of AI: Let's be honest, we won't get far without AI going forward. I think we both agree on that. You’ve already released several podcast episodes on AI yourself—including an exciting episode back in July. Because the relationship works both ways: AI doesn't just help accessibility; accessibility also heavily benefits AI. And that applies massively to PDFs.

We run our own small AI Lab where we experiment and conduct research. We've proven that while it might not show on a single simple PDF, querying an AI across a large archive of non-accessible PDFs often leads to incorrect answers.

If you query a large RAG (Retrieval-Augmented Generation) system or document archive containing inaccessible PDFs with a specific question, the error rate is very high.

Accuracy drops dramatically. On one hand, this is due to limited context windows; on the other, Large Language Models currently scan documents by flattening them into a single block of linear text.

Even if documents have tags, they often get scanned and linearized into a massive wall of text from which the model tries to extract answers.

When dealing with information inside tables, all contextual relationships get lost during linearization. The result becomes extremely inaccurate.

We presented this at axes4 Day. My colleagues Tamas and Thomas uploaded a video to YouTube walking through a specific test case involving limit values for ingredients in a skin cream—specifically, whether certain toxic substances exceeded allowed safety thresholds.

The result was striking: With the untagged PDF, the AI responded, "No, everything is fine, the limit is not exceeded." With the properly tagged PDF, however, the AI extracted the correct value—which was actually above the safe limit. I don't recall the exact substance—arsenic or another toxic element—but it genuinely exceeded legal limits. That makes a massive difference in real-world application. Accessible PDFs are proven to be ideal fuel for AI systems.

I recently attended the Digital Hessen conference, where a company demonstrated an AI assistant. The CEO mentioned: "In the future, our work will look completely different. We will mostly sit back, receive structured information delivered by AI, and focus on making decisions."

I responded: That sounds great, but if information comes from an AI, it must be completely reliable. Only then can we make sound decisions.

If you ask the AI, "What strategy should we pursue?" or "What were our exact sales numbers over the last few years?", the underlying data points must be 100% accurate.

That’s where accessibility delivers a huge benefit. I like to throw out the term "M&Ms" here—as you might recall from our joint event in Hannover. I use "M&Ms" to remind people of Mensch und Maschine (Human and Machine).

There needs to be a healthy balance. Machines shouldn't replace humans; instead, each should focus on what they do best. Software and AI are ideal assistants, but humans must stay at the wheel.

Both humans and machines love structured data. Accessibility and AI thrive on structured data—especially when it comes to PDFs.

If this realization spreads through the business world, we’ll see a massive "curb-cut effect" in digital accessibility that propels the entire field forward. We both know how often we have to repeat ourselves: "Accessibility is important, it's worth it, it's the right thing to do."

Connecting it to a clear business case—"AI loves accessibility because it provides structured data, making models more reliable and reducing hallucinations"—will render a huge service to the accessibility movement.

No AI Miracles for PDFs

Domingos: Thank you. Let's stay on the topic of AI and the promise of using AI to instantly generate accessible PDFs. Various vendors market tools where you upload a PDF, wait a few seconds for automated tagging, and download a file that claims to be "95% accessible"—or 90% from the more honest vendors.

Given your position in the industry, you'd know if these single-click solutions actually worked well.

Markus: Absolutely. One has to be extremely cautious with those marketing claims.

As I mentioned: To achieve widespread digital inclusion, we need to scale. Scaling requires automation and AI. But these will always be hybrid systems.

Quality is non-negotiable. Right now, it is simply impossible to produce a fully legally compliant, accessible PDF using AI alone.

People might argue, "Well, the technology will improve." That may be true to an extent, but human-in-the-loop hybrid systems will remain necessary.

We know many of the players building these solutions and maintain a clear overview of the market. Through my role leading the global working group for PDF accessibility techniques, we sit down and collaborate closely with our competitors.

It’s a fantastic experience because we define together how accessible PDFs should be built across tools and vendors.

We make great progress, even if debates get intense at times. But one thing is clear: There is no magic "one-click" bullet. The underlying automation heuristics will improve, but achieving truly reliable, accessible documents requires hybrid solutions.

These aren't pure AI solutions, either. Reputable vendors—ourselves included—combine AI with deterministic algorithms and heuristics. Heuristics are crucial because their output is predictable, whereas AI always carries a degree of uncertainty. AI serves well as a fallback—it can get you an 80% or 90% draft baseline faster than starting from scratch, but it cannot guarantee long-term compliance or reliability on its own.

There’s a second crucial aspect: Everyone has the right to access the original document. Imagine receiving an inaccessible invoice and running it through an AI tool. You get an extracted summary showing what to pay, the line items, and the deadline.

However, that information was mediated through an AI. How reliable is it? We know AI models make mistakes and hallucinate. For documents originating from automated workflows, generating an accessible original PDF directly from the source system should be standard. Users shouldn't have to rely on an AI's interpretation—they deserve direct access to an accessible original file.

Those are two key considerations. But I know you've tested these tools yourself, haven't you?

Domingos: Yes, absolutely. I regularly evaluate these solutions for my employer. There are minor improvements in certain areas—like generating alt text for basic images using strong Large Language Models.

Unfortunately, many tools implement cheap, low-cost AI models that output generic, unhelpful alt text. Without a human inspecting the output to verify its accuracy, errors pass right through.

I worry that many buyers of these "one-click" tools lack the capacity or willingness to double-check the results—otherwise, they’d adopt different workflows.

So I completely agree with you: Barring an unexpected technological revolution, fully automated pure-AI PDF remediation won't deliver reliable results anytime soon.

Markus: Exactly. Having been in the digital accessibility ecosystem for a long time, both of us welcome new providers entering the market. Naturally, though, some market entrants make promises they can't keep, leaving end users with disabilities with sub-par experiences.

When demand grows, legislation tightens, and a market matures, an influx of new tools is a natural phase. That’s where the industry sits right now.

Accessibility is meant to be seamless and invisible, which can make quality hard for non-experts to evaluate initially.

That’s why we built the AI check into PAC: to empower non-experts to evaluate files independently. If a vendor promises a "100% accessible PDF via AI in seconds," you can run the output through PAC, inspect the screen reader preview, and check if the content actually makes sense.

Accessibility is about Equal Access—providing an equivalent, reliable, and prompt experience.

We need to continue empowering non-experts so they develop the critical judgment required to distinguish genuine accessibility from superficial compliance claims.

How to Follow axes4

Domingos: I couldn't agree more. That’s a great closing thought. Final question: Where can listeners follow your work?

Markus: LinkedIn is always the best place—both the official axes4 company page and my personal profile (Markus Erle).

We also publish a monthly newsletter covering product updates and upcoming events. We host frequent free webinars and events. I encourage everyone to visit our website and subscribe to stay informed.

We host monthly free events, our annual axes4 Day every March or April, and the axes4 PDF Accessibility Summit in November—a two-half-day online event conducted in English for our international audience.

Following our LinkedIn pages or subscribing to the newsletter will keep you completely up to date.

Domingos: Thank you so much for these insights, Markus. I'm sure our listeners learned a lot about accessible PDFs and are excited to dive deeper into this topic.

I wish you and the axes4 team continued success. Given the pace at which you’re releasing new features, we’ll definitely need to catch up again in a year!

Markus: I’d love that, Domingos. It’s always a pleasure exchanging ideas with you. Thank you for having me, and I look forward to our next chat.

Domingos: Likewise. Thank you!

Markus: Thanks, Domingos!