Skip to main content
September 25, 2015
Mobile

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.

https://youtu.be/O3JEMTGTn60

Using Narrator in Microsoft Edge exposes a set of new accessibility features, including:

  • ARIA roles: none, article, definition, log, math, note, scrollbar, application, banner, complementary, contentinfo, form, main, navigation, search
  • ARIA properties: aria-atomic, aria-autocomplete, aria-dropeffect, aria-grabbed, aria-label, aria-multiline, aria-orientation, aria-sort, aria-valuetext
  • HTML headings (<h1> to <h6>) are exposed via role and property
  • Indeterminate HTML checkbox
  • Narrator table and list reading improvements
  • UIA implementation in HTML5 form elements

The Microsoft Edge team continues to work with the W3C and other browser vendors on an ongoing basis to ensure that new web platform features have sufficient built-in accessibility. For example, Internet Explorer was one of the first browsers to support the <track> element and WebVTT caption format for video captioning. The work we shipped in Windows 10 gives us a foundation to release future features more quickly, as part of our commitment to making EdgeHTML an evergreen platform.

Getting to good: Our backlog

We recognize Microsoft Edge isn’t where it needs to be to provide a fully accessible browsing experience. Building a new browser required new user experience work in all levels of the product, including accessibility.  Windows Insiders and others in the accessibility community have provided valuable feedback which we’re using to prioritize improvements to the accessibility of the browser’s controls and the web itself in Microsoft Edge that will be available in the coming months.  These include:

  • Better keyboarding and narrator support in major UI elements such as the address bar, settings, favorites, history, and downloads
  • Support for semantically tagged PDFs for paragraphs, links, and images including alternative text specified for links and images. PDF improvements also include better keyboarding for links within a document.
  • Improved Flash accessibility
  • Improved ARIA and HTML mapping to UIA

We’re also working on longer-term investments. The following are high priority items on our backlog:

Finally, we’re working to help enable WebDriver support for automating accessibility API testing.

This list is just the beginning – we will continue to invest in Microsoft Edge and sharing our development roadmap via this blog and our Platform Status page, which we’re updating to reflect the above priorities. We encourage you to share your feedback on our priorities to help us rank our backlog appropriately.

Recommendations for Assistive Technology users on Windows 10

Many assistive technology users rely on third-party screen readers, so we are working closely with the most popular third-party assistive technology vendors to help them transition to UIA to provide a better experience for their users than was possible in Internet Explorer. These conversations are also a valuable feedback channel for us as we evolve UIA to close any remaining gaps with other APIs like MSAA and IAccessible2.

Users who depend on third party assistive technology should read Rob Sinclair’s post, “Windows 10 upgrade considerations for screen reader and magnifier users,” on the Microsoft Accessibility Blog. Some third party assistive technology may not yet be fully compatible with Microsoft Edge; in the short term, we recommend Internet Explorer for the most accessible browsing experience with these tools as our partners complete this transition. As we continue to work with assistive technology providers and evolve UIA in Windows 10, we expect Microsoft Edge to close the gap with Internet Explorer, and third party assistive technologies to begin providing UIA support on par with Narrator in the coming months.

If you encounter issues using assistive technology on Windows 10, you can contact the Microsoft Disability Answer Desk for support, or contact your assistive technology vendor for more information on their Windows 10 and Microsoft Edge support.

As we continue to improve the accessibility of Windows 10, your feedback is crucial. We encourage you to consider joining the Windows Insider Program to share your experiences and suggestions with us.

– Cynthia C. Shelly, Senior Program Manager, Microsoft Developer Platform

Tags:
Accessibility
ARIA
Behind the Scenes
EdgeHTML
Narrator
New Platform Features
UI Automation