[BCAB] Edge accessibility support for HTML5
tink at tink.uk
Thu Aug 4 09:18:24 BST 2016
I'll try to answer what I can John. You might want to grab a cup of tea
though, this could take a few minutes!
Narrator works pretty well with Edge. I don't use Narrator in anger, but
if I want to look at something in Edge that's the only option for the
As to why Edge breaks accessibility, that's a more complex question. You
have to delve into the mechanics of accessibility on different platforms
to get to the bottom of it.
Each platform (Windows, OSX, Linux etc.) has an accessibility API. Some
platforms, like Windows, have more than one. Screen readers (and other
assistive technologies) use these APIs to discover information about the
things on-screen, like whether something is a menu, a button or an
application window for example. Screen readers also use these APIs to
get information about the things in web pages, like headings, checkboxes
or text for example.
For the purposes of this discussion, there are two accessibility APIs
developed by Microsoft: MSAA (which has been around since Windows 95)
and UIA (which has been around since Windows 7).
If you are curious to know more about accessibility APIs, this article
might be of interest:
So for several years IE used both MSAA and UIA, but with Edge Microsoft
decided to drop support for the much older MSAA in favour of UIA. There
were two problems with this:
1. Although UIA had been in existence for about six years by the time
Edge arrived, it hadn't been developed particularly well by Microsoft
and so it lacked a lot of the accessibility features that MSAA had.
2. Screen readers were comfortable using MSAA and saw no reason to put
time and resources into supporting UIA.
So the result was that Edge used only UIA, which made less accessibility
information available to screen readers, and screen readers really
weren't very good at using what little accessibility information UIA
There was another factor that complicated things further though. In IE,
when a screen reader couldn't discover information using the
accessibility APIs, it would go and look at the code of the web page (or
at least the browser's rendered version of the code) to try and
determine what was what. This is a horribly inefficient way for a screen
reader to have to do things, but it was a useful workaround when needed.
Edge prevents third party tools from accessing this rendered code, known
to developers as the Document Object Model (DOM). It prevents access to
make Edge more secure, and to stop malicious third party tools from
gaining access to the browser. Trouble is, it also stopped screen
readers from using their default workaround.
So that's why Edge is such a problem. Microsoft invited all screen
reader vendors to a summit in Redmond many months ago, and offered their
support to help them get up to speed - but until Microsoft did the
necessary work on improving UIA, there was truthfully little the other
screen reader vendors could do. Now Microsoft has fulfilled its promise
to improve UIA, hence the 100% results, and it is now up to the screen
reader vendors to play their part.
At the moment VI people are at a disadvantage when it comes to Edge,
because Narrator is the only option. Narrator isn't a fully fledged
screen reader yet, but I think it is at least as good as VoiceOver was
in the early days. It does have some navigation shortcuts for headings
and tables, but not as many as some of the other screen readers offer.
@LeonieWatson tink.uk Carpe diem
More information about the Bcab