Analytics for Accessibility
How your users experience your websites matters. That's why you use analytics to better understand their behaviors and improve their experiences.
Traditionally, your disabled users have not been a part of this feedback loop, primarily due to privacy concerns (see Karl Groves's article on this topic of privacy for more details).
However, there are several coarse segments you can still use, including
- Whether or not they're a keyboard-dominant user
- Whether or not they prefer reduced motion in animations
- Whether or not they're using Windows High Contrast Mode to increase color contrast
None of these segments uniquely identifies disabled users. But an experience failure for any of these segments will strongly imply an experience failure for disabled users.
Enhance Your Analytics
By default your analytics tool probably won't give you information on these segments. However, you can use a few small snippets of code to change this.
For detailed instructions on how to set that up, visit the docs page.
Once that's complete, you'll be able to get answers to questions like
- Are our keyboard users finishing our checkout flow at noticeably lower rates than our non-keyboard users?
- Are our potential customers who prefer reduced motion signing up for our new product at lower rates than everyone else?
- Did our latest release cause our users relying on Windows High Contrast mode to stop being able to use our app?
Positive answers to questions like these should highly correlate with poor experiences for your disabled users.
Privacy Considerations
Privacy considerations have to go hand-in-hand with any change to analytics. Here are some of the most important aspects to consider in this case.
Only Use Aggregated Data
There are tools out there (e.g. session replay tools) that can record in detail what each individual user is doing on your site.
This approach should not be paired with such tools (or any other high-cardinality solutions) as it would chip away at the privacy of individual disabled users.
Instead, the data from this approach should only ever be viewed and analyzed in the aggregate of many users' experiences to protect each individual's privacy.
Consent Collection
This approach likely won't change how you integrate your analytics provider with your consent processes on a technical level.
However, depending on your situation you may need to let your users know that you're collecting these new pieces of information (and it's certainly a good idea to do in any case).
For details on all the new information that the enhanced analytics could gather, visit this docs section.
Contact Info
For questions, comments, or feedback, you can find me on any of the following platforms:
Prior and Related Art
I was originally inspired by this case study from Intuit called "Proving accessibility is worth it with analytics". It takes a similar mindset, though the implementation is very different.
For more on inclusive user research more generally, check out the awesome-inclusive-user-research Github repository.
The Future
This approach is currently limited in scope to what can be inferred via Javascript alone. However that doesn't necessarily have to be the case.
Other Privacy Aspects
Beyond the tool itself, there are some other aspects of privacy to consider.
Privacy Aspects of this Site
This site is hosted on Deno Deploy, so they (and their subprocessors) most likely have access to your IP address, what browser you're using, its version, and what your operating system is. I don't know yet of any way to control that but I asked on Reddit about Deno Deploy's privacy posture.
The app code running on it is completely ignoring those pieces of PII.
This site uses client-side Google Analytics 4. I tried very hard to anonymize all information sent to Google (via Google Tag Manager) and documented how I configured Google Analytics to be maximally privacy preserving in an article.
The short version is that by default Google Analytics should not be persisting any data (though data may be sent to it). To change that activate the following button (there's no need to do this outside of my own testing)
Notes on Fingerprinting and Accessibility
Device and user fingerprinting is a technique unscrupulous websites and tools use to track you and your activity across the internet, without requiring 3rd party cookies or any form of traditional tracking.
It works by using standard web APIs to measure a large number of characteristics about your device and your settings. Each individual characteristic on its own doesn't identify you, but narrows you down a little amongst all other users. The problem being when all of the characteristics are considered together, they end up narrowing down all the way to you specifically amongst all users (follow this link for more details on fingerprinting).
The web APIs in use by Analytics for Accessibility are also susceptible to being abused as fingerprinting characteristics. This is not a hypothetical, there are solutions available today that fingerprint based off of accessibility characteristics.
Sadly, there is no direct defense to fingerprinting that I'm aware of. The best that can be done is to find the offenders and block them (e.g. like the tracker blocking company Disconnect attempts to do)
Accessibility Statement
This site is intentionally minimalistic to avoid accidentally introducing issues.
If you notice anything else off let me know via one of the above channels and I will aim to fix it.