assistive technology

Pro Tip: Fixing a Disappearing Interface in FastSM for Windows

by

FastSM is a popular accessible client for Bluesky and Mastodon, and for the most part it works beautifully with screen readers like JAWS and NVDA. However, some users have encountered a frustrating issue: shortly after FastSM starts, performing any action — such as trying to create a new post — causes the entire user interface to vanish. When this happens, the app is still running in the background but is completely unresponsive, and the usual fix of pressing Control+Windows+W does not bring it back. The only way out seems to be manually ending the FastSM process in Task Manager.

If this has happened to you, don’t worry. There are three solutions below, starting with the simplest and working up to a more thorough reset. Try them in order and stop as soon as one works.

Solution 1: Restore the Window with a Keyboard Shortcut

Before trying anything else, press Control+Windows+W. This shortcut is designed to restore FastSM’s standard visible interface if it has been accidentally hidden. If this brings your interface back, you’re done! If it doesn’t work, move on to Solution 2.

Solution 2: Turn Off the Invisible Interface in Settings

FastSM has a feature called the Invisible Interface, which, if accidentally enabled, can cause the window to disappear when you interact with the app. Here’s how to check and disable it:

  1. Start FastSM and, before doing anything else, press Control+Comma to open Global Options.
  2. Press Control+Tab five times to navigate to the Invisible Interface tab.
  3. Listen for whether “Enable Invisible Interface” is announced as checked. If it is checked, press Spacebar to uncheck it.
  4. Press Enter to save your changes and close the dialog.

FastSM should now behave normally. If the problem persists, Solution 3 below will give you a fresh start.

Solution 3: Reset FastSM by Removing Its Settings Folder

This is the most thorough fix. It completely removes FastSM’s stored settings so that the app starts fresh, just as it did the first time you installed it. Important: after completing these steps, you will need to sign back into all of your Bluesky and Mastodon accounts. If you are not sure whether you have administrator access to your computer, please ask your IT department or another trusted person for help before proceeding.

These steps have been tested on Windows 11 Workstation (version 25H2) with the latest versions of both JAWS and NVDA as of April 2026.

Step 1: Close FastSM Using Task Manager

  1. Press Control+Shift+Escape to open Task Manager.
  2. Press F repeatedly until you hear something like “FastSM collapsed level 1.”
  3. Press Alt+E to end the FastSM process.
  4. Press Alt+F4 to close Task Manager.

Step 2: Open Your Home Folder in File Explorer

  1. Press Windows+R to open the Run dialog.
  2. Type a single period (.) and press Enter. This opens your personal home folder in File Explorer.

Step 3: Show Hidden Files and Folders

  1. Press Alt by itself to focus the File Explorer ribbon.
  2. Press Right Arrow until you hear “View button collapsed” and press Enter to open the menu.
  3. Press Up Arrow until you hear “Show collapsed,” then press Enter to open the submenu.
  4. Press Up Arrow until you hear “Hidden Items.”
  5. If “Hidden Items” is not announced as checked, press Spacebar to enable it. If it is already checked, press Escape to leave this menu without making changes.

Step 4: Switch to Details View for Easier Navigation

  1. Press Alt by itself, then press Right Arrow five times, then press Enter to reopen the View menu.
  2. Press Down Arrow until you hear “Details,” then press Enter. Note: even if “checked” is announced, pressing Enter here will not change anything — it simply confirms the Details view.

Step 5: Navigate to and Delete the FastSM Settings Folder

  1. In the file list, press Down Arrow until you hear “AppData,” then press Enter to open it.
  2. Press Down Arrow until you hear “Roaming,” then press Enter to open it.
  3. Press Down Arrow until you hear “FastSM,” then press Delete to remove the folder.
  4. If a dialog appears asking for permission, press Tab until you hear “Continue” or “Yes,” then press Enter to confirm.

Step 6: Restart FastSM and Sign Back In

  1. Press Windows+D to go to the desktop.
  2. Press F until you hear “FastSM,” then press Enter to launch the app.
  3. FastSM will start as if it has been installed for the first time. Sign back into your Bluesky and Mastodon accounts as you did during the original setup.

Wrapping Up

A disappearing interface can be alarming, but as you’ve seen, there are reliable ways to get FastSM back on track without losing access to your social feeds for long. In most cases, the quick keyboard shortcut or a single settings change in Global Options will solve the problem in under a minute. The full reset, while a bit more involved, is a dependable last resort that leaves you with a clean, working installation.

FastSM continues to be one of the most screen-reader-friendly ways to enjoy Bluesky and Mastodon on Windows, and hopefully this guide helps you spend less time troubleshooting and more time connecting with your communities.

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

The Guitarist Who Teaches the World to Navigate the Screen

by

There’s a particular kind of patience that only musicians develop — the ability to sit with a student through a hundred failed attempts at a chord, knowing that the hundred-and-first try will produce something beautiful. Tony Gebhard has been cultivating that patience since he was seven years old, when he first picked up a guitar and started to sing.

Decades later, he’s applying it to a very different kind of instruction.

Tony is the creator of NVDA Coach, a free add-on for the NVDA screen reader that is quietly changing how blind people take their first steps into independent digital life. With 35 structured lessons covering everything from basic navigation to reading and customization, the tool is designed for users who aren’t ready — or willing — to sit down with a trainer, wade through a dense manual, or admit they need help.

“Think about someone like Sally,” Tony says, describing a hypothetical but achingly familiar user: a 62-year-old woman who has recently lost her sight and needs to check her bank balance, send an email to her daughter, or order something online. “She doesn’t need a classroom. She needs something patient. Something that won’t rush her.”

That sensitivity to the learner’s emotional experience isn’t accidental. Tony has spent seven years as an assistive technology specialist, working for a non-profit in Anchorage, Alaska, coordinating transitions for youth with disabilities, and eventually landing a role with a state government agency in Oregon. A graduate of the Assistive Technology Instructor Career Training Program from World Services for the Blind in Little Rock, Arkansas, he holds and recommends fellow professionals pursue Certified Assistive Technology Instructional Specialist for Individuals with Visual Impairments (CATIS) certification.

But long before any of those credentials, there was the music.

Tony started writing original songs at age 12. Today, he has published 12 albums — primarily in metal and progressive genres — available on Spotify, Apple Music, and Amazon. His music, like his teaching, reflects an appetite for complexity and a refusal to take the obvious path. Progressive metal is not a genre for the faint-hearted; it rewards listeners who are willing to be challenged, who trust that the dissonance will eventually resolve into something extraordinary.

He brings that same philosophy to assistive technology. NVDA Coach doesn’t dumb things down. It meets users where they are.

The add-on is now available on Tony’s GitHub repository. Version 1.0.0 marked its official debut, and Tony is already planning ahead: version 1.2 or 1.3 will introduce language translations, extending the tool’s reach to users in developing regions around the world where access to screen reader training is scarce or nonexistent.

“This isn’t just about the United States,” Tony says. “There are people everywhere who need this.”

From a seven-year-old learning his first guitar chord in a living room somewhere, to a 62-year-old learning to navigate a screen reader alone in her kitchen — Tony understands that the best teachers don’t just transfer knowledge. They make people believe they can do it themselves.

Now at Version 1.2.0 as of this publication date, NVDA Coach is available for download from Tony’s GitHub page.

Not yet convinced? Play the demo video and see for yourself why the connected, online blind community is all abuzz about NVDA Coach!

Beyond the Screen Reader: Can Gemini’s AI Agent “Accessify” the Web?

by

AI as an Accessibility Bridge: Testing Gemini’s Auto Browse

For blind and low-vision users, the modern web is a minefield of good intentions gone wrong. Developers build visually polished interfaces — date pickers, multi-step dialogs, dynamic dropdowns — but the underlying code often fails to communicate with assistive technology. Screen readers like JAWS and NVDA rely on semantic structure and proper focus management to guide users through a page. When that structure breaks down, so does access.

That gap is exactly what I set out to probe in a recent demonstration of Auto Browse, an agentic AI feature built into the Gemini for Chrome side panel. My test case was deliberately unglamorous: a Salesforce “Add Work” form on the Trailblazer platform, featuring a date picker that routinely defeats standard keyboard navigation. The question wasn’t whether the interface looked functional. It was whether an AI agent could step in and make it work.

The Problem with Date Pickers (and Why It Matters)

Custom date pickers represent one of the most persistent accessibility failures on the web. Unlike native HTML <input type="date"> elements, which browsers render with built-in keyboard support, custom-built widgets frequently rely on mouse interaction, non-semantic markup, or JavaScript behavior that strips focus away from the user mid-task.

In my demo, the Salesforce dialog presents a “start date” selector with separate Month and Year dropdowns. For a sighted mouse user, this is trivial. For a screen reader user navigating by keyboard, it becomes a trap — the list receives focus but refuses to respond to arrow keys or selection commands, leaving the user stuck with no clear path forward.

This is not a niche problem. Date pickers appear in job applications, medical intake forms, financial dashboards, and e-commerce checkouts. When they break, they don’t just create friction — they create exclusion.

Letting the AI Take the Wheel

My approach was straightforward: rather than fighting the inaccessible interface, I delegated the task entirely. With the Gemini side panel open (activated via Alt+G), I issued a plain-language command: “Please set the start date to December 2004.”

What followed was notable not just for what the AI did, but for how it communicated while doing it. Auto Browse autonomously interacted with the form elements — opening the Year dropdown, scrolling to 2004, selecting it — while simultaneously providing real-time status updates in the side panel. Critically, those updates (“Updating the start year to 2004”) were announced by the screen reader, keeping me informed throughout the process without requiring me to shift focus manually.

A “Take Over Task” button remained visible at the top of the browser at all times, ensuring that AI autonomy didn’t come at the cost of user control — a design principle that will resonate with anyone familiar with WCAG’s emphasis on predictability and user agency.

Where It Still Falls Short

I want to be candid about the rough edges, because that honesty is part of what makes this worth examining closely.

During the interaction, the dialog closed unexpectedly at one point, requiring a page reload before I could restart the task. For sighted users, this is a minor inconvenience. For screen reader users, an unexpected context shift — a dialog closing, focus jumping to an unrelated part of the DOM, a dynamic content update that goes unannounced — can be deeply disorienting. Recovery depends on knowing where you are, and that knowledge is precisely what gets lost.

This points to a fundamental challenge for agentic AI in accessibility contexts: it isn’t enough to complete the task correctly; the AI must also maintain a coherent focus environment throughout. If a script refreshes a page region mid-task, the virtual cursor needs to land somewhere intentional. If a dialog closes, the user needs to know what replaced it. These aren’t edge cases — they’re the everyday texture of dynamic web applications, and they’ll need to be handled reliably before tools like Auto Browse can be genuinely depended upon.

A Glimpse of What’s Possible

Despite those caveats, I came away from this demonstration genuinely encouraged. Gemini successfully populated both fields with the correct date, confirmed by the screen reader’s final readout. More importantly, it did so through natural language — no custom scripts, no manual DOM inspection, no workarounds requiring technical knowledge that most users don’t have and shouldn’t need.

The implications extend well beyond date pickers. Agentic AI that can interpret intent and act on a user’s behalf has the potential to make complex web interfaces navigable for people who have been effectively locked out of them. Not by fixing the underlying code — though that remains the gold standard — but by providing a capable, responsive intermediary that can bridge the gap in real time.

The web has always required remediation to be accessible. What’s new is who, or what, might be doing the remediating.

Visual Descriptions (Alt-Text for Video Keyframes)

To ensure this post is as accessible as the technology it discusses, here are descriptions of the critical visual moments in the video:

Frame 1: The Accessibility Barrier
A screenshot of the Salesforce “Add Work” dialog box. The “Month” and “Year” drop-down menus are highlighted, showing the visual interface that I am unable to navigate using standard screen reader commands.
Frame 2: The Gemini Interface
The Chrome browser split-screen view. On the left is the Trailblazer site; on the right is the Gemini side panel where I have typed my request. The AI is showing a progress spinner labeled “Task started.”
Frame 3: Agentic Interaction
The video shows the “Year” drop-down menu on the webpage opening and scrolling automatically as the Gemini agent selects “2004” without any manual mouse movement or keyboard input from the user.
Frame 4: Success Confirmation
The final state of the form showing “December” and “2004” successfully populated in the fields. The Gemini side panel displays a “Task done” message with a summary of the actions performed.

I am a CPWA-certified digital accessibility specialist. When I’m not testing the latest in AI or keeping up with my family, you can find me on the amateur radio bands under the call sign NU7I.

One Week with NVDA: A JAWS User’s Immersion Journey

by

What started as a seven-day experiment ended with a new primary screen reader.

I’ll be honest: I didn’t expect this to go the way it did. On February 14th, 2026, I set myself a challenge — use NVDA exclusively on my personal computer for one full week, switching back to JAWS only if my work required it. I’ve been a longtime JAWS user, and NVDA has always been on my radar as the powerful, free, open-source alternative. But radar is different from reality. So I dove in.

One week later — and several days beyond that — I’m still running NVDA. It has become my primary Windows screen reader. I won’t be abandoning JAWS entirely; both tools have their place. But if you’ve been on the fence about giving NVDA a serious try, read on. Here’s everything that happened.

Day 1 (February 14): First Impressions and the Punctuation Problem

The very first thing that tripped me up was punctuation. NVDA defaults to “some” punctuation, while I was accustomed to “most” in JAWS. The practical effect: symbols like the underscore were being silently skipped. I switched to “most” punctuation right away, and that helped — but it opened its own can of worms.

In “most” mode, NVDA announces the underscore as “line.” I found that maddening. The colon inside timestamps (insert+F12 for the time) was also being spoken aloud, which felt odd. These were small things, but they added up quickly.

I also explored the NVDA Addon Store. It’s a great concept, but I found the execution a bit rough — many addons lack solid documentation, and reading user reviews means navigating away to an external website. There’s room to grow here.

One more early grievance: common commands like Control+C and Control+S are completely silent in NVDA. You press copy or save and hear… nothing. The option to speak command keys does exist, but it makes everything chatty — tab, arrows, all of it. That’s not what I wanted either.

Day 2 (February 15): Muscle Memory Wars and Customization Overload

Day two was the most turbulent. My JAWS muscle memory fought me at every turn, and I spent a significant portion of the day not doing productive work but rather reconfiguring NVDA to survive.

Browse Mode and Focus Mode were a constant source of confusion. In JAWS, Semi Auto Forms Mode handles a lot of this context-switching behind the scenes. With NVDA, I found myself stuck in the wrong mode repeatedly. A simple example: after submitting a prompt to Gemini and hearing its reply, I pressed H to navigate to the heading where the response started. NVDA just said “h” and sat there. I was still in Focus Mode. Insert+Space toggled Browse Mode on and then everything worked — but I had to consciously remember to do that. This will likely get easier with time, but on day two, it was genuinely frustrating.

I remapped a fistful of commands to save my sanity. The NVDA find command in Browse Mode is Control+NVDA+F — not Control+F — which felt deeply wrong. I added Control+F, F3, and Shift+F3 under Preferences > Input Gestures. I also kept repeatedly bumping into Insert+Q being the command to exit NVDA rather than announcing the active application, which nearly gave me a heart attack the first time it happened. I enabled exit confirmation in Preferences > General, then later reassigned Insert+Q to announce the focused app and moved the exit command to Insert+F4.

The underscore-as-“line” issue got its resolution today. The fix wasn’t in NVDA’s speech dictionaries as I first expected — it was in Preferences > Punctuation/Pronunciation. Problem solved. I also tackled the exclamation mark, which sits in the “all” punctuation tier rather than “most.” I mapped it to announce as “bang” when it appears mid-sentence.

There was also a frustrating addon conflict: the NVDA+Shift+V keystroke, officially assigned to announce an app’s version number, was instead being intercepted by the Vision Assistant Pro addon to open its command layer. Addon keystrokes can silently override core NVDA functionality — something worth knowing. I ended up assigning Control+NVDA+V to get version info.

One gap I noticed that NVDA doesn’t yet fill: quickly reading the current page’s URL without shifting focus to the address bar. JAWS handles this with Insert+A. NVDA doesn’t have an equivalent. Alt+D works, but it moves focus, which isn’t always what I want.

Day 3 (February 16): The Good, The Annoying, and a Genuine Win

By day three — President’s Day — I was settling into something like a rhythm, though NVDA was still throwing surprises at me.

One thing I couldn’t crack was typing echo. In JAWS, I run character-level echo at a much higher speech rate than everything else. This gives me fast, confident confirmation of each keystroke without slowing down general speech. NVDA doesn’t appear to support different speech rates per context, so typed characters come through at the same rate as everything else. I know I can’t be the only person who relies on this, so I kept digging — but no solution yet.

I also noticed a recurring issue: NVDA going silent after focus changes. Closing Excel or Word and returning to File Explorer? Silence. Switching browser tabs with Control+Tab? Sometimes silence. This felt like potential bug territory.

PDFs were another pain point. I work with many poorly tagged PDFs, and NVDA with Adobe Reader exposes every formatting flaw without mercy. JAWS has historically done more smoothing and pre-processing before those errors reach the user. I’m withholding final judgment here — there are third-party PDF tools that work well with NVDA, and I planned to test them.

I experimented briefly with turning off automatic say-all on page load to reduce repetitive speech on websites. Bad idea. After toggling an action, nothing was announced — I had to manually navigate just to figure out where I had ended up. I turned it back on immediately.

The genuine win of the day: the Vision Assistant Pro addon. While working on a freelance project that required a visual description of a web page’s layout, I pressed NVDA+Alt+V then O for an on-screen description. Within seconds I had exactly what I needed. A follow-up question was answered just as quickly. Cross-checking with other tools confirmed the accuracy. This was an impressive moment and a real argument for NVDA’s addon ecosystem.

Day 4 (February 17): The 32-Bit Revelation and Eloquence Arrives

I learned something on day four that genuinely surprised me: NVDA 2025.3.3, the current stable release, is 32-bit. I had assumed for years that I was running a 64-bit screen reader. This discovery came about through an unexpected path.

I came across a link to a 64-bit version of the Eloquence speech synthesizer built for NVDA. Excited, I installed it and restarted — only to find NVDA using Windows OneCore voices with no trace of Eloquence. After posting about it on Mastodon, the community quickly pointed out the 32-bit issue. The 64-bit Eloquence addon requires a 64-bit NVDA, which only exists in the 2026 beta builds. I grabbed the beta, installed everything, and was finally running Eloquence on NVDA. The 64-bit upgrade is coming in the official 2026.1 release — well worth watching for.

I also continued searching for an NVDA equivalent to JAWS’s Shift+Insert+F1, which gives a detailed browser-level view of an element’s tags, attributes, roles, and IDs. This is invaluable for accessibility work. I hadn’t found a satisfying answer by end of day.

Day 5 (February 18): Discovering NVDA in Microsoft Word

I don’t often think of Browse Mode as a Word feature, so I was pleasantly surprised to learn — after reading some documentation — that NVDA supports a version of it in Word, allowing quick navigation by headings using the H key. This made my document work much more manageable.

I also received another update to 64-bit Eloquence, which fixed bugs I hadn’t even noticed. As for the work computer, I decided against installing the NVDA beta there — my employer deserves results from the stable release. That upgrade will wait for the official 2026.1 launch.

Day 6 (February 19): The Quiet Day

Day six was uneventful in the best possible way. I used my computer heavily and NVDA just worked. No major incidents, no emergency remappings. I noticed I was reaching for JAWS less and less in my thoughts. That felt significant.

Day 7 (February 20): Amateur Radio and a Happy Ending

The final day of the official challenge coincided with the start of the ARRL International DX CW (Morse Code) contest — one of the bigger amateur radio events of the year. I was curious how N3FJP’s contest logging software would hold up with NVDA, since this is specialized, legacy-adjacent software that doesn’t rely on standard accessibility APIs.

The answer: it worked great — and actually felt snappier than with JAWS. The one wrinkle was reviewing the call log. The standard screen review commands on the numpad didn’t yield useful information at first. The solution was object navigation. By pressing NVDA+Numpad 8 to climb to the parent object (“call window”), I found that each column in the log is its own object. Navigating with NVDA+Numpad 4, 5, and 6 moved between objects at the same level, announcing “Rec Window,” “PWR Window,” “Country Window,” “Call Window,” and so on. From there, Numpad 9 and 7 moved through the log in reverse chronological order. Once I understood the structure, it worked beautifully.

My two radio control apps — JJRadio and Kenwood’s ARCP software — also worked flawlessly. Just when I was expecting NVDA to hit its limits, it didn’t.

What NVDA Does Really Well

After a week of intensive use, here’s what impressed me most:

  • Speed and responsiveness. NVDA frequently felt faster than JAWS, especially in applications like the N3FJP logging software.
  • Deep customizability. The Input Gestures system makes it relatively easy to remap commands. Preferences > Punctuation/Pronunciation gives granular control.
  • The addon ecosystem. Despite rough edges, the Vision Assistant Pro addon alone demonstrated real power. The 64-bit Eloquence support is also a significant upgrade.
  • Object navigation. Once I understood NVDA’s object model, navigating legacy and non-standard interfaces became genuinely manageable.
  • Cost. NVDA is free, actively developed, and open source. The value proposition is extraordinary.

Where NVDA Still Has Room to Grow

  • Silent focus changes. NVDA going quiet after closing apps or switching tabs is disorienting and may be a bug worth filing.
  • PDF handling. Poorly tagged PDFs hit differently with NVDA than with JAWS, which smooths many errors before they reach the user.
  • Typing echo speech rate. The inability to set a faster speech rate specifically for typed characters is a real productivity gap for fast typists.
  • Element inspection. JAWS’s Shift+Insert+F1 for examining element attributes has no obvious NVDA equivalent, which matters for accessibility work when I just need to start with a quick-and-dirty answer before digging deeper into the code.
  • URL reporting without focus change. A read-only way to hear the current page address — without moving focus to the address bar — is missing.
  • Addon documentation and conflict resolution. Keystroke conflicts between addons and core NVDA aren’t surfaced clearly enough.

The Verdict: One Week Became the New Normal

I went in expecting to survive a week and then gratefully return to JAWS. Instead, I’m writing this article as an NVDA user. The first two days were genuinely hard — partly NVDA’s rough edges, partly years of JAWS muscle memory fighting back. But by day six, NVDA was simply humming along, and I wasn’t thinking about JAWS at all.

For experienced JAWS users considering a serious NVDA trial, my main advice is this: budget real time for reconfiguration in the first two days. The defaults won’t feel right. But the tools to make NVDA feel right are mostly there — they just require some digging. Preferences > Punctuation/Pronunciation and Input Gestures will be your best friends.

JAWS isn’t going anywhere in my toolkit. For professional accessibility auditing, PDF work, and certain specialized contexts, it remains the gold standard. But for day-to-day use on my personal computer? NVDA has earned the top spot.

The 2026.1 release — bringing official 64-bit support — is going to be a milestone worth watching. If you’ve been waiting for a good moment to give NVDA a real chance, that moment is here, now.

Sources

This article is primarily a firsthand account based on my direct experience. The following resources document or corroborate the specific factual claims made in the article.

  • NV Access: NVDA 2025.3.3 Released — Official release announcement for the stable version of NVDA tested throughout this article, confirming it is a 32-bit build.
  • NV Access: In-Process, 10th February 2026 — NV Access’s own blog post confirming that NVDA 2026.1 is the first 64-bit release, and discussing the scope of that transition.
  • NV Access: NVDA 2026.1 Beta 3 Available for Testing — The beta release announcement for the 64-bit version of NVDA referenced in the Day 4 entry.
  • NVDA 2025.3.3 User Guide — The official NVDA documentation covering Browse Mode, Focus Mode, Input Gestures, object navigation, Punctuation/Pronunciation settings, and the Add-on Store — all features discussed throughout the article.
  • Switching from JAWS to NVDA — A community-maintained transition guide for experienced JAWS users switching to the free, open-source NVDA screen reader, covering key differences in keyboard commands, terminology, cursors, navigation, synthesizers, settings, add-ons, and common troubleshooting scenarios.
  • N3FJP’s ARRL International DX Contest Log — The official page for the N3FJP contest logging software tested with NVDA on Day 7.
  • ARRL International DX Contest — The American Radio Relay League’s official page for the ARRL International DX CW contest referenced in the Day 7 entry.

Using Apple’s Built-In Accessibility Features to Reduce Screen Exposure During Severe Headaches

by

Summary

Some people experience severe headaches or migraines that make screen use difficult—especially when light sensitivity (photophobia) and flicker or refresh effects are major triggers. While display adjustments can help, there are days when the most effective strategy is to reduce visual reliance as much as possible.

If you use an iPhone and Mac, Apple includes several built-in accessibility tools that can support a “low-screen” or even “no-screen” workflow—particularly for everyday tasks like reading and replying to email.

This article focuses on the built-in Mail app and outlines a practical approach using:
VoiceOver (screen reader),
Voice Control (hands-free voice operation),
and Dictation (speech-to-text composition).

Why VoiceOver and Voice Control can help when light and flicker are triggers

VoiceOver reads on-screen content aloud and provides a structured navigation model that does not require visually scanning the interface. Instead of looking for buttons or reading text, users move through content sequentially and receive spoken feedback.

Voice Control complements this by allowing users to operate their device through spoken commands. Actions such as opening Mail, scrolling, replying, and sending messages can often be completed without touching or looking closely at the screen.

For people whose primary headache triggers include light sensitivity and flicker, combining these tools can significantly reduce both the duration and intensity of screen exposure.

iPhone: Building a low-screen Mail workflow on iOS

Turn on VoiceOver

VoiceOver can be enabled from Settings > Accessibility > VoiceOver. Apple provides a built-in practice experience that introduces the gesture model and basic navigation concepts.

Learn a minimal set of VoiceOver gestures

It is not necessary to learn every gesture. Starting with a small core set allows users to begin working quickly and add complexity later.

  • Swipe right: move to the next item.
  • Swipe left: move to the previous item.
  • Double-tap: activate the selected item.
  • Two-finger swipe up: read the entire screen from the top.
  • Two-finger tap: pause or resume speech.
  • Four-finger tap near the top: jump to the first item.
  • Four-finger tap near the bottom: jump to the last item.

Use Screen Curtain to eliminate display light

When VoiceOver is enabled, the screen itself can be turned off while the device remains fully usable. This feature, called Screen Curtain, allows users to rely entirely on audio output while avoiding light exposure.

  • Three-finger triple-tap: toggle Screen Curtain on or off.
  • If both Zoom and VoiceOver are enabled, a three-finger quadruple-tap may be required.

Adding Voice Control for hands-free interaction

Voice Control allows users to interact with on-screen elements using spoken commands. This can be particularly helpful when precise touch input or visual targeting is uncomfortable.

Common Voice Control commands

  • Open Mail
  • Scroll down / Scroll up
  • Go home
  • Show names (labels interface elements)
  • Show numbers (adds numbered overlays)

When an on-screen control is difficult to activate, VoiceOver can be used to identify the control’s name, and Voice Control can then activate it using that spoken label.

Reading and replying to Mail on iPhone using audio

  1. Open the Mail app using Voice Control or VoiceOver navigation.
  2. Move through the message list using swipe left and swipe right.
  3. Open a message with a double-tap.
  4. Listen to the message using a two-finger swipe up.
  5. Reply using Voice Control or VoiceOver navigation.
  6. Compose the reply using Dictation, speaking punctuation as needed.
  7. Send the message using a spoken command or VoiceOver activation.
  8. Enable Screen Curtain when light sensitivity is a concern.

Mac: Reducing visual load with VoiceOver

On macOS, VoiceOver enables spoken feedback and keyboard-based navigation across apps, including Mail. This allows users to work with less reliance on visual scanning.

Turn VoiceOver on or off

  • Command + F5: toggle VoiceOver.

Core VoiceOver navigation concepts

The VoiceOver cursor moves independently of the system focus and determines what is spoken. Navigation is performed using the VoiceOver modifier keys (often Control + Option).

  • VO + Arrow keys: move between items.

Quick Nav for streamlined navigation

Quick Nav can simplify navigation by allowing arrow keys or single keys to move through content without holding modifier keys. This can be especially useful once the basics feel comfortable.

  • VO + Q: toggle single-key Quick Nav.
  • VO + Shift + Q: toggle arrow-key Quick Nav.

Pacing and learning considerations

When screen exposure can trigger symptoms quickly, it helps to approach learning incrementally.

  • Practice in short sessions (5–10 minutes).
  • Focus first on listening and basic navigation.
  • Add Screen Curtain early if light sensitivity is significant.
  • Introduce Voice Control gradually for common actions.

Sources

Demonstration: Guide Accessifies the Addition of Components to Salesforce Experience Cloud Site Pages

by

At the intersection of the Salesforce ecosystem and the accessibility community, it has been long known that Experience Builder contains task-blocking accessibility issues that hold many disabled people back from being able to perform important job duties including site administration and content management. While the company continues efforts to improve the accessibility of Experience Builder, disabled administrators, content managers and site developers who rely on keyboard-only navigation and screen readers are finding ways to work around barriers thanks to new tools based on artificial intelligence (AI).

Read more

Unlocking the Power of AI

by

Unlocking the Power of AI

Presented by the National Federation of the Blind of Arizona

The future is here, and it’s smarter than ever. The National Federation of the Blind of Arizona is excited to host our first-ever AI webinar: a deep dive into the world of Artificial Intelligence and how it’s transforming accessibility for blind and low-vision users.

Date: Saturday, March 22nd

Time: 11 AM – 2 PM Pacific Time (2 PM – 5 PM Eastern Time)

What’s on the agenda?

Mobile Apps – Explore and compare top AI-powered apps, including Seeing AI, Be My Eyes, Aira Access AI, PiccyBot, SpeakaBoo, and Lookout for Android. Learn what sets them apart and how they can enhance daily life.

ChatGPT and Real-Time Assistance – AI is evolving beyond text-based interactions. We’ll discuss how ChatGPT’s voice mode can be used with the iPhone’s camera to provide real-time descriptions of the environment, giving users instant feedback about what’s around them. This technology is adding a new level of independence and awareness in everyday situations. Note: although Google AI studio is used on the computer, we will also include it here, as it provides real-time information about what is on screen.

AI on the Computer – Discover tools designed for PC users, such as Seeing AI for Windows, Google AI Studio, JAWS Picture Smart, and FS Companion (new in JAWS 2025!). These innovations are making it easier than ever to interact with digital content, from describing images to navigating complex documents.

AI-Powered Wearables – Smart glasses are certainly helping in the world of accessibility. We’ll explore the capabilities of Ray-Ban Meta Smart Glasses and Envision Glasses, which provide real-time AI-powered assistance for tasks like reading text, product labels, and navigating environments hands-free.

The Art of AI Prompting – Special guest Jonathan Mosen will guide us through the fundamentals of AI prompt engineering, teaching us how to structure questions effectively to get the best results. AI is powerful, but knowing how to communicate with it can make all the difference.

Bring your curiosity, your questions, and your excitement for what AI can do. Whether you’re a tech expert or just starting to explore AI, this seminar will give you the tools to unlock new possibilities. We hope to see you there. Below is all the zoom information to connect.

Topic: NFB of AZ AI Tech Seminar

Date: Saturday, March 22nd

Time: Mar 22, 2025 11:00 AM Mountain Time (US and Canada)

Join Zoom Meeting

F6 Is Your Friend

by

From enterprise collaboration software to web browsers, the little-known F6 keyboard shortcut can do many things that make our lives as blind computer users much easier and more productive.

In Slack F6 moves between the major portions of the window, such as channel navigation and workspace selection. It is, in fact, virtually impossible to access critical functionality, such as channels and direct messages, without pressing F6. Please review the Use Slack with a Screen Reader article for additional documentation. J.J. Meddaugh’s fantastic AccessWorld article An Introduction to Slack, A Popular Chat App for Teams and Workplaces provides a great starting point for using Slack from a blind user’s perspective.

In the Google Chrome and Mozilla Firefox web browsers, F6 jumps out of the address bar and moves focus directly into the currently loaded web page with the screen reader’s browse mode or virtual PC cursor active and ready for immediate action. It is not necessary to press tab several times to move through the browser’s toolbar.

In Microsoft Office apps, such as Excel, Outlook and Word, F6 moves focus between major elements of the window, such as the ribbon bar, list of messages, document area and the status bar.

Let’s discover together all the additional productivity boosts we can achieve through keyboard shortcuts like F6. What is your favorite keyboard shortcut? How does it increase your productivity?

Please tell us how you and your family are handling social distancing, feeding yourselves, vaccination and generally getting along, especially from a blind perspective, as we move out of the time of the Coronavirus. Please send an audio recording or a written message to darrell (at) blindaccessjournal (dot) com or tell us about it on our social media channels.

Blind Access Journal, and the Hilliker family, must frequently rely on sighted assistance in order to get important, inaccessible tasks done. In most cases, we have chosen Aira as our visual interpreter. If you are ready to become an Aira Explorer, and you feel it in your heart to pass along a small gift to the journal or our family, we ask that you use our referral link. Your first month of Aira service will be free of charge, we will receive a discount on our bill and we will thank you for supporting the important work we do here at Blind Access Journal.

If you use Twitter, let’s get connected! Please follow Allison (@AlliTalk) and Darrell (@darrell).