Accessibility Events

The question always hangs in the air, unspoken for a moment: "Is there a way to know when...?" Both client and developer understand the query, yet articulating it proves surprisingly difficult.

Initially, it seems purely technical – akin to asking about functionality on a specific device. But the hesitation reveals a deeper layer. Phrases like "assisted browsing context" don't roll off the tongue as easily as "on a phone" or "on a slow connection." The former is the language of accessibility experts; the latter, the client's everyday reality.

The question, finally voiced, is usually something like: "Is there a way to know when a user is using a screen reader?"

The answer, for a long time, was a welcome change from the typical complex web development response: "No, we can't." Technically, it's impossible; computers don't communicate that way. The "no" provided a sense of relief, confirming their unspoken assumption.

Even if technically feasible, I'd explain, it's undesirable. Detecting assistive technology use would add to our maintenance burden, not reduce it. It's analogous to the "phone-user" scenario; we can't reliably determine browsing context, and assumptions lead to problems. Each new feature would require additional work to ensure accessibility, raising the question: is the feature essential enough to justify the extra effort?

The idea of a fully featured website alongside a separate, accessible version might seem appealing. However, this approach quickly falls apart: an inaccessible main site will inevitably mean an incomplete accessible version. Creating a distinct "accessible experience" relegates it to an afterthought, mirroring the limitations of many dedicated mobile sites.

There's rarely disagreement. We've all experienced the frustration of being forced onto a subpar mobile site. We've learned from past mistakes.

Yet, the question transcends the purely technical. It's not just about browsers and screen sizes. The hesitation, the pause, the stumbling over words, transforms a mundane development question into something far more significant. The unspoken heart of the matter is: "Can we know if a user has a disability?"

The simple "no" was initially empowering, a convenient way out. But the introduction of "accessibility events" in iOS 12.2 and macOS 10.14.4 changed everything. This feature, quietly introduced, allows browsers to identify VoiceOver users. With this setting enabled (by default), a user's assumed disability is broadcast to the internet unless explicitly disabled.

(Update May 2019: Apple removed this feature.)

The outrage is justified, not only for users, but also for developers. Apple has made it possible to know if a user has a disability, opening the door to discriminatory practices. This information can be captured and used for targeted marketing or worse. All under the guise of inclusivity.

At some point, the developers of "accessibility events" were undoubtedly asked about its feasibility. Their "yes" was likely well-intentioned, a seemingly simple technical solution.

In the future, I will face similar hesitant questions. The pauses will be familiar. The easy "no" based on technical impossibility is gone. We can know if a user is using assistive technology. The information could be misused in countless ways.

But I won't participate in perpetuating Apple's mistake. My answer will be a heavy, uncomfortable "no." Not because we can't, but because we shouldn't. The "technically" excuse is gone. The answer is a firm, unequivocal No.

The above is the detailed content of Accessibility Events. For more information, please follow other related articles on the PHP Chinese website!