Risk Free Assessment
On March 25, Apple released iOS 12.2, the second major update to its iOS mobile operating system, closely followed by macOS Mojave 10.14.4. While bringing features such as Apple News+ support, Safari dark mode, new Emojis and numerous other enhancements, a change was quietly introduced for assistive technology users that has sent waves throughout the blind and visually impaired community. This change, succinctly dubbed “Accessibility Events,” will allow websites to determine whether VoiceOver or other assistive technologies – currently only Switch Control — are running. This option is disabled by default, and is part of the Accessibility Object Model (AOM),a collaborative effort by Google, Apple and Mozilla to create a JavaScript API for accessibility.
In the fifth WebAIM survey, a question was posed: “How comfortable would you be with allowing web sites to detect whether you are using a screen reader?” The vast majority (78.4%) of screen reader users reported being very or somewhat comfortable with allowing screen reader detection. 86.5% reported that they were very or somewhat comfortable with detection if it resulted in improved accessibility. Despite these positive results, assistive technology detection presents a handful of issues, ranging from social to the technical.
First, text-only websites. Often, websites such as Amazon have deployed a text-only version of their website which removes many of the graphics, carousels and other controls that may present problems for a disabled user. While these companies mean well, development of a text-only interface often means that the text-only website will lack features that the primary website has. The secondary version will also require significant focus put forth for upkeep, ensuring that the secondary version for disabled users properly mirrors the main website. Maintaining separate channels of code is a nightmare. Developers are already concentrating on making their websites interact best with multiple browsers and devices; accessible versions of websites will rapidly become out of date. Finally, this is a form of discrimination. Accessibility should be conceived at the design stage, not bolted on in such a fashion that it requires people to diverge to a separate website to complete their daily tasks.
This framework for accessibility events can be a violation of privacy. Some maintain that it is no one’s business what assistive technology may or may not be running on a machine, and this is a valid concern. Luckily, Apple has provided an option to toggle this behavior on and off at will, and it is not enabled out of the box on either macOS or iOS. Nevertheless, the precedent that this sets is worrisome. In various cases, users may be left to choose between privacy and accessibility, with no in between. Disability is a personal part of many people’s lives, and the internet has been fostered into a place where it’s not always apparent that a user has a disability, bringing cases of discrimination to a minimum. This changes that.
The scope of this “accessibility events” system is also limited; currently, it will only take effect with VoiceOver and Switch Control. That is barely a modicum of the accessibility use cases in the real world. Rather than focusing on tailoring the experience for a subset of users, developers must focus on making the experience accessible to all. Instead of asking “How can we leverage accessibility events to improve the experience for screen reader and switch Control users?” we should be asking “How can we improve our website so every single individual with a disability can interact with it?”
It’s impossible to predict what impact accessibility events will have on the web. There are both positives and negatives, and we sincerely hope that these events are leveraged for good, not to create even more of a barrier between the disabled community and mainstream access.