The core point was straightforward: AI does not fix a broken process; it accelerates whatever process you already have. If accessibility is already in the workflow, AI can help scale inclusion. If it’s not, AI will scale the same barriers teams are already shipping.

# Full Transcript

Jessie Lorenz: Everybody here ships software on a pipeline that looks something like this, right? Planning, design, development and coding, code review and CI/CD, public release, and then feedback. And then you kind of turn around and start the whole merry-go-round again, incorporating feedback back into planning.

It is a six-stage pipeline. You know it. I know it too. I know it as a blind PM at Microsoft and I know it as someone who was born blind and often encounters the accessibility errors or barriers that get shipped.

So hold on to this pipeline, because everything we are about to talk about lands somewhere on it.

Jessie: Let us look at what happens when you solve your accessibility issues in the planning process. If you do that, it is a conversation. It is usually free to fix.

Wait until design? Well, it is going to cost you ten times more. Wait until it reaches development? One hundred times more. If you do not notice your accessibility barriers until they actually ship, it compounds even more: one thousand times more.

And each order of magnitude that compounds, if you really think about it, is a person, and multiples of people, being locked out of what you ship.

Accessibility debt is a lot like security debt, and you would not just let security debt lie. Accessibility debt should be treated the same.

Jessie: So we’re all excited about AI, right? Well, it accelerates the pace of software development and it also accelerates the creation of accessibility barriers. Both sides of the coin are true.

Why? AI is trained largely on a web that is inaccessible. AI learned from a web that is primarily inaccessible, full of barriers, and AI ships these barriers faster and in places where we’ve not seen them before.

Jessie: Accessibility belongs in your workflow. We are talking today not about slowing things down, not about trying to make things harder. We are actually talking about catching things early, catching things when they are cheaper, and implementing accessibility checks in every stage of the workflow.

That could be a lint rule in the editor. That could be a gate in CI. It could be a flag in code review. It is the same workflow that we talked about before, the same pipeline. It is just that each step has an accessibility check on it.

Jessie: I really hope I can make this real for you.

People are always coming to talk to me about how to get money for their accessibility ideas. One guy came and talked to me and he was trying to get VC funding to re-carpet the San Francisco airport. He thought it would be a really good idea to give blind people canes that could guide them on this special carpet and the canes would have Bluetooth in them.

Well, I saw this guy’s demo. He actually had some investor money lined up, and I asked him one simple question. It is the question I ask everyone: Did you talk to a single person with disabilities before creating this demo?

The answer to my question is all too often no. Unfortunately, this is an example of what ungrounded planning looks like. You have a clever solution, but you are not solving the right problem.

So the first step in creating an accessible software development lifecycle is to make sure accessibility is in your planning documents. That could be a question about how your feature will serve people with disabilities in a PR/FAQ. But if you do not put us in the roadmap, you are going to end up building something really beautiful that is answering the wrong question.

Jessie: My team in Microsoft AI is building voice-first features in Copilot, and we have data that shows 37% of voice-initiated tasks in Copilot are abandoned. That is not good.

We also have data that shows that more than one billion people in the world live with some kind of disability, a limitation to one or more major life activities. And 76% of folks who have dyslexia or other neurological impairments say that they are better at work when they can use Copilot.

So what the data shows us is that when Copilot voice breaks, it hits the people who need it most first and hardest. That is why we created a feature called Speak to Done, and that is how it got on our roadmap.

Now I am going to pass it to Aaron.

Aaron Gustafson: Once the planning is done, most teams begin designing the user experience and the user interface. Now, whether they are using traditional design software or newer vibe-design approaches, it is imperative that designers have the right tools and information to help them make accessible choices.

Aaron: One of the efforts that I have had the pleasure of working on in this space is the Accessibility Assistant plugin for Figma. It offers a suite of tools to help designers clarify the intent of their interface and assess the quality of their design when it comes to supporting people with disabilities.

Here on the screen I have a visual showing an annotated UI. Those annotations can actually act as an accessibility spec to guide engineering work. In fact, we are working on a new feature that will allow designers to export this accessibility information and hand that off to developers, whether they are human or whether they are agentic.

We have seen some really positive results from our early tests of handing off that accessibility spec to agentic workflows, both in being able to fix existing bugs in the interface based on the accessibility spec and in being able to build interfaces from scratch. They are even able to take simple things like an example row in a grid and extrapolate the accessibility annotations for that one row out to all the rows within the grid, which is really exciting.

The demo also shows one of the visualization tools that we have. We have a bunch of tools we are adding in for designers to help them understand how their designs end up being understood or experienced by people. In this case, we have done a focus order overlay to visually display how somebody would move through the interface.

By having this information early, and as Jessie said, in a way that is very cheap to make changes, improving accessibility at the design stage can take mere moments, but it can have a huge impact. It costs a lot more to change that once it is already ensconced in code.

Aaron: Even with a rigorous design system and robust accessibility specs, it’s still critical to embed accessibility into the coding process. As Jessie mentioned at the beginning of this talk, that becomes even more critical in the era of AI-assisted coding.

Aaron: Out of the box, most coding agents are pretty terrible when it comes to accessibility. That’s not surprising though. As Jessie said, they’re trained on what we created, and the web we created has not been all that accessible, so they learned from us.

Left to their own devices, most of the code they write only passes about 8–25% of automatable accessibility checks.

Instruction files are often touted for their ability to steer models toward better outcomes by teaching them what the accessibility expectations should be up front, but even with that the pass rate only climbs to 37–60% of automatable checks.

When you start imbuing agents with skills, you get closer to a pass rate of roughly 86%, but it is not until you give them actual deterministic tests to run, and instructions on how to use them, that you get them to iterate until the code passes all of those automatable checks.

But even that only gets you so far because it takes you to the limit of what is testable purely in an automated fashion, via unit tests and integration tests. It does not cover things like usability, so I want to put it in context: automatable tests only cover about 50% of what you need for a UI to be considered truly accessible.

Still, every step in the right direction counts. And now that we have discussed accessibility in the code authoring context, I am going to hand it off to Carie to talk about embedding accessibility in the code review process.

Carie Fisher: I am from GitHub, and we made an Accessibility Scanner. It’s open source. If you have not checked out the booth, we have a demo there.

What we are talking about here is bringing accessibility alongside the other feedback developers already expect. In pull requests, it should show up alongside code quality and security feedback. In CI/CD, accessibility checks should run where automation makes sense, whether you are using GitHub Actions, Azure Pipelines, browser tests, or deterministic tests. We want to be where you are and make sure accessibility is considered.

After release, issues and feedback should flow back into the backlog and into better patterns for next time. The PR is necessary, but it is not enough. If accessibility only appears at the end, we are still fixing after the fact.

The bigger direction here is to embed accessibility into AI tooling and engineering practices so innovation scales inclusion, not exclusion.

Carie: GitHub’s AI-powered Accessibility Scanner makes that workflow concrete with a simple loop: Find, File, Fix.

First, it helps find repeatable accessibility issues. Then it files actionable GitHub issues instead of leaving teams with a separate report that lives outside their workflow. And then those issues become useful context for fixing, including with Copilot-assisted remediation.

Under the hood, we’re using Deque’s aXe ruleset, which is basically the gold standard for automated accessibility checks. It is free, it is open source, and we created the GitHub workflow around it so you can scan your page for accessibility errors, create issues, and then even assign those issues to Copilot to draft a pull request.

We deliberately left a spot for a human to stay in the loop and make sure the result is truly accessible. As Aaron and Jessie have said, automated checks may only catch about half of the issues overall. You still need manual checks and you still need to work with people with disabilities to make sure your product is really inclusive.

Carie: We don’t have time to run through the full demo on stage, but this is the workflow we wanted people to remember. Accessibility is not happening in a separate process. It is part of the same system teams already use to build, triage, review, automate, and ship.

Carie: When accessibility is integrated, magic happens.

Jessie: I am a blind PM at Microsoft and most days I spend them telling software what I want it to do and then spending an inordinate amount of time cleaning up what it did wrong.

My team owns two really powerful features called Copilot Tasks and Copilot Cowork. They are super powerful. However, they did not have voice included in them, so we created a feature called Speak to Done, which is the voice layer over Copilot Tasks and Copilot Cowork.

I said, “Find that track meet email from three weeks ago, add it to my calendar, and text the other parent.”

Copilot did not lose context, did not break, found the track meet in the Gmail thread, put it on the calendar, and sent it to the other parent without breaking.

Now let me be clear: without the shift-left practices, without the tools that we talked about today, the Figma plugin at the design process, the deterministic testing, the code review, none of these features reach me.

Speak to Done is really cool because it solves a problem that disproportionately impacts folks with disabilities, like we talked about earlier, but it also helps everybody who wants to use Copilot with their voice.

In disability circles, we talk a lot about the curb-cut effect. Back in the 1960s, they did not have curb cuts. Wheelchair users in Berkeley literally started taking sledgehammers to the curbs and making them themselves. Now we see curb cuts everywhere, and who benefits? People who use strollers, delivery workers, all of society.

That is a little bit of what we are trying to convey today. When we are talking about the things we build, we are not talking about tools. We are talking about who gets to use what we ship.

I encourage you to be conscious about creating a more accessible world, one code snippet at a time.

If you want to dig into the tools we referenced, here is the resource page for the talk.

Along the way, we shared examples from Microsoft and GitHub, including the Accessibility Assistant for Figma, deterministic testing for AI-assisted coding workflows, and GitHub’s Accessibility Scanner. The through line was simple: if accessibility is part of the process, AI can help scale inclusion; if it is missing, AI can scale exclusion just as quickly.

That’s the part too many people seem eager to hand-wave away. These systems are not arriving with some magically enlightened understanding of disability, inclusion, or accessible implementation. They’re being trained on the web as it is, which means they are taking all of its worst practices as truth.

If we want AI-assisted coding to improve outcomes rather than exponentially accelerate harm, accessibility must be foundational.

I also appreciate the callback in the title. We’ve been here before. The particulars may be new, but the core challenge is familiar: how do we build resilient, inclusive systems when the output is fluid, personalized, or otherwise beyond a designer’s exact control? Accessibility is not a bolt-on answer to that question; it’s where the answer has to begin.

This is the part too many teams miss: accessibility doesn’t end at the component boundary. A well-built component library can give you a stronger foundation, but it can’t guarantee the right labels, the right heading structure, the right focus management, or the right overall experience once those pieces are assembled into an interface. That work still requires judgment, care, and testing with actual people.

I know someone that uses her screen reader on her mobile phone, but when she’s on her desktop computer, she uses a mangifier.

Different contexts, different tools, same person.

I know someone that uses voice controls on his computer. He uses direct commands like “Click Contact Us” when he’s near the start of his day, and commands like “Click link, twelve” when he’s near the end of his day with lower energy and less clear speech and a dry mouth.

Different energy/capacity, same tools, same person.

I know someone that uses a switch on his computer. He also uses the onscreen keyboard on his computer. The one that he chooses reflects the task he’s trying to accomplish and how he can minimize switching between the tools.

Different task, same context, same tools, same person.

Disability is not black and white… it’s every shade of every colour.

We’re in the middle of a major overhaul. To get there, we needed a lot of foundational infrastructure work to modernize the plugin and prepare for new features that help designers produce more accessible work, faster. This release includes a big chunk of that groundwork, notably:

• Annotations are now presented as Figma-native Dev Mode annotations; this greatly reduces the working overhead of the plugin and reduces visual clutter in the document. We’ve also color-coordinated the icons in the Annotation Set viewer to the labels you see in the Dev Mode annotations, making it easier to scan.
• Legacy annotation tables will automatically be migrated into the new system. The visual readout tables will be hidden when this happens, but are still accessible if you need to copy or reference them. We’ve also included a tool to clean up these old layers when you’re ready.
• Annotations are now managed in a single UI rather than split by focus-order impact. That means you no longer need to jump back and forth between tools to annotate designs correctly.
• We’ve organized and expanded the list of W3C roles available in the role picker. Additionally, the form now adapts to the role, offering you only the relevant fields and reducing distraction. We also added a description field, should you need it.

We also fixed duplication bugs. You can now copy layers and keep their annotations as a new Annotation Set. Similarly, duplicating pages now regenerates page-bound annotations automatically. On especially large pages, that regeneration may take a little time.

This release has been a long time coming, and I’m incredibly proud of the team behind it, especially Ashish Singh from HCL, and Michael Fairchild, Scott O’Hara, and Ben Truelove from Microsoft. Their care, and their depth of accessibility knowledge, has been instrumental in getting this project to where it is today.

And there’s more to come!

I immediately invited them to pitch us for the AI for Accessibility Grant Program that I ran for Microsoft. With so much focus on assistive technology to enable folks to work and accomplish common life tasks, I loved that the OneCourt team was interested in enabling people with disabilities to enjoy leisure activities like sporting events. Moreover, I saw the potential to enable Blind and low-vision parents to experience their kids’ sporting events, which could be life-changing for them.

Needless to say, they wowed both me and the rest of the seleciton committee. We funded them to expand their prototypes and pursue partnerships with different professional sports leagues, teams, and venues. They were ambitious and it’s paying off.

Fast forward a few years and they’re enabling a handful of Blind & low vision sports fans to exerience the Super Bowl in a whole new way, using their technology. It’s amazing and I could not be more proud of them.

Congrats y’all!

Learning objectives:

1. Understand the pivotal role AI plays in crafting cutting-edge accessible technologies.
2. Learn about innovative AI tools that empower individuals with disabilities.
3. Dive into best practices for creating inclusive AI solutions.
4. Explore the exciting future of AI in pushing the boundaries of accessibility

Great summary here:

[M]y passion for accessibility stems from experiencing accessibility barriers personally, observing their impact on others, and holding the conviction that technology should tear down divides - not erect new ones. I want to fulfill, and help you fulfill, the web’s promise of equal access and opportunity for everyone, regardless of circumstances. Digital accessibility should not be an accommodation but a fundamental right and prerequisite for technology to truly better humanity.

Excitement around how AI can change the way we live and work has reached fever pitch — but less often discussed is how it could create a more inclusive, accessible world. Yet the opportunity is vast. Sifted estimates the addressable market for disability tech is somewhere in the 2bn range, while PwC predicts AI could contribute nearly $16tn to the global economy by 2030.

I’d like you to consider this a “yes… and” piece to complement Joe’s post. I don’t seek to refute any of what he’s saying, but rather provide some visibility to projects and opportunities where AI can make a meaningful difference for people with disabilities (PwD) across the globe. To be clear, I am not saying there aren’t real risks and pressing issues with AI that need to be addressed—there are, and we needed to address them like yesterday—but I want to take a little time to talk about what’s possible, in hopes we’ll get there one day.

# Alternative text

Joe’s piece spends a lot of time talking about computer vision models generating alternative text. He highlights a ton of valid issues with the current state of things. And while computer vision models continue to improve in terms of the quality and richness of detail in their descriptions, the results are not great. As he rightly points out, the current state of image analysis is pretty poor—especially for certain image types—and the current systems examine images in isolation rather than within the context in which they sit (a consequence of having separate foundation models for text analysis and image analysis).

These models are also not currently trained to distinguish an image that is contextually relevant (for which there should probably be a description) from one that is purely decorative. Of course this is something we humans struggle with as well… the right answer is often somewhere between the author’s intent and the user’s needs/preferences.

All of that said, there is potential in this space.

As Joe mentions, human-in-the-loop authoring of alt text should absolutely be a thing. And if AI can pop in to offer a starting point—even if that starting point is prompting you to say What is this B.S.? That’s not right at all… let me fix it—I think that’s a win.

Taking things a step further, if we can specifically train a model to analyze image usage in context, it could help us more quickly identify which ones are likely to be presentational and which ones likely require a description. That will help reinforce the importance of descriptions in the appropriate context and improve the efficiency with which authors can make their pages more accessible.

While complex images—graphs, charts, etc.—are challenging to describe in any sort of succinct way (even for humans), the image example shared in the GPT4 announcement points to an interesting opportunity here as well. Let’s say the description of a chart was simply the title of the chart and the kind of visualization it was. For example: Pie chart comparing smartphone usage to feature phone usage among U.S. households making under $30,000 a year. If the browser knows it’s a pie chart (because an onboard model verified this), imagine a world where a user could ask questions about the graphic.

• Do more people use smartphones or feature phones?
• How many more?
• Is there a group of people that don’t fall into either of these buckets?
• How many is that?

Setting aside the realities of Large Language Model (LLM) hallucinations for a moment, the opportunity to interface with image data in this way could be revolutionary for blind and low-vision folks as well as people with various forms of color blindness, cognitive disabilities, and so on. It could also be useful in an educational context to teach people who can see the chart, as authored, to read a pie chart.

Taking things a step further, what if you could ask your browser to simplify a complex chart, perhaps isolating a single line on a line graph? What if you could ask the browser to transpose the colors of the different lines to work better for the specific form of color blindness you have? What if you could swap colors for patterns? Given the chat-based interface and our ability to manipulate existing images in currently available AI tools, that certainly seems like a possible future.

Now imagine a purpose-built model that could extract the information from that chart and convert it to another format. For example, it could turn that pie chart (or better yet, a series of them) into a more accessible (and useful) format like a spreadsheet. That would be amazing!

# Matching Algorithms

Safiya Umoja Noble absolutely hit the nail on the head with the title of her book Algorithms of Oppression. While it was focused on search engines reinforcing racism, all computer models have the potential to amplify conflict, bias, and intolerance. Whether it’s Twitter always showing you the latest tweet from a bored billionaire, YouTube sending us into a Q-hole, or Instagram warping our idea of what a natural body looks like, we know poorly authored and maintained algorithms are incredibly harmful. A lot of this stems from a lack of diversity among the people who shape and/or build them. When built inclusively, however, there is real potential for algorithm development to benefit people with disabilities.

Take Mentra, for example. They are an employment network for neurodivergent people. They employ an algorithm to match job seekers with potential employers, based on over 75 different data points. On the job seeker side of things, it takes into account the candidate’s strengths, necessary workplace accommodations (and preferred ones), environmental sensitivities, and so on. On the employer side, it takes into account the work environment, communication factors related to the job, and the like. As a company run by neurodivergent folks, Mentra made the decision to flip the script when it comes to typical employment sites. They use their algorithm to propose available candidates to the companies, who can then connect with job seekers they are interested in; reducing the emotional and physical labor on the job seeker side of things.

When more people with disabilities are involved in the creation of algorithms, there is a lessened likelihood that these algorithms will be used to inflict harm on their communities. This is why diverse teams are so important.

Imagine if a social media company’s recommendation engine was tuned to analyze who you’re currently following and prioritized recommending that you follow people who talked about similar things, but who were different in some key way from your existing sphere of influence. For example, if you follow a bunch of non-disabled white male academics who talk about AI, it could suggest you follow academics who are disabled or aren’t white or aren’t male who also talk about AI. If you took its recommendations, you’d likely get a much more holistic and nuanced understanding of what is happening in the AI field.

# Other Ways AI Helps PwD

If I weren’t trying to put this together between other tasks, I’m sure I could go on, ad infinitum, providing all kinds of examples of how AI can be used to the benefit of people with disabilities, but I’m going to make this last section into a bit of a lightning round. In no particular order:

• Voice preservation. You may have seen the VALL-E paper or Apple’s GAAD announcement or you may be familiar with offerings from Microsoft, Acapela, and others. It is possible to train an AI model to replicate your voice, which is tremendous for people who have ALS/MDN and other medical conditions that lead to dysarthria. This is, of course, the same tech that can be used to create audio deepfakes, so it’s something we need to approach responsibly, but the tech has truly transformative potential.
• Voice recognition. Researchers like those in the Speech Accessibility Project are paying people with disabilities for their assistance in collecting recordings of people with atypical speech. As I type, they are actively recruiting people with Parkinson’s and related conditions and they have plans to expand this to other etiologies as the project progresses. This research will result in more inclusive data sets that will enable more people with disabilities to use voice assistants, dictation software, and voice response services as well as control their computers and other devices more easily, using only their voice.
• Text transformation. The current generation of LLMs is quite capable of making adjustments to existing text content without injecting hallucinations. This is hugely empowering for people with cognitive disabilities who may benefit from a text summary or the text being simplified or even from it being prepped for bionic reading.

# The Importance of Diverse Teams and Data

Of course to do things like this, we need to recognize that differences do matter. Our lived experiences are influenced by the intersections of identity in which we exist. Those lived experiences—with all of their complexity (and joy and pain)—are valuable inputs to the software, services, and societies we shape. They need to be represented in the data we use to train new models and the folks who contribute that valuable information need to be compensated for sharing it with us. Inclusive data sets yield more robust models that enable more equitable outcomes.

Want a model that doesn’t demean or patronize or objectify people with disabilities? Make sure content about disability, authored by people with a range of disabilities is well-represented in the training data.

Want a model that doesn’t use ableist language? Use existing data sets to build a filter that can intercept and remediate ableist language before it reaches an end user.

Want a coding co-pilot that gives you accessible recommendations from the jump? Train it on code that is known to be accessible.

I have no doubt that AI can and will harm people… today, tomorrow, and well into the future. However, I also believe that we can acknowledge that and, with an eye towards accessibility (and, more broadly, inclusion), make thoughtful, considerate, intentional changes in our approaches to AI that will reduce harm over time as well. Today, tomorrow, and well into the future.

Earlier today, the idea of a “spoiler / content warning” element popped onto my radar through the Web We Want inbox. It referenced a discussion over on the WICG and I was intrigued but the potential of this kind of feature for HTML. Some folks suggested progressive disclosures like details/summary was the way to go, but that approach is limited to flow content (and fraught with a host of issues).

# Markup possibilities

I wasn’t sold on the idea of a spoiler element either, as that’s a pretty specific use case of a content warning. And so I wondered, what if instead of an element, we introduced an attribute that could take the kind of content warning as its value. For example, consider the following:

<articlecontent-warning=“child abuse”>… article contents …</article>

This would identify the entire article as discussing child abuse. Obscuring that behind a warning would probably be a good idea.

Or perhaps the content warning should apply to an image:

<imgcontent-warning=“violence gore”…/>

Or, to return to the original idea of a spoiler, it could also be applied inline:

I thoroughly enjoyed the film, especially when it was revealed that<bcontent-warning=“spoiler”>Taye Diggs had been the bad guy all along</b>.

# Necessary behaviors

When considering how content behind a warning should be handled, there are a few things that jump immediately to mind:

1. Indicated content should be obscured by default.
2. Users must choose to reveal the content.
3. Content should not be included in the “find in page” index.
4. Images should not be downloaded until they are requested (or there is a good chance they will be needed).

There’s also an interesting opportunity for browsers to offer user preferences around this approach as well. For example, I may never want to be shown content that deals with rape, so I could configure that in my preferences and the browser could take additional steps to hide that content from me or at least make sure I actually want to reveal it by requiring a second step for final approval (i.e., Are you actually sure you want to see this?).

# Demo

I threw together a quick & dirty demo of what the experience could be like on Codepen if you’d like to take a look:

It’s still a work-in-progress, but it’s a starting point. Ideally the browser would handle all of this directly, rather than us having to author CSS and/or JavaScript to implement the feature ourselves. (Though maybe we could get access to style parts of the overlay.)

# Thoughts?

What do you think? Is this something you’d like to see on the web? I’d love to hear your thoughts, which you can share by Webmention-ing this post or referencing it on Mastodon.

# Update 2023-04-24

James Edwards mentioned the potential interplay issues with Reader Mode (and similar) so I started playing around with an alternate approach. I landed on a version that physically swaps out the elements in the DOM for a custom element content-warning that acts as a placeholder. Here’s how it works:

1. Author uses content-warning attribute as described above.
2. The runtime script swaps that element for the custom content-warning element, which contains a wrapper element (span) that is sized to occupy the same space as the original element (including margins).
3. The content warning text is used to label a button inside that wrapper.
4. Clicking the button swaps the original element back into position and announces it to screen reader users (using role="alert").

I tested this approach with VoiceOver and JAWS and it works a treat. I also confirmed the Edge’s Reader Mode does not deliver the hidden content.

Note: The browser doing the work of my demo would be much faster as it could do all the size calculations prior to rendering. I am having to fake that in JavaScript, so I have to peg it to the window’s onload event to ensure all CSS is applied to get the size calculations right.

Here is an excellent testing tool as well: https://www.color-contrast.dev/

1. Understand the user’s motivation, and the goals and tasks they are trying to complete.
2. Discern the cognitive load required to reduce that mismatch.
3. Co-create the final product with a diverse community of people across the spectrum.

It’s so great to see this seminal resource continuing to evolve.