Summer months are typically a great time for relaxing and unwinding. We here at Serotek recognize the value of rest and recreation, but as you know, the technology landscape is in a constant shift, requiring us to work overtime in the lab so that your favorite applications work the way they\u2019re supposed to when you\u2019re ready to come back from vacation. We have a number of short-term and long-term goals on the drawing board, some of which we\u2019ll share in upcoming posts, some of which we\u2019ll explore in a soon to be announced series of podcasts.<\/p>\n\n\n\n
In the meantime, we bring you the first in a series of articles exploring recent developments in mainstream technology.<\/p>\n\n\n\n
Earlier this week, Microsoft released the long-awaited Windows 10 Anniversary Update. Among the most prominent features in this update are several major improvements to the Edge web browser. The Edge development team recently published a blog post describing these improvements. Among other things, that post states:<\/p>\n\n\n\n
\u201cwe\u2019re proud to say that Microsoft Edge in the Anniversary Update is easily the most accessible browser we\u2019ve ever shipped\u201d.<\/em><\/p>\n\n\n\n While we at Serotek appreciate the considerable improvements that the Edge team has made in accessibility since the original release of Windows 10, we must emphatically insist that the claim quoted above is, at the very least, misleading. In our opinion as assistive technology developers, the only way that claim can be considered true is if the word \u201cwe\u201d in that sentence refers strictly to the Edge team, and not to Microsoft in general. That\u2019s because in practice, the accessibility of even the new and improved Edge is a significant regression compared to what we always had in Internet Explorer, and even compared to Firefox and Chrome.<\/p>\n\n\n\n There are two main problems: Edge does not give assistive technologies a way to access the raw Document Object Model (DOM) of a web page, which we need in order to fill in gaps in website accessibility. Further, the speed that we can achieve in Edge is hobbled in comparison to all other browsers on Windows.<\/p>\n\n\n\n First, in both Internet Explorer and the Windows version of Firefox, screen readers have always had a way to access the raw Document Object Model of a Web page. This is the browser\u2019s internal representation of the HTML code that makes up a page. This level of access allows all screen readers to provide various features that can fill in the gaps when a website isn\u2019t perfectly accessible out of the box. For example, Serotek has long been known for its C-SAW (Community-Supported Accessible Web) feature, which lets users provide labels for graphics and form fields that aren\u2019t labeled by the website developer. We are also able to implement our own website-specific work-around for accessibility problems, such as when a button or link isn\u2019t properly marked up but just appears as plain text, or when a site doesn\u2019t properly indicate that part of the user interface is currently invisible. Even very popular sites such as Amazon.com and PayPal still have problems like these sometimes.<\/p>\n\n\n\n At Serotek, we\u2019ve always believed that, to the extent possible, we should make our own accessibility, rather than wait for it to be served to us on a silver platter. But to do this, we need some help from the browser. And so far, the Edge team has not provided the level of raw access to a Web page that we need to fill in website accessibility gaps as we do in other browsers. Instead, the Edge team has apparently taken the position that its only job is to provide access to websites that already do everything right in terms of following the accessibility standards. In this respect, the Edge team has done a great job, and Edge\u2019s perfect score from the HTML5 Accessibility browser benchmark reflects that. But real websites, even from large companies such as Microsoft itself, do not always properly implement the latest accessibility features of ARIA and HTML5. It\u2019s our job as assistive technology developers to make up for these real-world shortcomings, and so far, Edge doesn\u2019t let us do that job nearly as well as other browsers.<\/p>\n\n\n\n That\u2019s not the only problem. One of the most touted features of Edge is its speed. However, when it comes to accessibility, the speed that any full-featured screen reader can achieve in Edge is hobbled in comparison to all other browsers on Windows. Historically, all full-featured Windows screen readers have provided access to browsers by running some of their code directly inside the browser. Basically, the screen reader gets right inside the browser\u2019s space, and can then access all of the available information about a web page with very low overhead. But now, as part of Edge\u2019s stringent approach to security, Microsoft has decided that screen readers and other assistive technologies must stay out of the browser, only communicating with it from a distance. We don\u2019t have a problem with this limitation in and of itself, but it means that the mechanism that the screen reader uses to get information from the browser needs to be carefully designed for maximum efficiency, and so far, Microsoft has not done this consistently. With Edge, it\u2019s like we\u2019re sucking information through a straw, whereas before, we were gulping from the fire hose. Again, it\u2019s possible for Microsoft to solve this problem without backing down on security, which is also important, but that hasn\u2019t happened yet.<\/p>\n\n\n\n We have provided feedback to Microsoft on both of these problems. Microsoft has been receptive to this feedback, and we look forward to working closely with the appropriate development teams on further improvements. But for now, we believe these regressions are so significant that we cannot provide a level of access to Edge that we consider usable, let alone enjoyable.<\/p>\n\n\n\n