accessibility

An Open Letter to Matt Mullenweg on Accessibility in WordPress

by

October 18, 2026

Dear Mr. Mullenweg,

I am writing to you publicly as a blind daily screen reader user, an IAAP Certified Professional in Web Accessibility (CPWA), and the publisher of Blind Access Journal. Many of our readers, and many of my professional colleagues, are authors, creators, publishers, developers and site owners with disabilities who rely on WordPress every day. I am choosing to make this letter public because the decisions at issue were made in public, they affect a very large community of people, and that community deserves to hear your answers directly.

My concern is your recent action on WordPress Trac ticket #50486, “Improve the admin notices accessibility”, and what it signals about the future of accessibility in WordPress.

What the Ticket Was Meant to Fix

Ticket #50486 was opened in 2020 to address a basic barrier. Admin notices in WordPress carry no semantics that identify them to assistive technology. When a notice appears, a screen reader user is not told about it, and a keyboard user has no way to move directly to it. In practice, people like me can miss confirmations, warnings and errors that sighted users see at a glance.

The ticket was postponed through many release cycles. Earlier this month, a modest fix was finally committed. It placed notices in a navigable landmark and added a notice count to the page title, which is the first thing a screen reader announces when a page loads. After six years, it represented real progress.

What Happened Next

The change surfaced legitimate technical problems, including notice counts appearing on the Dashboard and in the block editor when no notices were visible, and contributors were actively working through fixes. Refining or reverting an imperfect change is a normal part of software development, and the revert commit that followed explained its technical reasoning clearly. My concern is not that the work was revised. My concern is how the decision was made and what accompanied it.

Your first comment on this six-year-old accessibility ticket was an instruction to revert all of the work. In the same comment, you told Andrea Fercia that he no longer holds any WordPress.org positions or authority and was “invited to contribute your talents to another project.” No technical reasoning was offered on the ticket. As reported by The Repository on October 16, you later said in WordPress Slack that you were simply no longer interested in his contributions. I acknowledge that you also apologized for the temporary locking of his account and said that was not your intent.

Mr. Fercia has contributed to 33 WordPress releases, has been a core committer for a decade, and is one of the most experienced accessibility specialists the project has had. Removing him in this way, on an accessibility ticket and in the middle of active collaboration on that ticket, sends an unmistakable signal to disabled users and to the people who advocate for us.

A Pattern That Concerns Our Community

This does not stand alone. In August, you declared that the Accessibility Team had overstepped its authority, usefulness and charter, and that any other team or committer could override its suggestions. In 2025, you proposed developing accessibility improvements as a canonical plugin rather than in core. Taken together, these actions make it difficult for disabled users to know whether accessibility remains a core value of WordPress or is now treated as an obstacle to progress.

Accessibility cannot be optional for the people who need it. When it lives outside core, or depends on the standing of individual advocates, people with disabilities are the ones left behind.

The effect on contributors matters too. Several respected members of the WordPress community have said publicly that they feel unable to speak freely about these events. A project that depends on volunteer and sponsored contributions cannot build accessible software if the people doing that work fear the consequences of doing it.

Important Questions

In the spirit of openness that the WordPress project has long championed, I respectfully ask you to answer the following questions publicly:

  1. Do you consider accessibility a core requirement of WordPress, on equal footing with performance, security and usability, rather than an optional enhancement?
  2. What is your plan, and the expected timeline, for making admin notices perceivable and navigable for screen reader and keyboard users, now that the work on ticket #50486 has been moved to a future release?
  3. What authority and role will the Accessibility Team hold going forward, and how will its expertise be incorporated into decisions that affect disabled users?
  4. What process and criteria were applied in removing Andrea Fercia’s roles, and what process will govern similar decisions in the future, consistent with the project’s Code of Conduct?
  5. What commitment can you make to authors, creators, developers and site owners with disabilities that the tools they depend on will remain accessible to them?

An Invitation to Respond

WordPress powers a large share of the web, and its choices shape what millions of people, including millions of people with disabilities, can read, publish and build. Clear answers would go a long way toward restoring trust. Should you choose to respond, Blind Access Journal will publish your response in full and without edits, so our readers can hear directly from you.

To our readers, and to everyone in the WordPress community who shares these concerns: I encourage you to read The Repository’s reporting and the ticket history for yourselves, and to add your voice respectfully and constructively.

Sincerely,

Darrell Hilliker, CPWA
Publisher, Blind Access Journal

The Monarch as My Silent Co-Presenter: Braille Notes That Kept a Live Accessibility Demo on Track

by

Anyone who has delivered a live technology demonstration knows the feeling: you are driving the screen reader, narrating every keystroke for your audience, fielding questions, and somewhere in the back of your mind trying to remember which example comes next. Recently, I delivered a screen-reader accessibility demo on the job, and this time I had a secret weapon sitting right beside my keyboard: my Monarch multi-line Braille display.

The Demo: Keyboard and Focus Success Criteria in the Real World

The demonstration walked my colleagues and students through real examples of both failures and successes of the keyboard and focus WCAG success criteria, using a popular electronics shopping website with the JAWS screen reader on Google Chrome. Live sites are wonderful for this kind of demo because nothing is staged, but that same unpredictability means a presenter needs a reliable way to stay oriented. Which page was I visiting next? Which control demonstrated the focus visibility failure? Which component showed keyboard access done right?

Preparing My Notes with QUILL and KeyDrive

Before the session, I wrote up brief notes as a plain text file using the new QUILL editor. If you have not tried it yet, QUILL is free, community-driven, screen-reader-first writing software for Windows and macOS, designed from the ground up for blind and low-vision users, with first-class support for braille displays and braille file formats. It was the perfect tool for quickly capturing a clean, uncluttered outline of my demo steps.

I saved the notes to Google Drive, then loaded them onto the Monarch using KeyDrive. That was the entire workflow: write, save, load. No conversion gymnastics, no printing, no last-minute scrambling.

Ten Lines of Braille Changed Everything

Here is where the Monarch earned its keep. As I moved through the live demonstration, I could simply reach over to the device, quickly find my place on the 10-line braille display, and jog my memory about which steps to complete in what order. Because I could see an entire section of my outline at once rather than a single line at a time, reorienting took a moment of light touch reading instead of a disruptive pause. My hands stayed in the flow, my narration never stalled, and my audience got a smooth, confident walkthrough.

For those of us who present regularly, this is the multiline difference in a nutshell. A single-line display can hold your notes, but a ten-line display lets you scan them the way a sighted presenter glances at index cards or speaker notes.

The Result

The demo was a resounding success, with lots of engagement and feedback from attendees. Showing real keyboard and focus barriers, and real fixes, on a website people actually use makes accessibility concrete in a way no slide deck can. Having my braille notes at my fingertips let me focus on the teaching instead of the logistics.

Thank You, APH Project Rise

None of this would have been possible without the Monarch RISE Project from the American Printing House for the Blind, which provided me with my Monarch along with all the amazing opportunities that come with it. Project Rise is building a community of Monarch users who share strategies and success stories to advance braille access and competitive integrated employment, and I am deeply grateful to be part of it. This demo was exactly the kind of workplace win the project was created to make possible.

From the Outside In to the Inside Out: My First Global Accessibility Awareness Day at Khan Academy

by

Khan Academy recently published a recap of its Global Accessibility Awareness Day (GAAD) celebration, written by Elizabeth Barker, Senior Technical Program Manager for Accessibility. You can read the full article here: The Duality of May: Why Global Accessibility Awareness Day Hits Differently.

As many of you know, I joined Khan Academy as an Assistive Technology Specialist late last year, and this was my first GAAD with the team. I want to tell you about the part I played, because it speaks to something I believe in deeply: nothing replaces the lived experience of a real assistive technology user.

Walking the team through our product, my way

My contribution to the day was a live, firsthand walkthrough of Khan Academy’s product, including plotting a point on an accessible graph, reading an article and chatting with the Khanmigo learning assistant, using the tools I rely on every day: a screen reader and a refreshable braille display. No simulation. No blindfold exercise. No hypothetical personas. Just an honest tour of exactly where our product shines and exactly where it falls short, delivered by someone who navigates the web this way as a matter of daily life.

This is the kind of feedback that hits differently for sighted developers and designers. Reading a WCAG checklist tells you what the rules are. Watching a native screen reader user encounter an unlabeled button, a focus trap, or a beautifully structured heading hierarchy tells you why the rules exist. As Elizabeth put it in her article, this is the most powerful kind of feedback there is.

A full day of awareness paired with action

My walkthrough was one piece of a genuinely well-designed day. Engineering Manager and Accessibility Architect Jeanette Head opened by celebrating the past year’s accessibility wins and setting ambitious goals for the year ahead. Senior Engineer Marcy Sutton Todd led a No Mouse Challenge, asking participants to navigate using only Tab, Shift+Tab, the arrow keys, Enter, and Escape — and watching colleagues discover keyboard traps and missing focus indicators in real time was its own kind of education.

The day closed with a Big Bug Bash devoted entirely to accessibility. By the end, more than 20 accessibility bugs had been fixed, with accessibility experts on hand to explain patterns, review fixes, and test solutions before launch.

Why this matters

Longtime readers of Blind Access Journal know I’ve spent more than three decades pushing for digital accessibility, often from the outside in. What made this GAAD meaningful for me was being on the inside — invited not as an afterthought or a compliance checkbox, but as a colleague whose perspective shaped the day.

Awareness paired with action. That’s the standard every organization should hold itself to, on GAAD and on the other 364 days of the year.

Go read Elizabeth’s full recap on the Khan Academy Blog, and if your organization hasn’t yet put a real assistive technology user in front of your product team, consider this your nudge.

Top Tip Thursdayh: Tap, Tap, Tap — The One-Finger Triple Tap You Should Be Using Every Day

by

Happy Top Tip Thursdayh, everyone! Today’s tip has a fascinating story behind it — and it comes with a built-in promise: by the time you finish reading this, you’ll have a faster, easier way to do several things on your iPhone or iPad that you probably do every single day. We’re talking about the one-finger triple tap in VoiceOver, and why it may be one of the most underappreciated gestures in your entire toolkit.

A Quick History Lesson

Let’s set the scene. Before iOS 13.2, performing the equivalent of a long press with VoiceOver required the double-tap and hold gesture. You’d double-tap an item and keep your finger pressed down on the second tap, then wait — and wait — for a rising tone that signaled iOS was ready to register your long press. Only then could you complete the action. It was fiddly, timing-dependent, and not exactly a joy for users dealing with any kind of hand tremor, fatigue, or fine motor challenge. Keyboard users had it a bit easier with a key combination, but for touch users, it was genuinely tedious.

With the release of iOS 13.2, Apple quietly made a change that many users didn’t even notice at the time. The one-finger triple tap — which previously simulated a plain double-tap — was reassigned to bring up the contextual long-press menu directly. No holding. No waiting for tones. Just three quick, clean taps. The old triple-tap behavior was bumped to a four-tap gesture, which almost no one was using anyway. It was a thoughtful, practical swap, and it is one that even experienced VoiceOver users have only discovered in recent years — sometimes long after it happened.

If you’ve been on iOS for a decade or more and never knew about this, you are in very good company. We hear from VoiceOver users all the time who have just stumbled across this gesture and wondered where it had been all their lives.

So What Exactly Does It Do?

In short, the one-finger triple tap opens the contextual menu — the same menu a sighted user would see by pressing and holding on an item. This is where all the good stuff lives: the options that aren’t available from a simple activation, the actions that apps reserve for “press and hold.” What appears in that menu depends entirely on where you are and what you’re focused on. VoiceOver will announce the first available option, and you can then swipe right to move through the choices and double-tap the one you want.

Where It Really Shines: Real-World Examples

This is where it gets practical. The triple tap isn’t just an abstract gesture — it earns its keep in apps you’re probably using right now.

Apple Music

Apple Music is one of the best examples of why this gesture matters. Navigate to a song, album, or artist in your library or in a playlist, and triple-tap it. You’ll get a rich action menu that gives you options like Add to Library, Add to a Playlist, Share, Go to Artist, Go to Album, and more. Without the triple tap, reaching these options would mean navigating into a separate detail screen or hunting for a dedicated button — if one even exists. With it, you get the full action sheet right where you are, immediately. This is a workflow that becomes dramatically more efficient once you know about it.

Home Screen App Icons

Triple-tapping any app icon on your home screen brings up that icon’s long-press menu, giving you options like Remove App, Edit Home Screen, and — for apps that support them — Quick Actions. Quick Actions are app-defined shortcuts that let you jump straight to a specific feature: compose a new message in Mail, scan a document in Notes, start a new workout in Fitness, and so on. Previously, getting to these required either entering the edit mode wiggle dance or relying on the double-tap and hold. Now it’s three taps.

Messages and Mail

In Messages, triple-tapping on an individual message bubble gives you access to reaction options, Reply, Copy, and more — the same menu sighted users get with a long press. In Mail, a triple tap on a message in your inbox brings up options like Reply, Flag, Mark as Unread, Move, and Trash, all without needing to open the message first. For anyone who processes a lot of email, that’s a meaningful time-saver.

Safari Links

When you’re browsing in Safari and your VoiceOver focus lands on a link, a one-finger triple tap gives you the link’s contextual menu: Open, Open in New Tab, Add to Reading List, Copy Link, and Share. For users who routinely open links in new tabs or send links to others, this is far more efficient than opening the link first and then navigating back to share it.

Photos

In the Photos app, triple-tapping on a photo in your library opens options including Share, Add to Album, Copy, Duplicate, and more. It’s the quick action layer for your photo library, and it works on individual photos whether you’re in the main grid view or inside an album.

The App Store

Triple-tapping an app in the App Store gives you quick access to options like opening its detail page or interacting with it directly. And in your App Library or on your home screen, it’s how you can get to app updates or quick action shortcuts without going through additional navigation steps.

How to Do It

The gesture itself is straightforward. Navigate to the item you want — make sure VoiceOver has announced its name — and tap three times in quick succession with one finger. Keep the taps brisk and even, the way you’d do a double-tap but with one extra. VoiceOver will announce the first option in the contextual menu, and from there you swipe right to browse and double-tap to activate.

If the gesture doesn’t respond on the first try, experiment with the speed. Some users find a slightly slower rhythm works better for them, and you can also fine-tune the double-tap timeout — which affects the timing of triple taps as well — by going to Settings, then Accessibility, then VoiceOver, and looking for the Double-tap Timeout setting.

A Note on Accessibility

What makes the one-finger triple tap especially valuable is that it asks nothing of the user beyond a quick, repeating tap. There’s no holding, no precise timing window, no risk of an accidental drag. For VoiceOver users who experience tremors, arthritis, reduced grip strength, fatigue, or any other condition that makes sustained screen contact difficult, this gesture removes a genuine barrier that the double-tap and hold was putting in the way. Apple’s decision to make this change in iOS 13.2 was a small but meaningful accessibility improvement, and it’s one more reason why keeping iOS up to date is always worthwhile.

Your Turn

Open Apple Music right now, navigate to any song in your library, and give it three quick taps. See what comes up. Then try it on an app icon, a text message, or a Safari link. Once you start using the one-finger triple tap, you’ll find yourself reaching for it constantly — and wondering how you ever got along without it.

As always, we’d love to hear from you. Was this gesture already in your repertoire, or is today the day it clicked? Let us know in the comments or find us on social media. And if there’s a tip you’d like to see featured on a future Top Tip Thursdayh, we’re always listening.

Until next Thursdayh — three taps and you’re there!

Top Tip Thursday: Inspecting Web Elements with Your Screen Reader

by

Ever want to peek under the hood of a web page without having to open browser developer tools? If you’re a JAWS or NVDA user, you’re in luck — this is something you can do right from your screen reader.

JAWS has this capability built in, and NVDA users can get the same functionality through the HTML Element Inspector, a free add-on created and maintained by Amir Soleimani.

Here’s how it works: move your browse mode or virtual PC cursor to any element you’re curious about and press Insert+Shift+F1. You’ll get a quick, no-fuss look at how that element is represented in the browser’s Document Object Model (DOM) — which is essentially how the browser exposes page details to your screen reader.

And it doesn’t stop there. Keep pressing the down arrow key past the initial tag and you can peel back the layers above that element, giving you a clearer picture of the higher-level structure of the page around it.

It’s a handy trick whether you’re troubleshooting an inaccessible page, satisfying your curiosity, or just leveling up your web literacy.

The Simple PTT Lucid: A Push-to-Talk Radio Built with the Blind Community in Mind

by

For years, push-to-talk over cellular (POC) radios have offered something remarkable: the reach of a nationwide radio network, without the limitations of traditional two-way radio. Whether you are coordinating a volunteer emergency response, connecting with fellow hobbyists across the country, or simply staying in touch with a group of friends spread across the world, POC radios deliver clear, reliable communication wherever a cellular signal exists. The problem, until recently, was that most of these radios were designed almost entirely with sighted users in mind — packed with visual menus, small unlabeled buttons, and displays that offered little to no spoken feedback.

That gap has now been addressed, and the story of how it happened is as encouraging as the product itself.

The Road to the Lucid

Simple PTT, a U.S.-based POC radio provider run by Scott Johnson — known in the community as “The Magician” for his ability to make things happen — was approached by a visually impaired user who saw an opportunity. Jed Barton, known online as JetN1JBC, raised the subject of accessibility directly with Johnson, explaining that the blind and low-vision community represented not just a market, but a group of people who genuinely stand to benefit from reliable push-to-talk communication. Johnson listened, took the idea seriously, and within approximately three weeks, worked with a hardware manufacturer to bring an accessible radio to life.

That radio is called the Lucid.

What the Lucid Is

The 2026 Lucid is a nationwide PTT walkie-talkie from Simple PTT, currently available at an introductory sale price of $99.99 (regularly $129.99). It operates over cellular networks using a multi-carrier SIM that floats between AT&T, Verizon, and T-Mobile, meaning coverage follows you across the country rather than being tied to any single carrier’s footprint.

The hardware itself is compact — measuring just 1.18 inches deep by 1.97 inches wide by 3.74 inches tall — and thoughtfully minimal. There are seven buttons total: a push-to-talk button on the left side, volume up and down, and four buttons across the front face beneath the display. That simplicity is intentional. Scott Johnson designed this radio with ease of use as a guiding principle, and for blind users specifically, a low button count means less confusion and faster muscle memory.

Under the hood, the Lucid carries a 4800mAh battery capable of all-day talk time and up to seven days on standby. It charges via USB-C, supports fast charging, and handles a wide range of LTE bands. For audio fidelity, it uses a high-sensitivity microphone combined with AI-driven noise cancellation that the manufacturer claims eliminates over 95 percent of background noise — a real benefit for users in busy or outdoor environments.

The Accessibility Feature That Changes Everything

What sets the Lucid apart from every other POC radio on the market is its spoken menu system. Every menu option, channel name, and member name is read aloud by the radio. You do not need to see the screen. You do not need a sighted assistant. You navigate the radio entirely through audio feedback and the physical buttons.

Jed Barton put together an audio demonstration of the Lucid in action, and it is well worth a listen for anyone who wants to experience the radio’s navigation firsthand. In the recording, Barton walks through the menus in real time, demonstrates navigating talk groups (the POC equivalent of channels), performs a private call to a friend in Boston, and shows how the member list functions — all without referring to the display at all.

The voice is what Barton cheerfully calls “a little Chinese-ish” — a result of the radio’s firmware originating from a Chinese manufacturer. It is not a polished American English voice, but it is clear, functional, and consistent. More importantly, it speaks. For a community that has long had to work around radios that communicate exclusively through tiny visual displays, a voice that reliably reads every menu item is a genuine breakthrough.

How the Platform Works

Simple PTT’s network has a strong community dimension. The platform hosts a wide range of public talk groups — the equivalent of open channels — where users from all over the world gather to connect and coordinate. Available groups include:

  • General social channels like The Hangout
  • POC Skywarn, for weather spotting and severe weather coordination
  • POC WX Alerts, for weather alert monitoring
  • Regional and purpose-driven channels for emergency preparedness and local communities

Switching between talk groups on the Lucid is as simple as navigating up or down with the arrow button and pressing the menu key to select. The radio announces the group name at each step, so you always know exactly where you are.

Private calls are equally accessible. From the member list, a user arrows to the name of the person they want to reach, selects them with the menu key, and keys the push-to-talk button. No guesswork required.

SIM plans vary, but unlimited service options are available, making the total cost of ownership — hardware plus service — quite competitive compared to licensing fees and equipment costs associated with traditional ham or GMRS radio setups.

Why This Matters

POC radio has always had real-world utility for the blind community. The ability to communicate instantly with a group — whether a family, a volunteer team, or a community of fellow users — without depending on the visual interface of a smartphone is genuinely valuable. The Lucid removes the last major obstacle, which was the radios themselves. What had been a category that required sighted assistance to configure and navigate is now independently operable by a blind user from the moment they take it out of the box.

The speed with which Simple PTT responded to the community’s request — roughly three weeks from conversation to finished product — also says something. It demonstrates that when manufacturers are willing to engage directly with blind users, meaningful accessibility improvements are achievable without years of advocacy campaigns or regulatory pressure. Scott Johnson heard a clear case for inclusion and made it happen.

Where to Learn More

The Lucid is available directly from Simple PTT at SimplePTT.com. The product page includes full specifications and SIM plan options. Jed Barton’s audio demonstration is an excellent companion resource, providing an honest and thorough walkthrough of the radio’s accessibility features in real-world conditions — a strong first step for anyone considering a purchase or simply wanting to hear the radio in action.

For blind and low-vision users who have been curious about POC radio but held back by accessibility concerns, the Lucid is a strong reason to take a second look at this technology. The network is already out there, the community is active and welcoming, and now the radio has finally caught up.

The AI Design Gap: A Student’s Journey in Accessifying Visual Layouts

by

As a Certified Professional in Web Accessibility (CPWA), I spend my days ensuring the web works for everyone. But as a student currently enrolled in a design course, I recently hit a wall that even my expertise combined with advanced artificial intelligence couldn’t easily scale.

The assignment was straightforward for most: Review a series of design samples and identify the visual layout being used—specifically, patterns like Z-shape, Grid of Cards, or Multi-column. For a blind student, however, this wasn’t just a design quiz; it was an accessibility challenge in its own right.

The Assignment

I was working through a module on Understanding Website Layouts. While the course platform itself was technically navigable, the “Design” samples provided were purely visual. To complete the assignment and select the corresponding layout buttons, I needed to understand the spatial arrangement of elements I couldn’t see.

I turned to a powerful ally: the March 2026 release of JAWS and its Page Explorer feature. By pressing Insert + Shift + E, I invoked Vispero’s AI-driven summary to “accessify” the assignment’s visual content.

The Experiment (and the “Failure”)

For the first sample, Page Explorer described the main area as “divided into two large colored panels side-by-side or stacked.” Based on this, I guessed Grid of Cards.

Incorrect. The system informed me a grid features a series of cards providing previews of more detailed content.

I tried again with the next sample. This time, I asked the AI specifically to describe the layout from a “design perspective.” It responded with details about a “white rounded rectangular card with a subtle shadow” and “prominent headings.” It sounded exactly like a Grid of Cards.

Incorrect again. The correct answer was a Z-shape layout, which encourages users to skim from left to right, then diagonally.

The Lesson Learned

This experiment was a “failure” in terms of getting the points on my assignment, but a massive success in highlighting where we are in the evolution of Assistive Technology:

  • Identification vs. Synthesis: The AI is getting incredibly good at identifying objects (buttons, shadows, panels). However, it hasn’t quite mastered the synthesis of those objects into cohesive design patterns like “Z-shape.”
  • The Subjectivity of Layout: Design patterns are often about the intended eye-path, a concept that is still a “work-in-progress” for even the most advanced generative models.

A Hopeful Future for Blind Designers

Despite the frustration of getting those “Incorrect” marks on my coursework, I’m deeply hopeful. The very fact that I can now have a “conversation” with my screen reader about the “subtle shadows” and “colored panels” of a design sample is a massive leap forward.

We are standing at the threshold of a new era. As AI models are trained more specifically on design heuristics and visual hierarchy, they will eventually move beyond simple description. They will become the “visual eyes” for blind designers, developers, and students, allowing us to not only participate in design courses but to master the visual language that has long been a barrier.

The experiment didn’t help me pass this specific assignment, but it proved that the tools are coming. We’re just a few iterations away from turning these “impossible” design hurdles into accessible milestones.

Video Demonstration

To see exactly how this played out in real-time, you can watch my screen recording below. In this video, I walk through the attempt to use JAWS Page Explorer to identify the layouts, showing both the AI’s descriptive output and the trial-and-error process of the assignment.

Not a Panacea: Why AI Browser Agents Haven’t Solved the Inaccessible Web—and What Comes Next

by

When Google launched Auto Browse for Gemini in Chrome in January 2026, a few of us in the blind and low-vision community felt a familiar surge of hope. Could this be the moment when the inaccessible web finally met its match? Could an AI that reasons about web pages—rather than merely reading their code—become the accessibility bridge we’d been waiting for? Microsoft’s Copilot Actions in Edge was already generating similar excitement. For the first time, it seemed like mainstream browser vendors were building tools with the potential to help us navigate software that had never been designed with us in mind.

The reality, as many of us have now discovered, is more complicated. Auto Browse and Copilot Actions are genuine advances—but they are not the panacea we had hoped for. Understanding why matters, both so we can use these tools wisely and so we can advocate effectively for the deeper changes our community needs.

How These Tools Work—and Why They Sometimes Don’t

Both Auto Browse and Copilot Actions belong to a new category called agentic AI browsers. Rather than simply reading out what is on a page, these tools attempt to reason about what you want to accomplish and then take action on your behalf—clicking buttons, filling in forms, navigating menus, even comparing prices across tabs.

Google’s Auto Browse uses Gemini 3, a multimodal model, running within a protected Chrome profile. It can “see” a page through a combination of the page’s underlying code and actual visual images of what the page looks like on screen. Microsoft’s Copilot in Edge takes periodic screenshots and uses those to understand and interact with the page. On a well-structured, accessible website, these approaches can be genuinely impressive.

On a good day, Gemini can select from a combobox that has no accessibility markup at all—because it can see the visual “shape” of the dropdown even when the code offers no semantic clues.

But the web we actually live on is not always well-structured. Enterprise applications like Salesforce Experience Cloud use complex architectural patterns—what developers call Shadow DOM, iframes, and dynamic rendering—that create serious obstacles for these AI tools. Shadow DOM, in particular, hides a component’s internal structure from outside scripts, which means the agent’s map of the page becomes fragmented and incomplete. When the agent tries to interact with a nested component inside such a structure, it may simply not be able to find it.

Drag-and-drop interactions present another profound challenge. A click is a discrete event: the agent identifies a target, fires a command, done. Dragging is a continuous conversation between the agent, the page, and the browser over time. The agent must hold a real-time, high-fidelity picture of the page’s geometry while issuing a rapid sequence of commands—press, move, release—in exactly the right rhythm. Most vision-based agents process a screenshot, wait one to two seconds for the AI model to interpret it, then send a command. By the time that command arrives, the drag event on the page may already have timed out. The result is the “hit-and-miss” experience many of us have encountered: sometimes it works, sometimes it doesn’t, and it’s often impossible to know which you’ll get before you try.

Security: The Wall We Keep Running Into

There is another reason these tools fall short on complex applications, and it has nothing to do with AI capability: security. Both Copilot and Auto Browse operate within the browser’s strict security model, which is designed to prevent one website from accessing or manipulating data from another.

Copilot in Edge operates in three modes—Light, Balanced, and Strict—that govern how freely it can act on a given site. In the recommended Balanced mode, it will ask for your approval on sites it doesn’t recognise, and it is outright blocked from certain sensitive interactions in enterprise applications. If a site isn’t on Microsoft’s curated trusted list, the agent may simply refuse to act, citing security concerns.

These restrictions are not arbitrary. A critical vulnerability discovered in 2026, catalogued as CVE-2026-0628, demonstrated that malicious browser extensions could hijack Gemini’s privileged interface to access a user’s camera, microphone, and local files. In response, browser vendors have tightened the controls on what their AI agents can do—particularly in authenticated enterprise sessions where the stakes of a mistake are high. The same protective walls that prevent attackers from abusing these agents also prevent the agents from helping us with the complex, authenticated workflows where we most need assistance.
The precautions taken to keep attackers out also keep our AI helpers from doing their job.

Enter Guide: A Different Approach

While the browser-native agents struggle with these constraints, a different kind of tool has been quietly demonstrating what’s possible when you step outside the browser sandbox entirely. Guide is a Windows desktop application built specifically for blind and low-vision users. Instead of working within the browser’s security model, Guide takes a screenshot of your entire computer screen and uses AI—powered by Claude—to understand what’s visible. It then acts by simulating physical mouse movements and keystrokes at the operating system level, exactly as a sighted colleague sitting at your keyboard would.

This seemingly simple difference has profound consequences. Because Guide operates at the OS level rather than inside the browser, it is not subject to the Same-Origin Policy restrictions that stop Copilot and Gemini in their tracks. There are no cross-origin security alarms triggered, no curated allow-lists to consult. If a human hand could drag a component onto a canvas in Salesforce Experience Builder, Guide can do it too—and it has been demonstrated doing exactly that.

Guide also does something that matters deeply for users who want to build their own competence: it narrates the steps it is taking. Rather than operating as an opaque black box that either succeeds or fails mysteriously, Guide shows its reasoning, which means users can learn the workflow, understand what went wrong when something fails, and even record successful interaction patterns for later reuse.

It is worth being clear about what Guide is not. It is not a general-purpose browser agent designed for everyone. It is a specialist tool, built with our specific needs in mind, for situations where conventional assistive technology runs aground on inaccessible interfaces. That focus is, in many ways, its greatest strength.

Why the Underlying Problem Remains

Guide, Auto Browse, Copilot Actions, and other agentic tools represent genuine progress. But it is worth naming honestly what none of them actually solve: the inaccessible web itself.

When a screen reader user cannot navigate a Salesforce Experience Builder page, the root cause is not a shortage of clever AI workarounds. The root cause is that the page was not designed with accessibility in mind. The Shadow DOM obscures its structure not because Shadow DOM is inherently inaccessible, but because the developers who implemented it did not expose the semantic information that assistive technologies need. The drag-and-drop interface offers no keyboard alternative because whoever built it did not consider keyboard users.
Layering an AI agent on top of a broken foundation is a workaround, not a solution. It can help in many situations—and we are grateful for any help we can get—but it introduces its own fragility. The agent’s success depends on the visual layout remaining stable, on the AI model making accurate inferences, on security policies remaining permissive enough to allow action. Any of these can change, and when they do, a workaround that worked yesterday may stop working today.

Research is increasingly clear that blind users often find it less effective to patch an inaccessible UI with an AI layer than to address the underlying semantic issues in the code. The global assistive technology market is projected to reach twelve billion dollars by 2030, and yet the fundamental problem—developers building interfaces that exclude us from the start—remains stubbornly persistent.

Reasons for Real Hope

It would be easy to read all of this as a counsel of despair, but that is not what the evidence suggests. There are genuine reasons for optimism, grounded in both technological development and regulatory change.

The Regulatory Landscape Is Shifting
The European Accessibility Act came into force in June 2025, requiring a wide range of digital products and services—including enterprise SaaS platforms—to meet accessibility standards. This is not a minor guideline; it carries legal weight that organisations cannot ignore. As companies face real accountability for inaccessible software, the economic calculus changes. Fixing the foundation becomes cheaper than defending against legal action or building ever-more-elaborate AI patches.

The Technical Path Forward Is Clear
The research community and the web standards world have identified what better AI-assisted accessibility should look like. The Accessibility Object Model—a richer, semantically meaningful representation of web pages designed specifically for assistive technologies—offers a stable foundation that could allow future AI agents to navigate complex applications far more reliably than today’s tools.

Emerging “semantic geometry” approaches map the visual elements a user can see back to the specific, interactable code nodes behind them, eliminating the coordinate-guessing that causes today’s agents to miss by a few crucial pixels. Multi-agent architectures, where a navigation specialist, an execution agent, and a supervisory agent work in concert, promise more robust handling of complex multi-step tasks.

AI as a Last Resort, Not a First Line

Perhaps most importantly, the accessibility community and technologists are beginning to articulate a clearer vision: accessibility designed in from the start, with agentic AI reserved for the small number of genuinely intractable cases where no amount of good design can fully bridge the gap.

This vision has the right shape. It says: we will build the web so that blind and low-vision users can navigate it independently, with their existing assistive technologies, without needing AI intervention for every task. And for the edge cases—legacy systems that cannot be rebuilt, proprietary enterprise software with decades of accumulated inaccessibility, niche tools that will never attract enough attention to be fixed—we will have capable, transparent, OS-level AI assistants like Guide ready to step in.

Accessibility by design. AI as a safety net. That is a future worth working toward.

The supplementary tools we have today—including Auto Browse, Copilot Actions, and Guide—are imperfect instruments for an imperfect web. They will sometimes help us do things that were previously impossible, and they will sometimes frustrate us by failing at what seems like should be simple. Using them wisely means understanding their limitations and knowing which tool to reach for in which situation.

But the story does not end here. The regulatory momentum, the technical research, and the growing awareness among designers and developers that accessibility is not optional are all pointing in the right direction. A web that is built for everyone, with AI available for the hard cases, is not a utopian fantasy. It is an achievable goal, and we are, slowly, getting closer.

Sources

All sources used in the Blind Access Journal article “Not a Panacea: Why AI Browser Agents Haven’t Solved the Inaccessible Web—and What Comes Next” (March 28, 2026).

Primary research document:
Technical Analysis of Agentic AI Efficacy in Navigating Complex Web Architectures for Accessibility Remediation

AI Browser Agents – Auto Browse and Copilot Actions

Security and Vulnerabilities

Salesforce and Complex Web Architecture

Guide – Specialist Accessibility Application

AI Agent Architecture and Failure Modes

Accessibility Research and Standards

Regulatory and Market Context

Alternative Agentic Tools

Fifty Years of Hard-Won Rights Are on the Line: The Fight to Save Section 504

by

Published in support of the National Federation of the Blind‘s March 2026 call to action.

There is a lawsuit moving quietly through the American legal system right now that could undo five decades of civil rights progress for tens of millions of disabled Americans. It is called Texas v. Kennedy, and if you haven’t heard of it yet, that is exactly the problem.

The National Federation of the Blind (NFB) is sounding the alarm — and asking all of us, disabled or not, to pick up the phone and write the email. Here is why this matters, what is at stake, and exactly what you can do about it today.

The Law That Changed Everything

In 1973, Congress passed Section 504 of the Rehabilitation Act — the first federal law in American history to prohibit discrimination on the basis of disability. Its principle was simple and radical: no person with a disability could be excluded from, denied the benefits of, or discriminated against in any program or activity receiving federal financial assistance.

In the decades since, Section 504 has meant that a blind child has the legal right to accessible materials in a federally funded school. That a wheelchair user cannot be turned away from a government building. That a disabled employee at a federally funded organization has recourse against discrimination. It was the direct legal precursor to the Americans with Disabilities Act of 1990 — one of the most important civil rights laws ever enacted in this country.

Section 504 is not a technicality. It is the legal backbone of disabled life in America.

What Texas v. Kennedy Threatens

The Texas v. Kennedy lawsuit, filed by a coalition of nine states led by Texas, challenges the federal government’s authority to enforce Section 504 as currently written and applied. According to the NFB’s official call to action issued in March 2026, the lawsuit “risks weakening or eliminating key protections that blind people in the United States rely on every day,” endangering access to “education, employment, public services, and other essential opportunities.” [National Federation of the Blind, March 2026]

If the plaintiffs prevail, the federal government’s ability to require accessibility accommodations, enforce non-discrimination standards, and hold federally funded institutions accountable could be dramatically curtailed. Schools could reduce or eliminate accommodations for disabled students. Employers at federally funded institutions could discriminate against disabled workers. Public services millions of people depend upon every day could become legally inaccessible without meaningful federal recourse.

The implications reach beyond Section 504 itself. The legal theory at the heart of this case — that federal authority to attach civil rights conditions to federal funding is constitutionally limited — could set a precedent that weakens enforcement of other civil rights statutes as well. This is not simply a disability rights issue. It is a civil rights issue for every American.

The Nine States Behind This Lawsuit

The following nine states are currently party to Texas v. Kennedy:

  • Texas
  • Alaska
  • Florida
  • Indiana
  • Kansas
  • Louisiana
  • Missouri
  • Montana
  • South Dakota

The NFB has already organized nine of its state affiliates to write directly to their respective attorneys general urging withdrawal from the case. [NFB Letter from Nine Affiliates, March 2026] Now it is time for the broader public to join that effort.

Why Your Letter or Call Can Actually Change the Outcome

It is easy to feel that a single email cannot change the course of a federal lawsuit. But that thinking misunderstands how political and legal pressure actually works.

Attorneys general and governors are elected officials. They are acutely sensitive to constituent opinion, organized public pressure, and the reputational cost of being seen as attacking the civil rights of disabled citizens. When thousands of letters arrive, when inboxes fill and phone lines ring, when local and national media begin covering a public outcry, political calculations change. Officials who joined this lawsuit made a choice. Sustained constituent pressure helps them make a different one.

Beyond the direct political impact, a documented record of public opposition shapes how officials talk about the case publicly, how they respond to press inquiries, and whether withdrawal begins to look like the politically prudent path. The history of American civil rights is full of moments where ordinary people writing ordinary letters tipped the balance. This is one of those moments.

If You Live in One of the Nine States: Contact Your Officials Now

If you are a resident of any of the nine states party to this lawsuit, your message carries the most direct political weight. Please contact your state attorney general and urge them to withdraw your state from Texas v. Kennedy immediately.

Here are the direct contact emails provided by the NFB [NFB Call to Action, March 2026]:

When you call or write, here is what to say (adapted from the NFB’s suggested message [NFB, March 2026]):

“Hello, my name is [Your Name], and I am a constituent. I am writing to urge you to withdraw our state from the Texas v. Kennedy lawsuit. This lawsuit threatens Section 504 of the Rehabilitation Act — a critical civil rights protection that ensures equal access for blind and disabled Americans in education, employment, and public life. Weakening Section 504 would cause real, lasting harm to real people in our state. Please take immediate action to remove us from this harmful lawsuit. Thank you.”

Make it personal if you can. Tell them about a family member who depends on accessible education. A friend who relies on workplace accommodations. A neighbor whose independence would be threatened. Officials remember letters that put a human face on the law.

If You Live Outside the Nine States: Contact Texas Directly

Texas is the lead plaintiff and the political engine driving this lawsuit. Even if you are not a Texan, contacting the Texas Attorney General’s office sends a clear signal that this case has drawn national attention and national opposition.

Texas Attorney General: kenneth.paxton@oag.texas.gov

Tell them that people across the country are watching this case, and that the disability community — and everyone who supports civil rights — expects better.

Share This. Amplify This. Don’t Wait.

The NFB’s call to action is clear: “Your voice is critical. Every message sent and every phone call made helps demonstrate that blind Americans will not stand by while our civil rights are threatened.” [NFB, March 2026]

But this fight belongs to all of us. Forward this article. Post it. Print it out for someone who needs it. Bring it up at your church, your school, your community organization. The officials who signed their states onto this lawsuit are counting on public silence. Let’s make sure they don’t get it.

Section 504 is a promise America made to its disabled citizens fifty years ago. Let’s hold the line together.

Sources & Further Reading

For more information, contact the National Federation of the Blind at 410-659-9314 or visit nfb.org.

Slack Accessibility Bug in Simplified Layout Mode Confirmed Fixed

by

Great news for screen reader users who rely on Slack’s Simplified Layout Mode: the accessibility regression we reported last month has been resolved.

In our February 14 article, we documented a critical, task-blocking bug introduced in Slack version 4.47.69 in which the Activity tab became completely inaccessible to JAWS users when Simplified Layout Mode was enabled. Focus was trapped on toolbar elements, and the screen reader would report only “Loading” or “Blank” rather than the expected list of notifications, mentions, and direct messages.

We are pleased to confirm that the bug has been fixed.

Confirmation from Slack

On March 12, a member of the Slack team reached out by email with the following update:

“The bug was fixed and pushed to production on the 4th of March. That’s an impressive turnaround time for such detailed and helpful bug reports! Our team also mentioned the screen recording made a huge difference in getting it resolved so quickly.”

We want to express our sincere appreciation to the Slack accessibility and product teams. Throughout this process, Slack worked diligently with members of the online disability community, asking for feedback and providing timely updates. That kind of responsive, collaborative engagement is exactly what the assistive technology community needs from software developers, and it made a real difference.

What We Learned About the Bug

In early March, additional details emerged that shed more light on the root cause. The screen-reader accessibility failure in the Activity tab occurred specifically when two conditions were met simultaneously: Simplified Layout Mode was enabled and the Slack window was not maximized. In our own testing, we were able to confirm this — when Slack was maximized, the bug was not observed.

This is a useful piece of information for anyone who may have been experiencing the issue and wondered why it appeared intermittently. If you had Slack in a smaller or restored window, the bug would surface; if you had it maximized, it would not.

A Reminder for Screen Reader Users

This bug serves as a timely reminder of a best practice that benefits all screen reader users across virtually any application: in general, it is a good idea to keep the currently active and focused window — the one where you are currently working — maximized or in full-screen mode at all times.

Here’s how to keep it maxed.

If you’re not sure whether or not the current window is maximized, follow these steps to make it so:

  1. Press alt+spacebar to open the System Menu for the focused application window. “Restore”, “System Menu” or something similar will be announced.
  2. Press the letter x to maximize the window. The window’s title will be announced and you’re brought right back to the task you were working on before maximizing.

Many accessibility-related rendering and focus issues are window-size dependent, and maximizing your working window can work around an entire category of potential problems before they get in the way of achieving your hopes and dreams. It’s a simple habit that can meaningfully improve your day-to-day experience with any application.

Next Steps

If you are running a version of Slack released on or after March 4, 2026, you should have the fix. If you are still experiencing issues navigating the Activity tab with a screen reader and Simplified Layout Mode enabled, we encourage you to reach out to Slack support right away.

Thank you to everyone in the community who tested, reported, and helped document this issue. Your participation — and especially those screen recordings — made this resolution possible.