Designing accessible web with privacy - when web browsing reveals information

Soon every website will be able to know if its visitors have a disability, or not. Well, not quite. That will relate to those who use assistive technologies (i.e. screen readers for vision-impaired), and who gave access for this feature. This thanks to Accessibility Object Model (AOM), a feature being developed by web browser vendors, and likely to be standardised within W3C later.

AOM is a good thing! It will make web design for developers easier. Most importantly, it will simplify information access for disadvantaged people. However, the design rationale behind this piece of technology are both challenging and unique. The choices made now will define for long how people with disabilities will be using the web. These choices and decisions will impact on the handicap disclosure process when visiting sites. I admittedly focus on the privacy aspect, but I stress that there is an important digital ethics case here.

How does AOM work

Early version of AOM elements are now already supported by several web browsers. For example Chrome Canary exposes it when a special flag is manually set (technical description of AOM is here). AOM defines a set of technical nodes making web development easier on the one hand, and facilitating the use of assistive technologies on the web. For instance, users can browse the site with the “TAB” key to change focus between the elements on the website; or use special typing/pointing assistive devices instead of a mouse, and so. Now, when we actually click on a link, sites can naturally detect it. With AOM on, HTML nodes and JavaScript APIs - links, tables, images - can listen to additional events such as “accessibleClick”, knowing then that a specialised hardware is in use. This is great because certain functionality can be tailored towards user-specific needs. It is also revealing, on the other hand. What kind of people would be using a specialised assistive hardware?

This means that the sole launch of such a JavaScript event is somewhat disclosing: it says that a certain user is a disabled person (in the considered case, that would be a vision-impairment, but you can imagine similar situation with a voice control module).

There is currently an ongoing debate around Accessibility Object Model and privacy aspects. I must say this is a very challenging issue of finding the tradeoff between privacy and accessibility. It is also good that this debate takes place.

Let’s consider a number of scenarios.

Expose without protection

When a website is listening for accessibility events and the user performs an action using assistive technology, the site may immediately conclude that the user is a disabled person. This is obviously suboptimal, to say the least.

Can we do better? The problem is a difficult one, especially when we consider how limited web platform is when isolating and guarding such functional aspects.

Ask for permission

When the user performs an action with an assistive technology, browser displays a permission prompt to the user. They may choose then whether to allow the site to consume the event. Once the user does so, the website knows that the user is a disabled person. This is better than previously: the user is in control and can decide. But it is assumed that the user is aware of what may be the implications of granting permissions. And here the message framing is everything. It is not entirely clear if the user, once asked “do you want to use assistive technology on SITE.COM?” (or similar) will understand what the consequences are.

The implications are in profiling. When the user grants the permission, the website immediately knows that the user is a disabled person, the site can potentially store this information and later adapt the site towards the user, with this information at hand. There is immediately also another huge risk once this information is shared to others. This might lead to discrimination.

The web architecture now is quite leaky (examples: 1, 2, 3), with abuses common. Some sites also simply leak information deliberately. This can happen if abusive third-party scripts are being included, or if the collected information is deliberately shared outside. But there is an inherent difference between sites sharing mouse movement analytics data, or even location data, to those potentially telling about one’s health status. When designing technical facilities unambiguously pointing towards the user traits, extra care is needed. Processing data on user disabilities is a regulated area, for example GDPR places strict bounds here (“special category data”). But the technical design anger is important in itself.

A possible different path would be to create mapping between the accessibility API and the current web API. This means that accessibility events would be translated to the standard ones, or be indistinguishable. The problem here is that it is not clear if certain concepts could always be easily translated in practice (e.g. accessibleIncrement event), and even if this was possible - whether the detection based on behavioural patterns extraction, would not be revealing in the end, anyway.

There is also another angle. Currently when we visit a website, the browser constructs the document object model tree (DOM), basically corresponding to the rendered website. With AOM, a specialised structure called Accessibility Tree will be the counterpart of the DOM. There is no doubt that this structure, when actually implemented, must be done and working for all users, regardless of using assistive technology or not. Otherwise it would need to be done on a strict opt-in basis, but here again the profiling risk pop in.

It will be interesting to observe how this transformative technology will develop. It is certainly positive. Let’s hope the best design choices can be found and implemented. The affected communities would certainly benefit from some strong research & development ideas and input here.

Summary

The security and privacy trade-off is perhaps the one known best. But there is more to impact assessments, so often it’s actually security vs privacy vs accessibility.
When rotten compromises need to be, or are made this does not always lead to best designs. The case described in this post is especially challenging. It will touch many users. It concerns sensitive information. And yet, good choices need to be made.

I'd like to thank Leonie Watson for some discussions around AOM.

Comments? Are you interested in more analyses of the kind? Feel free to reach out: me@lukaszolejnik.com