Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Is Quietly Killing Enterprise Screen Readers
Transcript
- Lucas: There's a quiet clock ticking on every enterprise Windows desktop that relies on a screen reader, and it's not the one that shows the date in the system tray. Luna: You're talking about the screen reader API transition — MSAA to UIA — that Microsoft announced a couple of years ago but hasn't exactly been shouting about lately. Lucas: Exactly. Microsoft Active Accessibility, or MSAA, has been the backbone of screen reader software since Windows 95. JAWS, NVDA, even the old Windows Narrator — they all leaned on MSAA to figure out what's on screen. But MSAA is old. It can't handle modern UI patterns like XAML, web views embedded in apps, or the kind of dynamic content that shows up in a Power BI dashboard. Luna: So Microsoft built UI Automation — UIA — as the replacement. It's more capable, supports richer metadata, and works with modern frameworks. The problem is, tens of thousands of enterprise applications still rely on MSAA. And the deadline to move is coming. Lucas: Right. Microsoft's official line is that MSAA is deprecated in Windows 11, and they've said they'll remove it in a future release. The current guidance points to 2027 as the cutoff — but that's not a hard date carved in stone. What is carved in stone is that Windows 11 24H2 already ships with MSAA turned off by default in some security configurations, like when you enable S mode or certain lockdown policies. Luna: And that's where the enterprise surprise hits. A company might have a perfectly working JAWS license, a fleet of Windows 11 machines, and suddenly the screen reader stops reading certain dialog boxes — because the app is using MSAA and the API is blocked. Lucas: Let's get specific. Take an internal HR portal built on an older web framework. The screen reader uses MSAA to grab the text of a dropdown menu. In Windows 10, that works fine. In Windows 11 with the latest cumulative update, MSAA calls may return empty data because the accessibility bridge has been redirected to UIA — and the app never implemented UIA. So the employee who depends on the screen reader can't fill out their benefits enrollment. Luna: And that's a compliance issue. Section 508 in the US, the Accessibility Act in the EU — if an enterprise can't demonstrate that their internal tools work with assistive technology, they're exposed. Not to mention the productivity hit. Lucas: So what should IT admins do? First, audit every line of business application for its accessibility API usage. There's a tool — the Windows Accessibility API Explorer — that can show you whether an app is talking MSAA, UIA, or both. Second, contact your screen reader vendor. JAWS from Freedom Scientific has supported UIA for years, but the configuration is sometimes turned off by default. NVDA supports UIA out of the box, but older versions might still default to MSAA. Luna: And the third thing is the hardest: get your software vendors to update their apps. If you're running a custom internal app built on.NET Framework 4.7 or earlier, it probably uses MSAA under the hood. You'll need to retarget it to.NET 8 or later, or at least add UIA support explicitly. Lucas: There's a real tension here. Microsoft wants to modernize the platform, and UIA is genuinely better — it exposes more information, it's faster, it supports touch and voice. But the transition has been messy. There's no single 'enable UIA for all apps' switch. Each app has to be updated individually. And in regulated industries — banking, healthcare, government — the certification cycle for a new app version can take 18 months or more. Luna: By the time a bank certifies its screen reader compatibility on Windows 11, Microsoft might have already shipped another update that further restricts MSAA. That's the kind of whiplash that keeps IT auditors up at night. Lucas: And honestly, if understanding this transition gave you something useful for your own planning — that's exactly the kind of insight that keeps this show ad-free and independent. If it was worth a coffee to you, that's the link: buy me a coffee dot com slash fexingo. Luna: It's a small way to signal that these deep-dive Windows conversations matter. No pressure, just a nod if it helped. Lucas: Back to the migration. One thing that's flying under the radar is that Microsoft itself is deprecating MSAA in the Windows UI framework. WinUI 3 and the newer Windows App SDK don't even expose MSAA calls. If you build a new app today with those tools, it's uia only. So the future is already decided. Luna: But the past is still sitting in the enterprise — thousands of legacy apps that were written before UIA existed. What's the practical timeline for an IT department? Lucas: I'd say treat 2027 as a hard gate. If your app isn't uia compatible by then, you risk having users who can't do their jobs. Start with the most critical apps — the ones that handle HR, payroll, compliance training. Those are the ones where a screen reader failure is an immediate legal risk. Luna: And what about the screen reader vendors themselves? Are they ready? Lucas: Mostly. JAWS 2024 and later have full UIA support, but some users report that certain advanced features — like custom scripts for complex applications — still rely on MSAA hooks. Those scripts will break. Freedom Scientific has a migration guide, but it's not a one-click fix. NVDA is more agile; its developer community has been pushing UIA for years. The real wildcard is the built-in Windows Narrator. Luna: Narrator actually uses UIA natively — it's Microsoft's own screen reader. So it's already on the new API. But most enterprises don't deploy Narrator; they use JAWS or NVDA because those have more features. Lucas: Right. Narrator is fine for basic navigation, but power users in enterprise environments need the customization and scripting that JAWS provides. So the enterprise is caught between a vendor lock-in and a platform change. Luna: There's also a testing burden. IT teams need to set up a test environment with the latest Windows 11 build, enable the 'disable MSAA' group policy, and run through every workflow with JAWS or NVDA. That's not a weekend project. Lucas: No, it's a multi-quarter initiative. And it intersects with other Windows 11 changes we've covered — like the deprecation of Group Policy for MDM, or the shift to passwordless authentication. If you're already overhauling your device management strategy, this is another layer on top. Luna: Let's talk about one specific scenario that's causing headaches: virtual desktop infrastructure. When a user connects to a Windows 11 VDI session, the screen reader has to communicate over RDP. The accessibility API calls get remoted. With MSAA, that was flaky but worked. With UIA, the remoting is more reliable — but only if the VDI host and the client are both on Windows 11 with the correct settings. Lucas: That's a great point. Citrix and VMware have released updates to support UIA over their protocols, but many enterprises are still on older versions. I've heard of organizations that upgraded their physical desktops to Windows 11 but kept their VDI on Windows 10, and the screen reader users in the VDI sessions ended up with a split experience: some apps work, some don't. Luna: So the migration has to be synchronized across the entire fleet — physical and virtual. That adds complexity. Lucas: It does. And there's one more wrinkle: third-party accessibility tools that aren't screen readers. Things like magnification software, speech to text, and braille displays. Many of those also use MSAA indirectly. The Windows 11 changes affect the entire assistive technology ecosystem. Luna: Microsoft has published a list of deprecated APIs, but it's buried in the Windows developer docs. Most IT admins don't read those. They find out when a ticket comes in saying 'screen reader not working on new laptop.' Lucas: Exactly. That's the reactive pattern we want to avoid. Proactive planning means running the Accessibility API Explorer across your app portfolio, prioritizing by user impact, and setting a 2026 target to have all critical apps uia compatible. That gives you a year of buffer before Microsoft potentially flips the switch. Luna: And if you're a developer maintaining internal apps, what's the technical lift? Is it just a library swap? Lucas: Not quite. If your app uses Windows Forms or WPF, the transition is relatively smooth — those frameworks have built-in UIA support. You might need to add automation properties to custom controls. If your app uses MFC or raw Win32, it's more work because you have to implement the UIA provider interface yourself. Microsoft has sample code, but it's not trivial. Luna: So the takeaway for IT leaders: start an accessibility API audit this quarter. Don't wait for the help desk calls. And have a conversation with your screen reader vendor about their UIA roadmap. Lucas: That's the play. Windows 11 is a better platform for accessibility in many ways, but only if you prepare for the transition. The clock is ticking, and it's not making a sound.