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.)
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:
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.
0 comments:
Post a Comment
I get a lot of comment spam :( - moderation may take a while.