Skip to content →

Month: November 2025

Give Accessibility a Seat at the Notepad Table Please

Unreal, I read today that Microsoft has started rolling out table support for Notepad. But guess what, if you are using a screen reader, the fact that you are in a table when editing is not communicated at all. This despite the fact that Office has clearly communicated tables when editing for many years with screen readers, including Narrator. So, clearly technical solutions exist and have been used for a long time. Why is something this basic once again left out for accessibility?

If you are so inclined, you can up vote feedback I submitted on this issue at this feedback link.

This is another example of why I say we need more accountability around accessibility. If Microsoft is going to enhance Notepad, accessibility needs an equal seat at the table, not something missed yet again.

2 Comments

Windows Copilot Serves At Best Half an Answer to Screen Reading Users

If you follow me on social media, one of the themes you’ll find I talk about fairly often related to accessibility is how text that isn’t shown visually needs to have better verification. This can be anything from alt text on web pages, to the accessible names used in different applications for controls such as menus and more. For several months now, the Windows Copilot app has had a serious problem that fits in this category. I know I reported it to Microsoft at the start of March of this year and the problem remains as broken today as it was then.

In this case, the challenge is that the text communicated for accessibility purposes is clipped such that when reviewing answers with Copilot, The answers you receive are incomplete.

If I ask Copilot for a list of the fifty United States, I’m led to believe that there are only 27 states. In the way the list is rendered to a screen reader, the List ends at the State of Nebraska. I guess Wisconsin, where I am writing this from, has disappeared?

If I ask for a list of the U.S. presidents, the list when read with a screen reader only shows 10 presidents and in fact cuts off the last name such that you end up getting only a partial name. At least my history never said we had a president named “10. John T.”

You can try various modes with the different screen readers, such as Narrator’s Scan Mode, the JAWS Touch Cursor and more and the problem is not improved. In most cases, such as Narrator’s Scan Mode, you end up reading some text twice but still never get the full answer.

It should not be necessary to copy a response and paste it into another app just to read the answer from an AI system or any app for that matter.

The frustrating thing is that none of this was an issue at the start of 2025. Microsoft appeared to be coalescing around a fairly standard user experience for the multitude of Copilot experiences available to customers. The foundation for the Windows app was a well-structured HTML experience with headings and more that made reading answers quite straight forward.

Sometime after the start of the year, the Windows Copilot app appears to have changed some of the foundational technology used that has caused this sorry state of incomplete answers when read with a screen reader. One can only wonder how long this busted experience will be allowed to exist. It is already several months too long in my opinion.

To be honest, it is incredibly frustrating to write blog posts like this. I doubt they do much good, but I am not sure what other avenues to pursue. As I said, I reported this situation to Microsoft in early March of this year. Through multiple email exchanges, all I know is that Microsoft claims they are taking the issue seriously.

It is repeated situations like this, where accessibility issues linger on and on where I say we need a shift to true accountable accessibility. I outlined a proposal for such earlier this year as well.

This is just one of several significant accessibility challenges with the Windows Copilot app. I’m a firm believer that all experiences should be usable and accessible, but this is especially true for AI-based situations. We need to be able to access the responses put out from AI effectively and obviously comprehensively.

In fact, if I ask the Windows Copilot app to give me a definition of accessible software, the experience is to me completely unacceptable. Things start out well enough with automatic reading of a message that Copilot is preparing the answer. They then progress to a reading of the beginning of the answer, only to have that reading interrupted by a restart of the reading of the answer that starts over from the beginning, only to read more of the full answer automatically.

Ignoring the multiple tabs or shift+tabs it requires to get from the edit box for communicating with Copilot to the chat history, the answer in the chat history is again clipped from what you heard with the automatic reading. Here is my chat history as read by Narrator when moving to the Copilot chat history for the accessibility prompt and response.

give me the definition of accessible software please.
**Accessible software is software designed to be usable by people with a wide range of disabilities, ensuring equal access to digital tools and content.**
### 🧩 What Accessible Software Means
Accessible software incorporates features and design principles that remove barriers for users with:
– **Visual impairments** (e.g., blindness, low vision, color blindness)
– **Auditory impairments** (e.g., deafness, hard of hearing)
– **Motor impairments** (e.g., limited dexterity, paralysis)
– **Cognitive or neurol

If I copy the answer, you can read just how much is skipped and also the fact that any of the structure, such as lists, is not communicated when reading in the Copilot app. Here is the full copied answer to my question.

Accessible software is software designed to be usable by people with a wide range of disabilities, ensuring equal access to digital tools and content.

🧩 What Accessible Software Means

Accessible software incorporates features and design principles that remove barriers for users with:

  • Visual impairments (e.g., blindness, low vision, color blindness)
  • Auditory impairments (e.g., deafness, hard of hearing)
  • Motor impairments (e.g., limited dexterity, paralysis)
  • Cognitive or neurological conditions (e.g., dyslexia, ADHD, autism)

The goal is to ensure that everyone, regardless of ability, can interact with the software effectively and independently.

🔍 Key Features of Accessible Software

  • Keyboard navigation: All functions can be accessed without a mouse.
  • Screen reader compatibility: Proper use of semantic HTML, ARIA roles, and alt text for images.
  • Color contrast and scalable text: Ensures readability for users with low vision.
  • Captions and transcripts: For multimedia content, aiding users with hearing impairments.
  • Logical structure and focus management: Helps users navigate and understand content flow.
  • Customizable interfaces: Allows users to adjust layout, font size, and input methods.

📐 Standards and Compliance

Accessible software typically adheres to guidelines such as:

  • WCAG (Web Content Accessibility Guidelines) – the global standard for digital accessibility.
  • Section 508 (U.S.) – mandates accessible technology for federal agencies.
  • EN 301 549 (EU) – accessibility requirements for ICT products and services.

🧠 Why It Matters

  • Inclusivity: Promotes equal participation in digital spaces.
  • Legal compliance: Avoids lawsuits and meets regulatory requirements.
  • Better UX for all: Accessibility often improves usability for everyone.
  • Ethical responsibility: Reflects a commitment to social equity and universal design.

If you’d like examples of accessible software in action or want to benchmark a specific app, I can help you analyze it.

2 Comments