Sep 20, 2026

CSS Media Features and Privacy: A Word of Caution

Listen to this article

Speed

0:00

Working with medical software over the years has made me aware of potential ways a person’s protected info could be accidentally exposed through practical means. My first word of caution was about how unique aria-labels could expose personally identifiable information (PII) in analytic software. Something I’ve been thinking about as of late is how CSS @media features could be used to infer a person’s disability. Now, before we get too deep into this, let me start by saying that someone’s disability status is a protected class under the Americans with Disabilities Act (ADA) and a special category of personal data under the General Data Protection Regulation (GDPR) Article 9. Inferring a protected status from the user’s settings or behavioral patterns and acting on that knowledge is highly unethical and illegal. The content within this post should not be used a blueprint for such behavior. Now, with that being said, I’m sure anyone working in accessibility has been asked or has heard this question…

“Can’t we just check to see if someone is using assistive tech?”

TL;DR answer … No.

The reason is because browsers don’t expose the use of assistive tech to protect the user’s privacy and to prevent discrimination. In addition to this, assistive tech, such as screen readers, don’t run in the browser, so there’s nothing to detect.

I will acknowledge the fact that the person asking may truly not know or understand and their motivation behind asking is benign. Unfortunately, in my experience, it’s asked in conjunction with pushing back on having to make something accessible. Typically, because the person pushing back is hyper-focused on the disability related to the error and is convinced that a user with said disability does not use the product.

For example, if the UI contains a bunch of icon buttons that are missing accessible labels. A Blind screen reader user will not understand what those buttons mean. This prompts the person who is pushing back to say something like “Can’t we just detect if someone is using a screen reader?” The thought is, if it’s possible to add a band-aid “fix” or provide an alternative experience, do that instead of fixing the issue correctly. This takes on a “separate-but-equal” vibe, which is similar to the pattern that lands overlay vendors in hot water.

Another motivating factor is that the person pushing back wants to collect data to try and prove the need to make the product accessible is not necessary.

The potential risk

Knowing that we can’t detect assistive tech directly, by using JavaScript, there are CSS features that map to current Success Criteria (SC) in the Web Content Accessibility Guidelines (WCAG) that can be detected.

For example, this script checks the value of the prefers-reduced-motion feature, which is related to WCAG SC 2.3.3 Animation from Interactions. The console.log, for demo purposes, prints reduce or no-preference depending on the state.

// Example code for science only. Don't use this in prod

(function () {
  var QUERY = "(prefers-reduced-motion: reduce)";
  var mediaQuery = window.matchMedia(QUERY);

  function report(matches) {
    console.log("prefers-reduced-motion:", matches ? "reduce" : "no-preference");
  }

  report(mediaQuery.matches);

  function onChange(event) {
    report(event.matches);
  }

  if (typeof mediaQuery.addEventListener === "function") {
    mediaQuery.addEventListener("change", onChange);
  } else {
    mediaQuery.addListener(onChange);
  }
})();

Take this scenario. Say it’s a small team and they use analytics to inform their design decisions. They use this method to gain insight into how their visitors feel about the use of parallax. Before user testing became more common, my team used anonymous data to determine if our users were interacting with the tooltips at all. Turns out they weren’t. As a result, we pulled tooltips from the UI and changed the UX pattern.

However, keeping the original question about “can’t we just check?” in mind, collecting data like this crosses the line when the state of prefers-reduced-motion is used to assume the use of assistive tech and/or pairing it with a user to infer that user’s protected status. I’ve seen some weak and unsuccessful attempts to sidestep accessibility, and this argument is just as loose because it’s speculative. Just because a person has this feature active does not mean they have a vestibular disorder. They could be someone who simply can’t stand parallax animations.

Though the use of media features is very common in CSS and alone does not expose PII. It’s the connecting of the dots to expose PII that is illegal. Staying aware of how PII can be exposed and understanding the risks can help protect your users, yourself, and the integrity of your application.

Here’s a list of @media features that map to WCAG SC