Leveraging AI Accessibility Workflows

Please be advised, you must Allow All Cookies to view this video. If you are experiencing difficulties, you can also view it here.

View the Video

Read the Transcript

Pete Bruhn [00:00:06]: Alright, welcome, everybody!

Sorry we are a couple minutes late here, just wrapping up some setup stuff to make sure this goes off without a hitch.

And while we’re gonna give another minute or so for a couple more folks to show up, we’re gonna launch a poll about your current usage of AI. So, when that comes up, feel free to answer the question, and we’ll get this kicked off very shortly.

Pete Bruhn [00:01:03]: Alright, let’s kick this off. Welcome, everybody, to the Onward Accessibility Pre-GAD Week webinar titled “Leveraging AI and Accessibility Workflows.”

We’re really excited to be here and have this presentation with you all. We’ve got some really great panelists who will be giving short 10-minute mini presentations on various workflows that AI can be leveraged within.

With that, I’ll do a quick intro for myself. My name is Pete Bruhn. I am the Director of Digital Accessibility Solutions here at Onward Accessibility.

I’ve been in the digital accessibility industry for about a decade now and really love this work. I’m really excited about the future and what’s going to come with various tools and technologies that we can use to help make this process a little more efficient.

So, with that, our agenda for today: like I said, we have three mini presentations, and then we’ll have some time for questions and answers at the end.

Our first presentation will be presented by Doug Abrams and is titled “AI in Your Audit Cycle.” The second presentation will be presented by Dylan Isaac, and its title is “Context Engineering for Web Accessibility Workflows.” The final presentation will be presented by Babi Das and is titled “Where AI Delivers PDF Accessibility at Scale.”

So, to start things off, we have Doug Abrams. Doug is our Technical Accessibility Lead here at Onward Accessibility. He previously served as a Principal Accessibility Engineer at TPGI.

He has over 10 years of experience and a background spanning accessibility engineering, web development, and software development at organizations like UPS and General Motors.

He brings deep expertise to digital accessibility. He holds a DHS Trusted Tester Certification.

Today, Doug will be speaking about AI in your audit cycle, including where AI can accelerate accessibility workflows, where human expertise remains critical, and how teams can improve efficiency without sacrificing quality.

With that, Doug, I’ll pass it over to you.

Doug Abrams [00:03:19]: Awesome. Thanks, Pete, for the introduction. Hello, everyone. Happy to be here today to talk a little about accessibility workflows.

In the decade-ish that I’ve been part of the digital accessibility community, a large portion of that time has been spent testing web pages and applications and providing remediation advice to site authors and developers.

In other words, I’ve done a fair share of WCAG audits.

That audit process can be repetitive and time-consuming. Today, I’d like to talk a little about how AI can be incorporated into your audit workflow.

A few weeks ago, Gina Clark wrote a really insightful article about how AI initiatives need to be optimized differently for each part of the development lifecycle.

The article was titled “Design and Engineering Solve Different Problems. AI Initiatives Are Forgetting That.”

One line in particular from the article really stood out to me. It said, “The more important question for any AI initiative isn’t just how do we go faster? It’s which part of the work improved with AI, and which parts need to remain slow.”

This idea applies really well to the audit process.

If you’re not thoughtful about where you use AI, it’s easy to introduce risk or lower the quality of your work. So instead of trying to speed up everything, it helps to break down the audit process and look at where AI actually adds value.

Now, most accessibility audits follow a pretty consistent pattern with these three stages.

First, you run automated scans, whether that’s using site monitoring tools or on-demand scans with something like the Axe DevTools plugin.

Then you follow up with manual testing. This is where you’ll use screen readers to read through a webpage or navigate through interactive elements with a keyboard.

And finally, you’ll document any issues that you find.

These three stages aren’t always linear. They can overlap with each other, or you can cycle through them multiple times during an audit, depending on your individual methodology.

The first stage, automation, tends to take roughly the same amount of time whether AI is involved or not.

Manual testing is the part that really needs to stay slow. That’s where you’re trying to experience the product the same way someone with a disability would.

It requires judgment, context, interaction, and nuance. And that’s not something you want to rush or take away the human touch from.

When it comes to manual testing, AI can be another tool in your toolbox, just like browser plugins, bookmarklets, and other common tools. But it shouldn’t replace the knowledge or expertise that a human can provide.

AI becomes part of your process, but not the process itself.

Now, that leaves documentation. For most teams, that’s the biggest time sink.

You’ve already done the hard work of identifying issues, but now you have to turn that into reports, tickets, actionable advice, and remediation guidance.

And unlike other steps, documentation time is the only part that really scales with how many issues you find.

This is where we’ve seen the most success using AI.

One approach that’s worked well for us is leveraging AI to generate templates for common accessibility issues.

Instead of writing every issue from scratch, we built a reusable library of issue templates that we can pull from during audits. And here’s how we approached it.

First, we defined a clear outline for what each issue should include. It needed to include things like a plain-language overview of the issue and why it matters, a list of impacted disability categories, the relevant WCAG success criteria, and, of course, detailed remediation guidance, including code examples.

Then we manually created one or two high-quality examples that followed that structure.

We used Markdown as the format since it’s easy for AI to understand and reproduce.

We also provided things that the AI struggled with, like severity ratings and impacted users, so that it didn’t have to guess.

And we asked for multiple code examples in the recommendations. For example, using both native HTML and ARIA solutions so that developers have options depending on their tech stack and code constraints.

Once we had this in place, we used AI to generate a broad set of templates based on common issues.

This may be a little difficult to see on the slide, but I wanted to give a screenshot of what this looked like in practice. Here’s the Markdown outline and an example of a template it produced for functional images that are missing alt text.

The result of this process is that during an audit, we’re no longer starting from scratch. Instead, we’re selecting the appropriate template and adding specifics, like where the issue occurs.

It turns documentation into more of a tagging and customization exercise rather than a writing exercise.

And there are also long-term benefits. These templates become reusable assets. You can carry them forward into future audits, refine them over time, and keep improving consistency across your reporting.

Doug Abrams [00:09:53]: Now, if you zoom out a bit, documentation doesn’t stop at individual issues.

There’s a lot of other outputs that come at the end of an audit, and these are all areas where there’s potential for AI to help.

You can use your audit results to generate high-level summaries of findings, quickly create executive reports with metrics like how many violations there were, what the WCAG levels of those violations were, etc.

Don’t let audits be a one-time project.

Use them for internal knowledge sharing, like turning the results into a knowledge base of lessons learned and best practices for development teams to follow in the future so they’re not repeating those same issues over and over.

And you could even try using it to generate a first draft of an Accessibility Conformance Report.

Now, that last item is one that’s still evolving, and I want to emphasize caution when trying it. We haven’t seen perfect results yet, but creating conformance reports is something that we and other organizations are experimenting with.

The key there is treating AI as a starting point, not the final product.

ACRs are high-stakes, public-facing artifacts, so they always need careful human review.

If there’s one takeaway I’d like you to remember, it’s this: don’t try to speed up everything.

AI is one tool, not your only tool. Use it where it makes sense, and accept that some parts of the process are intentionally slow.

Don’t force the square block into the round hole.

Accessibility is all about people. And if you make the process all about speed and tools, then you leave out people.

Keep manual testing slow and intentional. That’s where quality comes from.

But look at opportunities in the parts of the process that are repetitive and time-consuming, especially documentation. That’s where AI can give you meaningful efficiency gains without compromising the outcome.

Thank you. And back to you, Pete.

Pete Bruhn [00:12:19]: Amazing. Thank you, Doug. Really appreciate that presentation.

Got a lot of thoughts there, and I think we’ll have some questions for you at the end, but in the interest of time, let’s keep moving forward.

Next up, we have Dylan Isaac. Dylan is the founder of Enablement Engineering, where he builds AI systems designed to extend human capability rather than replace it.

He’s also a member of our expansive talent network and was previously a Lead AI Engineer at Deque, where Dylan pioneered AI-driven accessibility systems, including multi-agent workflows and contextual remediation tools that dramatically improve testing accuracy.

His work today continues to focus on the intersection of AI and accessibility, as Dylan helps organizations transform inaccessible content into semantic, usable experiences at scale.

Now, Dylan will be sharing his insights into AI-powered accessibility engineering, multi-agent systems, and the future of accessible content workflows.

With that, Dylan, over to you.

Dylan Isaac [00:13:25]: Awesome. Thanks, Pete.

Hi, everyone. My name’s Dylan Isaac. I’m the founder of Enablement Engineering, and this talk is called “POUR for Agents: Context Engineering for Web Accessibility Workflows.”

AI is participating in our accessibility work whether we plan for it or not, and the question is whether we’ve designed our working environment so that agents can participate responsibly.

From my experience working with language models, I’ve found that our expertise has to move from tacit judgment into workflow infrastructure — something that’s durable, inspectable, and executable.

Some quick grounding on what an agent is before we continue: a language model can be wired up to tools, and then it runs in a loop, and then people call it agents.

This creates real strengths because agents are super fast, they’re text-native, and they can synthesize across long inputs at superhuman speeds.

But the weaknesses matter just as much. They’re forgetful, they have no durable memory outside of the environment, they’re very pattern-hungry, and they overfit to whatever patterns are nearest to them.

I think this fast synthesis plus this missing memory is why AI-generated accessibility work can feel so strange.

What I’ve noticed is that the output looks finished from AI accessibility workflows. The layout works, the modal looks like a modal, the button looks like a button.

Visually, the interface has the shape of completion, but underneath, the semantics are still quite thin.

There’s no focus, names are wrong or incomplete, state is communicated outside of assistive technology, and keyboard access gets treated as an implementation detail instead of part of the interface.

The model learns how to make an interface look done before it reliably learns how to make it truly work.

It can be really good at React but still ignore things like name, role, value, and screen reader behavior.

In other words, the capabilities of the model are jagged — superhuman in some things, but incomplete in others.

A big reason for these outputs is memory mismatch.

Your team gets to accumulate context. You remember past bugs, deprecated components, or the time an automated Axe scan passed but the screen reader experience was still broken. That’s what true lived experience is.

But an agent doesn’t inherit any of that. Every single session is day one.

Your team members will stop suggesting patterns your team deprecated, but agents won’t unless you build it into the environment itself.

So here’s the reframe.

We already use POUR — perceivable, operable, understandable, and robust — from WCAG to understand how the web works for our users. And I want to use that same framework to ask whether our workflows work for our agents.

The decades of work shifting left and building accessibility workflows — none of that changes. What changes, however, is the audience.

So the same four questions just turn around.

The agents need to have readable expertise and context. They need to have safe handles to do work, visible reasoning to understand ambiguity, and review loops to inspect the work that is done.

So step one: we have to inventory what the agent can read.

Agents are text-native and can learn from their environments. That means they can learn from code, docs, tests, file names, APIs, etc. Anything that is a readable surface teaches the AI something.

For instance, if you have a component named dialog.tsx, that teaches more effectively than popper.tsx because the model has all these patterns built into its weights that make it familiar with “dialog,” but it doesn’t know what your internal name for something is.

A test named “Return Focus to Trigger after Close” does double duty. That test validates the behavior, but the name of that test teaches what correct behavior looks like.

The codebase is part of your prompts now, and every readable surface is either an affordance for your agent to use or, if you ignore it, a potential obstacle that can confuse your agent and lead it down suboptimal paths.

So now we can turn this all around.

Perceivable: can the agent access the right signals for accessibility decisions? Things like your code, your DOM, the accessibility tree, or the visual presentation of the page?

Operable: does it have safe handles to perform actions without mistakes or assumptions? Things like agent skills, components, APIs, or simply knowing where to find a workflow?

Understandable: can it follow our reasoning, not just copy our output? Does it have pattern documentation, decision trees, or design rationale?

And robust: does the workflow give the agent a way to check, correct, and escalate when work is happening outside of its purview?

Four lenses for one question: have we designed our environment so that accessibility expertise is available in a form that agents can actually use?

So let’s make this concrete with the alt text decision tree from the W3C.

The naive workflow is that you hand the model an image and ask for a description, but that’s not exactly how accessibility experts work.

Alt text isn’t just a caption. Alt text is a decision about what role an image is playing in a specific context.

So instead of asking, “What is in this image?” we’re asking, “What role is this image playing here?”

We can provide the image, its context, and a decision tree on how to come to this decision. Then the agent gets to participate in the process instead of bringing its own incorrect assumptions into the mix.

Dylan Isaac [00:19:31]: So, perceivable.

Perceivable for alt text isn’t just computer vision — it’s about context.

The same image needs different alt behavior in different places. For instance, a product photo is informative on a product detail page and decorative inside of a repeated card.

Pixels alone will get you a caption. Pixels plus surrounding DOM, nearby text, page purpose, and image role get you closer to an accessibility professional’s decision.

Operable for alt text means that you give your agents a handle around your data — a resource like a prompt that it can quickly point to when it’s doing work.

For instance, a weak prompt would be, “Write alt text for an image.”

A stronger one says, “Classify this image using our alt text decision tree, recommend the correct alt behavior, explain the decision path, and flag anything that needs human review.”

The point isn’t that models magically become accessibility experts overnight. The point is that the agent is acting through structures that encode our practice, and then that practice can now live in reusable text that can be referenced by the agent.

Understandable means the decision tree has to be available to the agent as context.

Specialists internalize things like this decision tree through years of practice. They don’t have to consciously walk through each branch of what makes good alt text and what doesn’t.

That agent, however, doesn’t have years of deliberate practice.

The decision tree needs to live somewhere readable for the agent. It needs to be a pattern doc, a tool instruction, a system prompt, or maybe even designer reasoning docs from a designer handoff.

Judgment just needs to land somewhere the agents can actually read.

And then finally, robust.

The answer itself has to be reviewable. I don’t want just the output string. I want the decision path that produced it.

Did the agent classify the image as decorative, functional, informative, or complex, and why?

That allows us to give automated tests something to test.

You can run code to test if alt text is present or if an accessible control has keyboard controls, for instance.

We can also do things like “LLM as a judge,” where a second model whose job is to review the first model’s reasoning can catch contradictions, like, “You classified this as decorative, but your rationale says that it contributes meaning.”

A final part of the robust loop is that you can escalate to a human when ambiguity still remains.

So the robust loop is: validate what you can, escalate where it can’t, and leave the decision path in a way that can be inspected later.

Dylan Isaac [00:22:20]: The final thing that I want you all to take away from this is that your expertise is truly the asset.

We don’t get to control what the model learns, but we do get to control the environment in which our model works.

What we can control is what our agent can read through, act through, reason from, and check against.

Alt text is just one example, but it can be applied to your entire accessibility practice.

The key is to inventory your expertise, encode it, and surface it where your work happens, and finally verify that it stays true.

The shift is from accessibility expertise as consultation into accessibility expertise as an asset that is durable, inspectable, executable, and workflow-native.

That’s how you magnify expertise instead of generating more slop. Thank you.

Pete Bruhn [00:23:12]: Right. Thank you, Dylan. That was very, very informative. Looking forward to getting into the questions on your presentation afterwards.

Dylan Isaac [00:23:22]: Yeah, looking forward to it.

Pete Bruhn [00:23:23]: That’s right.

Okay, so next up, we have Babi Das.

Babi is the CEO and Chief Architect of Accessibility On Demand, or AOD, which is an AI-powered platform built to automate PDF accessibility remediation and compliance at enterprise scale.

He has decades of experience leading technology and automation initiatives. He has focused his recent work on helping organizations dramatically reduce the time and manual effort required to meet WCAG, ADA, and Section 508 accessibility standards.

Today, he’ll share insights into AI-powered accessibility automation, compliance workflows, and what scalable document remediation can look like in practice.

Alright, Babi, over to you.

Pete Bruhn [00:24:13]: Unmute.

Babi Das [00:24:17]: I knew I’d forget to do that. Thanks, Pete. Happy to be here.

Hello, everyone. My name is Babi Das, and I’ve spent the better part of my career solving complex automation problems. Improving both speed and accuracy is usually at the core.

And making PDFs accessible at scale was definitely one of those incredible challenges.

We all know the PDF accessibility problem, and today I’ll speak about where AI finally makes it solvable at scale.

We’ll discuss the five areas where AI contributes to production-ready outcomes right now and how they have fundamentally changed the operating model.

Babi Das [00:24:58]: For those remediating PDFs, you all live with the same manual remediation math.

Painfully expensive — $8 to $50 per page when outsourced, 15 to 30 minutes per page in effort, and around 30% error rates on the first pass.

And even more troubling, a backlog that grows faster than you or your team can clear it.

See, that’s the problem. Here’s the strategy that solves it: an automation-first approach.

Automation, properly coupled with AI, can remediate the bulk.

Humans can validate the exceptions, with automation and AI assisting them in the effort to streamline and enable these nonprofessional remediators to increase their productivity, even at the source, effectively decentralizing remediation efforts and supporting scale.

It comes down to three principles:

Train at the source to reduce day-forward volumes.

Automate the bulk and the backlogs.

And then reserve professional expertise for the documents where their judgment matters the most, like very high-complexity documents and policy-driven documents such as court filings, regulatory submissions, audit reports, etc.

Typically, examples are contrast ratio validations and issues, and highly subjective reading orders.

The point I want to make here is AI doesn’t replace accessibility expertise — it scales it.

What makes this strategy operationally viable is what AI can actually do today.

There are five proven capabilities that have crossed the threshold from experimental to production-ready, and they are the focus of the rest of the presentation.

So here are the five areas that make a difference.

Reading order matters. They’re sequential.

You start with OCR — it’s the foundation.

Tagging gives the document structure.

Contextual alt text makes images meaningful.

Tables and forms handle the hardest cases.

And finally, validation closes the loop with audit-ready compliance defense.

Together, they cover the full PDF accessibility stack, from raw scans to audit-ready compliance certification.

So let’s take them one at a time.

Capability one: OCR.

This is the foundation.

OCR has been around for decades. What changes now is reliability across the increasingly messy world. It could be ugly scans pulled from old fax machines, multi-column legal documents, mixed-language reports, even embedded handwriting.

When done right, AI-optimized OCR can now handle all of these at accuracy rates approaching native digitally born text.

It preserves document structure, including column boundaries and reading-order cues, so everything downstream can now be successfully built on it.

Here’s why this matters: if you can’t get text out of a document reliably, nothing downstream works.

Tagging needs words to tag.

Alt text needs context.

Validation needs structure.

OCR is the foundation, and it’s now solved well enough that we don’t have to talk about it as a separate problem anymore.

Capability number two: structural tagging and reading order.

I call this the skeleton — the parts screen readers actually navigate and, more importantly, what define true accessibility.

It used to be that a human would read every page. They marked up headings, identified lists, and set reading order.

On a 200-page document, that’s hours and hours of focused work and must be done consistently, or the screen reader experience quickly breaks down.

AI can now infer structure from visual cues — font sizes, indentations, spacing patterns, whitespace — all if trained properly.

It identifies headings, lists, footnotes, columns, and sidebars.

And critically, it does this consistently across an entire backlog.

Document number 50,000 gets the same quality treatment as document number one.

That’s where most of the savings comes from.

Tagging at scale is what was structurally impossible manually.

Babi Das [00:29:08]: Number three: contextual alt text.

This is the real breakthrough, and I think some of the other presentations talked about this.

Old image recognition methods could tell you, quote, “This is a bar chart,” end quote.

Useful technically, but a screen reader user already knows it’s a bar chart from context. They really want to know what the chart actually says.

Now AI has the ability to tell you descriptions like this:

Quote, “This bar chart shows Q4 revenue by region. The relevant point is that the Northeast led at $4.2 million, ahead of the Southwest at $3.1 million,” end quote.

See, that’s contextual, not categorical. That’s actually serving the reader.

Alt text was historically the most subjective part of remediation. Two human remediators would write fundamentally different alt text for the same image.

AI can now do this at scale with consistent quality while calibrating to the document type.

For example, a formal document like a financial report versus a conversational document like a marketing piece.

So if you tested alt text with AI two years ago and weren’t impressed, I urge you: you should test it again.

Number four: tables and forms.

Historically, the hardest case for both professional remediators and machines.

A simple table is straightforward, but a financial statement with merged cells, nested headers, and footnotes referencing specific cells — that’s not a simple table.

I would argue it’s a small relational database.

Screen readers need to understand the relationship between cells, not just values.

Forms are the same problem.

A field that only appears if you check a box, a calculation that depends on three other fields, tab order that needs to follow business logic, not just visual placement.

AI with a proper baseline and focused training can now understand these structures.

It identifies merged-cell relationships, infers header scope, builds proper tab order, and effectively tags conditional logic.

The cases that used to break automated workflows and force everything into manual review now stay in automated workflows, with human validation reserved for truly unusual, complex, or policy-required reviews.

This is what closes the gap between partially automated and fully automated.

And finally, capability five: compliance validation.

This is what closes the loop.

Manual remediation produces quality variance. No way around this.

Two skilled remediators looking at the same document could — and often do — produce different outputs.

The same person on a Tuesday versus a Friday may also produce different output.

There was no reliable way to give a board, an auditor, or a regulator a defensible compliance number.

Now every output gets validated against the same automated standard.

Third-party PAC checker compliance with WCAG and PDF/UA can now be applied consistently — every document, every single time.

Documents that fall below a policy-defined threshold get routed to human review automatically.

Documents that pass come with an audit-ready certificate, version history, and timestamp.

Now, here’s why this matters.

When your CIO asks, “How do we know our documents are compliant?” the answer is no longer, “Well, we trust our remediation team.”

The answer is, “We have a validated compliance method and reconciliation certificate for every single document with a full documentation trail.”

That’s what auditors really want to see.

Babi Das [00:32:37]: So that’s the five capabilities where AI can be applied to achieve PDF accessibility.

So what does this really translate to in operating terms?

Up to 95% cost reduction per page versus manual remediation.

Processing in minutes, not weeks or months.

95% or more validated compliance scores against industry standards like WCAG and PDF/UA — again, every document, every single time.

And finally, number four: any volume.

Now you can address backlogs or high-volume projects that were considered impossible because what used to be a quarterly, weekly, or daily task is now possible.

So here’s the math reframed.

The $100,000 backlog we talked about earlier — manually, at current remediation rates, that’s a million dollars and years’ worth of work.

Automation drives it down to as low as $30,000 and days instead of years.

So it’s a complete divergence in what’s possible.

This is the part that changes the conversation with your CFO.

Compliance stops being an emergency budget item — the thing we all scramble to fund when a regulator comes knocking.

Instead, it becomes an economical steady-state operating cost.

It’s predictable, plannable, and defensible.

And one honest note here: 95% compliance scores are not 100%.

The remaining percent is exactly where human review still adds a ton of value.

That’s a feature, not a bug.

It’s exactly the work we as humans should be doing.

Babi Das [00:34:13]: So, in closing — and I said this before — AI doesn’t replace accessibility expertise, it scales it.

Five production-ready capabilities are now in play: OCR, tagging and reading order, contextual alt text, tables and forms, all wrapped up in final validation.

Together, they turn automation-first from an ambition into a steady-state operating model.

Thank you.

Pete Bruhn [00:34:41]: Awesome. Thank you, Babi. Really appreciate that. That was a really awesome presentation.

Again, looking forward to the questions at the end here.

So just before we shift to questions, I’m gonna do a quick little bit about Onward Accessibility for those of you who don’t know us.

We are the only digital accessibility partner that can provide our customers with both service solutions as well as talent.

We help companies build teams while also filling gaps and helping do actual digital accessibility work on our customers’ behalf.

Alright, how do we do that?

We offer fully managed support for projects on a subscription basis.

We offer different services, things that fall into strategy and implementation, auditing, research, testing, remediation, and engineering.

Really, whatever you need when it comes to digital accessibility services, we have the folks here ready to go to work on your behalf.

And finally, on the talent side of things, if you’re looking to build teams or you need to replace somebody who just left, we have some of the best talent ready to go and looking for work right now.

Whether you’re looking for contractors, consultants, direct hires, or fractional executives, we have these folks ready to go, and we’d love to talk to you about how we can support you and your business.

With that, we are going to shift over to our Q&A session.

I will actually stop sharing my screen so I can kind of see everybody as well, and let’s get into questions.

Pete Bruhn [00:36:23]: Alright, so it looks like we’ve had a good healthy amount of questions going on in the chat, and that’s really awesome to see.

Let’s see. I’m just trying to find one that has not been answered yet.

I guess if I just throw one out there for the group — whoever wants to answer this first, feel free — but how can an organization get started with integrating AI into accessibility flows?

If they’ve never done this work before and they’re just getting going, what tools should they look at? What are the best steps to kind of get this process moving?

Dylan Isaac [00:37:04]: I’ll go ahead and take it.

I think the starting point for this process is to sit down and, instead of doing the work like you normally do, take the time to write it down.

Write exactly what decisions you make and how you go about that thought process.

Because, like I was saying in the presentation, now you can encode it in text, and the agents can follow your lead and think through the same chains of thought that you would normally have to take manually.

That way, it can highlight things that you may not have considered, but it also might be able to speed up some of those monotonous decisions that you have to make over and over again in accessibility work.

Doug Abrams [00:37:46]: I think one thing that I’ll tack onto that, Dylan, is don’t just sit down and type in the first prompt that you think of and expect to get a useful answer.

Invest the time up front into preparing context for the agent so that it can give you the most valuable answer — an answer that’s in context with your process, your systems, and your decision-making that’s repeatable again in the future rather than random with each prompt.

Pete Bruhn [00:38:21]: Okay, great.

Again, I know there’s been some back and forth with the questions in the webinar chat, but I’m gonna pull out a couple that may have already been talked through so you can kind of talk through those outside of the chat as well.

One I want to bring up is from Narmada, and the question is: where do you draw the line between AI automation and human accessibility expertise, especially in audits and remediation?

Doug Abrams [00:38:50]: Yeah, I can take that one.

I think at the end of the day, you need to consider that AI is really just one aspect of testing.

If it’s all you’re doing — and this applies to any automation, whether it’s AI-based or traditional automation — if you’re only doing that and removing the human aspect completely, then you’re already behind.

You’re not really meeting the expectations of the end user.

For example, if I’m planning to audit a website or web application and I fail to read through each page with a screen reader at least once, then I’m already falling behind that mark, and I’m relying too much on automated capabilities.

But it’s the areas where automation can really help speed through checks that would normally take a long time to do manually.

Things that are code-level detectable are really easy to flag quickly and in bulk.

And then outside of the actual testing process itself, think about how you can speed up other parts of that audit workflow, not just the testing portion.

Babi Das [00:40:15]: I can probably piggyback because I think I take more of the back-end view, since our focus is on automation and production-ready remediation.

I totally agree with what Doug said.

There really needs to be a balance between what we as humans ultimately have expertise in — and I don’t want to say subjective, but it’s our real expertise and experience that can validate that you’ve done the right thing.

Where automation needs to be is where you’re thinking about scale, cost, and areas where the quality of output during that AI implementation can drive down cost and improve performance and speed in areas we could call commoditized.

Then really use human expertise to tune the final output.

We were talking about this the other day in a meeting about how we use AI in the production of our automated PDF system. We call it “the polish.”

It polishes what is ultimately done by expertise.

So when you think about this, always think about where you, as the polisher, need that expertise to do it just right.

Those parts should never be forgotten.

Think about the workflow where that expertise adds the most value.

Automation should happen to get rid of the bulk, but then make sure it gets over the hump with human expertise.

Doug Abrams [00:41:52]: Yeah, one really specific example, Babi, I can add onto that, talking about how it can help with scaling.

Pete and I were actually looking at something earlier today around scoping an audit.

There’s this idea in audits of choosing a representative sample of a product.

For example, if you have a website that is 200 pages, but under the hood that’s really a dozen or so templates, we’re experimenting with tools that can look through a large portion of those pages, identify common patterns within the UI, and help you pull out that representative sample.

That really helps both with the scoping side of things and on the testing side because then you’re gaining more confidence that you’re hitting a true sample of a product and not just manually picking and choosing pages.

Pete Bruhn [00:42:57]: And I’m super excited about that tool.

Doug Abrams [00:43:00]: Yeah, it’s pretty cool.

Pete Bruhn [00:43:02]: It’s really awesome.

Alright, again, I know this one was answered in the chat, but Dylan, do you build custom agents for your accessibility workflows or use third-party ones? What platforms or models do you use, and why?

Dylan Isaac [00:43:15]: Yeah, I do build custom AI harnesses.

I don’t build custom models. What I describe it as is building the mechanisms through which you nudge the model toward correct decisions.

I’ve found that I’ve had the best luck building APIs using a framework called PydanticAI.

It gives you type safety, and you can understand what decisions are being made and how. You can know the whole lifecycle of the different responses.

But my new obsession recently is building custom harnesses with this new framework called Pi.

It lets you build Claude Code-like experiences, but you get to control every single aspect of your interface.

So you can have custom nudges. If it’s reading a particular file, you can say, “Now apply these accessibility workflows because you’re reading a component and these rules apply to these types of components.”

Or you can have it go through a workflow where it first looks at a component from the perspective of a designer, which brings out user-facing questions.

Then you have another agent that’s looking at the problem from a developer perspective, which pulls in code-quality questions.

Then you can hand it off to a testing agent, which figures out all the different aspects that need to be tested in order for this decision to be trustworthy.

So it’s all of these little pieces that you can build into your tooling now.

That’s why I’m so adamant about getting this knowledge out of our heads and onto paper so we can allow our agents to take the same journeys we would take when applying information to our processes.

Doug Abrams [00:45:24]: Dylan, I have a question that I thought of during your presentation, and this seems like a good transition point.

When you think about exposing your agents to code and context, something that came to mind is code commenting.

I know that’s not a new concept. We’ve been relying on it for human context, passing code from developer to developer for a long time.

But is that something agents can take advantage of? Is that something that can be exposed to them to help build out that context pool?

Dylan Isaac [00:45:42]: Most definitely.

I like using comments specifically to link to different parts of the documentation that are relevant to a given function.

Like, if we have a core function that’s part of a testing loop, I’ll add a comment that says, “Please review architecture.md to understand that you’re part of this particular loop inside of this larger system.”

That way, when the agent is debugging this particular part of your system, it looks at that comment and goes, “Oh, I should look at architecture.md, and then I’ll get the entire picture of how the application behaves,” instead of shining a spotlight on one individual function that might be taken out of context from the entire system.

Pete Bruhn [00:46:32]: Fascinating.

Alright, we’ve got another one that’s kind of pointed at you, but anybody can feel free to answer.

Have you seen AI-generated accessibility fixes pass compliance checks but still fail real user experience expectations?

Dylan Isaac [00:46:48]: Yeah, I have.

It’s part of this robust feedback loop that I was harping on.

In your testing for your AI loops, you start to see all the different types of outputs that can happen.

It can do all the code checks. It can run Axe Core, it can look at the accessibility tree, but as accessibility practitioners, we all know that what’s present on the accessibility tree isn’t always what gets read out by screen readers because of compatibility issues or bugs.

Those are the failure cases where I see AI hit the wall — when the code hits the metal.

How do you overcome that?

What I did was figure out how to surface what the screen reader is physically saying to the computer.

Then you can use things like Guidepup, which can actually run the screen reader, capture the output, and then your AI agent can read the transcript of what the screen reader was saying.

That can be built back into your robust loop.

So it’s about detecting where those edge cases exist, figuring out how you can connect the computer to that context, and then giving it proper instructions on how to interpret that signal.

Pete Bruhn [00:48:20]: Interesting. Okay.

Thank you for that.

Alright, so we have maybe time for four or so more questions that are in the chat, so let’s keep moving along here.

Sam asks: can you provide an example of a specific case study or project in which AI was applied for an audit or remediation project? What challenges came up, and what were the results?

Pete Bruhn [00:48:49]: Anyone want to take it?

Babi Das [00:48:52]: I could pipe in because we’re a little different since we’re providing a tool for this.

There’s been an evolution even with our technology and our tool — from doing a good job, to a great job, to now an excellent job. It’s just evolved.

I think this also relates to another question I saw about AI for document remediation and what exactly AI’s biggest limitations are.

They sort of go hand in hand.

Ultimately, you could have a document or PDF pass a compliance checker like PAC Checker with 100%, but the document still isn’t actually accessible.

Because we have reading order, appropriate tags, and contextual alt text that needs to say something meaningful.

Those are all real challenges.

The evolution of this has been that where the challenges initially existed was around the subjective side of things.

Proper tags, alternative text, and reading order can be different for different audiences.

I hate to use a map as an example, but maps have very different audiences.

Somebody may be using it to look up cities, while somebody else is using it to travel from one place to another.

Those are two separate use cases for the same content.

So the challenge is where remediation becomes subjective.

Though you can come up with an objective methodology for a subjective activity, there are still layers of subjectivity.

That’s where we see feedback on outcomes. Usually somebody says, “I would’ve done it differently,” not necessarily that the output was wrong.

So it’s a little different from our lens in developing our product.

Doug Abrams [00:51:13]: I can speak a little bit to some challenges on the web side of things.

One thing that we see a lot is around remediation advice.

Dylan, I think this leans into the question you were answering too, but from a different user’s perspective.

You talked about the end user being the person absorbing the content, but there’s another user to consider, which is the people who own that content.

Are we following good practices and scalable practices that can be maintained over time?

One challenge we see a lot with AI remediation is that it often breaks the first rule of ARIA.

For context, the first rule of ARIA is that if there’s a native HTML equivalent in a web context, prefer the native solution over an ARIA solution.

What we’ve seen is that because a lot of the training content these models are based on doesn’t necessarily follow that principle, we end up seeing an overabundance of ARIA in recommendations where it’s not needed.

That gets into the context you’re building these agents on — telling them to prioritize native HTML solutions, give multiple solutions, use native first, then ARIA alternatives.

Those are all different contexts to be aware of right now in the way AI prefers responding to things.

And you learn to account for that as you iterate through what you’re asking it to do.

Pete Bruhn [00:53:06]: Okay, great.

So we’ve maybe got time for two more questions.

The first comes from Tate, and she asks: how do you believe AI-powered technologies will evolve over the next 12 months?

Do you expect what you’re seeing today to change? And if so, how can organizations prepare for that change?

I think it’s a really great question because it feels like every week we’re seeing significant changes and advancements with AI tooling and technology.

So I’m curious what the panel’s thoughts are. What does a 12-month outlook look like for AI changes?

Dylan Isaac [00:53:45]: My personal opinion is that it’s really hard to predict, but if I had to guess, I would say that the AI labs are still woefully under-testing accessibility and building it into their default model behavior.

So it’s up to us as accessibility experts to build those workflows ourselves.

I think the biggest shift that’s going to happen over the next 12 months is that the interfaces around these systems are going to become dramatically more customizable.

You’re already seeing this with things like Claude Code and the different agent frameworks where you can build workflows around the model.

The model itself is becoming less important than the surrounding infrastructure.

What matters is how you provide context, how you review outputs, and how you build loops around the system.

So I think organizations should focus less on trying to pick “the winning model” and more on documenting their expertise, building repeatable workflows, and figuring out how they validate quality.

Because those things will transfer no matter which model ends up being dominant.

Doug Abrams [00:54:52]: I think one thing organizations can really do to prepare is start experimenting now in low-risk areas.

Don’t wait until everything feels perfect because it probably never will.

Find workflows that are repetitive, time-consuming, and relatively low risk, and start understanding how these systems behave.

That could be documentation, internal knowledge management, summarization, template generation — things where humans are still reviewing the outputs.

Because part of preparing for the future is just building familiarity and organizational comfort with the technology.

And I think the organizations that start building those muscles now are going to be in a much better position a year from now than the organizations waiting for a perfect solution to appear.

Babi Das [00:55:38]: I think from my perspective, the biggest thing that’s going to evolve is reliability and consistency.

Right now, there’s still a lot of concern around trust.

Can I trust this output? Is it repeatable? Is it defensible?

What we’re seeing already is movement toward systems that are much more measurable, auditable, and policy-driven.

I think over the next year you’ll see more enterprise governance wrapped around AI systems, especially in accessibility and compliance work.

Organizations should prepare by thinking about process, not just tools.

Think about validation workflows, audit trails, escalation paths, and how humans stay involved in the process.

Because I don’t think the future is humans versus AI.

I think it’s operational systems where AI handles scale and humans handle judgment.

Pete Bruhn [00:56:32]: Awesome.

Alright, I think we have time for one final question here.

What advice would you give accessibility professionals who are worried that AI might replace parts of their jobs?

Doug Abrams [00:56:46]: I can jump in on that one.

I think the first thing I’d say is that accessibility is fundamentally human-centered work.

A lot of what makes somebody good at accessibility isn’t just identifying technical issues. It’s judgment, communication, empathy, prioritization, and understanding user experience.

Those are things AI still struggles with.

What I do think will happen is that some of the repetitive parts of the job will change.

And honestly, that’s already happened throughout the history of technology.

Automation has always changed workflows.

But I think accessibility professionals who learn how to work alongside these tools are going to become much more effective and valuable, not less.

Dylan Isaac [00:57:33]: Yeah, I strongly agree with that.

I actually think accessibility professionals are uniquely positioned right now because we’ve spent decades thinking about ambiguity, edge cases, human behavior, and systems thinking.

Those are exactly the kinds of problems that AI systems struggle with.

So instead of thinking about AI replacing accessibility expertise, I think accessibility expertise becomes more important because now we need people who can encode judgment into workflows.

We need people who understand what “good” actually means.

And I think the people who document their reasoning, build systems around their expertise, and learn how to supervise these workflows are going to be incredibly valuable.

Babi Das [00:58:18]: I agree with both of them.

I would just add that historically, every major automation wave changed jobs, but it also created new categories of work.

I think we’re going to see accessibility professionals move more toward governance, oversight, validation, policy, and quality control.

Because if AI scales accessibility work, somebody still has to define quality.

Somebody still has to determine whether outcomes are actually usable and defensible.

So I think the expertise becomes more strategic, not less important.

Pete Bruhn [00:58:58]: Awesome.

Well, I think that’s a great note to end on.

Thank you again to all of our speakers today — Doug, Dylan, and Babi — for sharing your expertise and insights.

And thank you to everyone who attended and participated in the chat and questions.

We really appreciate your time, and we hope you found this valuable.

Have a great rest of your day, everybody.