#A11Y Slackers

#a11y slackers - play on the slack multicolored hash symbolA ubiquitous issue for people involved in moving the web forward is that there is always too much to do. Identifiying and prioritising tasks is critical. Identifying is fairly easy, prioritising not so. Priorities depend on both internal and external factors often beyond our control.

I have a tendency to be critical of huge, profit making, corporations that are involved in moving the web forward who de-prioritise accessibility [who appear to de-prioritise accessibility]. It’s not always a useful trait, but it’s who I am. I am also aware that many of the people who I interact with, while working for these corporations, are doing their best to make accessibility a priority despite the internal and external factors beyond their control.

A current example is Microsoft, what we know is that Windows 10 will be with us at the end of the month along with a new much improved standards based browser called Edge. What is known is that Microsoft is a huge corporation with a long history of accessibility support in its software and also a long history of broken sub-standard accessibility support for HTML in its browser (IE). IE has come along way in web standards support in the last few years, the  same cannot be said for the accessibility branch of web standards.

There is the future promise that with Edge accessibility web standards support will be much improved, but as is often the case due to corporate prioritisation, and resulting provision of resources and expertise, Windows 10 will arrive with a brand new browser, with broken accessibility support and advice to continue to use the old IE browser whose support, while broken, is more robust because assistive technology have had a lot of time to hack around the brokeness.

It is instructive to understand that when an organization genuinely prioritises the needs of users with disabilities, anything is possible:

Further Reading

Windows 10: Advisories from screen reader developers and final thoughts


It was unfair of me to imply that the current Microsoft browser team are #a11y slackers. They are doing all they can under difficult circumstances to bring a modern, robust accessibility implementation to Edge, something that unfortunately Microsoft failed to do in the history of IE.

Categories: Technical
Tags: , , ,

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.


Jacob Rossi says:

The a11y experience of Microsoft Edge is not where we want it to be and we’re working hard on fixing that. Here’s what’s going on behind the scenes that can help better understand how we’re where we are and what we’re working towards.

IE supported MSAA as its primary a11y API for ATs. MSAA was later superseded with UIA in Windows. However, IE used a bridge to convert between MSAA and UIA. This bridge component was the source of *much* of the buggy a11y experience in IE. So for years, we’ve wanted to move to a native UIA implementation.

In Microsoft Edge, we’re doing that finally! This is a massive investment and we have lots of engineers working on it. It’s perhaps, actually, our biggest investment in a11y in the browser in years (maybe ever). So it’s not true to say we deprioritized a11y in the least.

However, we are still in the progress of that transition. This transition also requires the 3rd party AT ecosystem to adapt as well. We’re working hard on completing this transition and are working close with 3rd party ATs on this (we just had a bunch of them up here on campus just a couple weeks ago, for example). We’re also looking at improving UIA itself, working to rectify capability gaps compared to other APIs like MSAA and IAccessible2.

Windows 10 will RTM this month and MS Edge isn’t where we want it for a11y just yet. So we’re recommending AT users use IE for the time being. But we look forward to updating Microsoft Edge to *exceed* the a11y experience of IE once all these moving parts land.

Hope that helps shed some light on the journey we’re making to improve a11y. Always open to questions and feedback @jacobrossi on Twitter.

Steve Faulkner says:

Thanks for your detailed comment, have modified my statement on de-prioritisation.

Correction, you appear to have modified the statement. What’s with the anger? Jacob explained all the ins and outs here, what else could he do?

Steve Faulkner says:

Hi Christian, no anger, but indeed, you sound a bit feisty. I acknowledged that there are differences between appearances, based on public knowledge and what is actually happening. There is/was no anger in my writing here, a little frustration maybe…

Steve Faulkner says:
Steve Faulkner says:
Michiel Bijl says:

I want to thank Jacob Rossi for his public reply to clarify what’s going on at Microsoft and within the EdgeDev Team.

Steve Faulkner says:
Léonie Watson says:


Thanks for the useful information. Couple of questions…

It’s good to know that UIA is being worked on to bring it inline with IA2 etc. Is there a timetable/roadmap for this?

How much is Edge used throughout Windows 10 itself? It’s my understanding that it’s used as a wrapper for content within the Windows App Store for example. I know this is a concern for many AT users looking to upgrade.

Jacob Rossi says:

Great questions, Léonie. We’re working on a blog post and other materials to outline the roadmap for the work I mentioned. I’ll make sure to post a link here once that’s up.

EdgeHTML is used in a variety of places in Windows 10. Besides the browser, we offer a WebView to run web content inside Universal Windows Apps from the Store. UWAs can also be entirely web based running on EdgeHTML (we offer both a packaged web app format and a hosted web app format). Additionally, there are surfaces throughout the OS that use the rendering engine, such as Cortana.

The work I’ve described above applies to all instances where EdgeHTML is used in the system. Additionally, all instances are auto-upgraded (evergreen), meaning these a11y improvements will be automatically applied in all these contexts when released.

Léonie Watson says:

Thanks Jacob. This is useful to know, and it’ll be good to see the roadmap when it’s available. You make a good point about changes to UIA and other accessibility features being automatically applied too.

The pertinent question seems to be whether the use of Edge in other places throughout Windows 10 will cause problems for third party screen reader users in the meantime? I know Narrator works with Edge, and it’s great to see all the improvements Narrator has in Windows 10, but switching screen readers (even on a temporary basis to get a task completed) won’t be feasible for many users.