Part of what this entails is the deprecation of Internet Explorer.
As a bit of history, Internet Explorer (IE) was developed and first released in the mi 90’s, approximately twenty years ago. This was at the same time when Accessibility APIs were in development, and still had a long way to go before reaching what we know and use today. Also, this was before ARIA was officially invented, existing only in the heads at that time of a handful of people who were working on the planning stages for it. As such, IE was released as an application that would be plagued with legacy bugs and accessibility issues spanning twenty years of continuous development to the present day.
This is the primary reason why more modern browsers such as Firefox include better Accessibility API support for technologies such as ARIA, because the code base is newer and easier to update as these technologies evolve and become better defined.
In contrast, as technologies evolve, many aspects of Internet Explorer need to be reverse engineered in order to identify where things don’t work before it is possible to update the code with new and more accessible functionality, which is much more complicated and takes much longer to accomplish. Also, as MSAA was morphed into UIA as the global Accessibility API for Windows, a custom layer was introduced for use within Internet Explorer called UIA Express; introducing duplication of effort for maintaining both equally.
The only feasible long term solution for dealing with this was to build a new browser and map it directly to UIA within Windows, unifying access to the Accessibility API and consolidating code management so that new features would be easier to introduce in the future.
This is what the Edge browser has become, and it will automatically tie into the Windows Accessibility API so that new technologies such as ARIA will work better than they ever did in Internet Explorer.
There are some important ramifications to this however, which need to be mentioned.
Firstly, though security updates to Internet Explorer will continue, Accessibility Tree updates to IE will not. This includes all versions of IE upon all supported versions of Windows.
This means that ARIA support within Internet Explorer is now frozen at its current level, which is mostly compliant with ARIA 1.0, but diverges greatly with ARIA 1.1 and will continue to do so as ARIA 2.0 is developed in the future.
As such, ARIA compliant interactive widget designs will continue to improve and become more powerful and accessible within Edge and other browsers such as Firefox, Chrome, and Safari, but will become increasingly less accessible within Internet Explorer as time goes on and the gap steadily widens.
Secondly, since JAWS still holds the majority of the screen reader market for non-sighted users worldwide, there will likely be a shift from the majority of Internet Explorer usage to that of Firefox upon pre-Windows 10 operating systems, since Edge will not be available on those systems for users of JAWS. This shift will be necessary, because web technologies will become increasingly advanced, in many ways integrating directly with the platform operating system to provide feature-rich experiences for users that are designed to be accessible at the same time. However, none of these new features will work the same using Internet Explorer.
As developers, designers, and implementers of accessible web technologies, we all need to be aware of these new developments, and how they will shape our efforts in the future.