Accessibility: Towards a more inclusive web with Microsoft Edge and Windows 10
Microsoft is committed to accessibility as a core part of software design, and today we would like to share more about how Microsoft Edge is evolving to improve support for assistive technology beyond what was possible in Internet Explorer.
Inclusive development is a journey, not merely a destination, and we are committed to continuing to evolve Microsoft Edge to be the best place for accessible browsing on Windows. We’ve made a major step forward with architectural changes in Microsoft Edge, some of which regress experiences compared to Internet Explorer in the short term, but which are in the interest of creating a more inclusive experience for everyone in the long term. This post outlines our journey to a more accessible web experience, including changes in Microsoft Edge available today and recommendations for Windows 10 users who rely on third-party assistive technology software.
Our journey to a more accessible web experience
Windows has used the Microsoft Active Accessibility (MSAA) API since Windows 98 to express buttons, menus, text, and other on-screen content to assistive technology. Assistive technology vendors have used the MSAA API (along with other app-specific APIs like the DOM in IE, the Office Object Model in Office, and even scraping video drivers) to make text and interfaces more accessible. These techniques have the disadvantage of varying wildly between different applications and documents, which leads to a fragmented and unreliable experience. As user interfaces, documents, and the web significantly increased in complexity, Microsoft introduced the more modern UI Automation (UIA) API in Windows Vista as the successor to MSAA.
UIA was designed to expose more information about the user interface and structured documents, improve performance, and be portable across platforms. Because UIA replaces a variety of potentially unreliable and non-interoperable techniques with a single API, it reduces software complexity, allows developers to express novel UI concepts more easily, and improves stability and user experience consistency between web and native apps, across all types of assistive technology.
Though UIA superseded in MSAA in 2005, Internet Explorer continued to rely on MSAA, using a ‘bridge’ to convert between MSAA and UIA. Relying on this bridge introduced bugs and performance problems in Internet Explorer, and for years it has been a goal of the browser team to move to a native UIA implementation.
Accessibility investments in Microsoft Edge
In Microsoft Edge, we are thrilled to finally have the opportunity to make the transition from MSAA to UIA, alongside enormous complementary investments in rearchitecting our DOM implementation and rewriting the browser interface from scratch. The change to UIA is our largest investment in browser accessibility ever, and it lays the foundation for a more inclusive web experience for users who depend on assistive technology in Windows 10. Because EdgeHTML is used throughout Windows 10 (inside Universal Windows Apps, in Cortana, etc.), these benefits will have an impact beyond the browser. Users will also benefit from the evergreen nature of the EdgeHTML engine.
You can see many of the improvements in action today using Narrator, which is built into Windows 10. We’re using Narrator to vet UIA as we simultaneously work with third party assistive technology providers to transition in the near future. For example, while MSAA supports only basic UI constructs, Narrator works with UIA in Microsoft Edge to express more complex roles, states, and properties to better represent structured and interactive documents.