Thursday, March 16, 2023

Microsoft's Ability Summit has inspired me, again!

Microsoft Ability Summit March 8, 2023

Microsoft's Ability Summit was last week, and it has, once again, inspired me to do more work on the tools I have in progress.

You can register via the above link to get to the official site, but the videos are also now available on YouTube.

It was inspiring to see the recently announced Accessibility Checker inside Visual Studio in action. It also showed me that it does have value. I had doubts about this as it's functionality that already exists elsewhere. 

This new tool allows you to run the same tests as can be run by Accessibility Insights, but from a button in the in-app (debug) toolbar (or Live Visual Tree window.)

Two captures from Visual Studio. The left capture shows the top edge of an application being debugged including the in-app toolbar. The 7th button is the "Show Accessibility Checker" button, shows an accessibility icon in white and has a red circle around it. The right capture shows the top of the Live Visual Tree panel in Visual Studio. On the toolbar at the top of that panel, the 6th button is the "Scan for Accessibility Issues" button, has the same accessibility icon in blue and also has a red circle around it.

I've got in the habit of using Accessibility Insights directly or via automated testing* to perform basic testing of an application.

* Yes, I have tests that run an app, navigate to each page, run accessibility tests against that page, and check for (& report) failures. It's not perfect, but it's much better/faster/reliable than doing it manually. 

It reminded me that I have code that can do much of this on source code.

Like this:

Visual Studio Editor screenshot showing contrast issues and missing Name on XAML source code files

When the benefit of Visual Studio having an Integrated Accessibility Checker in the debug experience is that it makes issues easier for developers to see and fix because they don't have to go to another tool. And it makes them quicker and easier to fix by "shifting left" to be part of the debugging experience; how much better to shift further left to when the code is being written (before getting to the debugging step) and not putting the functionality behind another tool that must be known about and run but putting the information where developers are already looking?

I really must hurry up and get this in a state that I can make it public.

It's not as complete as the other tooling as it can't catch quite as many issues, but I think there's value in catching (and fixing) even some issues earlier. 


Post a Comment

I get a lot of comment spam :( - moderation may take a while.