Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assistive technologies: tightening up the text #529

Open
hadleybeeman opened this issue Dec 4, 2024 · 3 comments
Open

Assistive technologies: tightening up the text #529

hadleybeeman opened this issue Dec 4, 2024 · 3 comments
Assignees

Comments

@hadleybeeman
Copy link
Member

In the course of discussion on #498, @matatk @hober and I tangentially found two things about the §2.9 Don't reveal that assistive technologies are being used section:

  1. It has no definition of "assistive technologies", and issue 498 made us realise that it's not always clear that we are talking about ATs at the user agent level. We could add a link to WCAG's definition of assistive technologies — though @matatk was uncomfortable that it explicitly says "(as used in this document)" and therefore may not be suitable for use in ours.
  2. We realise that the industry consensus is that sites should not have knowledge of a user's use of ATs — without discussion of a consent mechanism. It's just bad. To that end, we could remove the text "without the user's consent" from the sentence, "If an API provides access to this information without the user’s consent, this sensitive information may be revealed to others (including state actors) who may wish them harm."
@matatk matatk self-assigned this Dec 4, 2024
@alice
Copy link
Contributor

alice commented Dec 4, 2024

I misunderstood the edit, but I'm leaving the text here as context for Jamie's comment below.

There may well be good reasons why users may be be pleased to give sites (free, informed) consent to know that they are using assistive technology. There are optimisations which are not possible without revealing to the site that the user is using assistive technology. For example, a site which lazily loads data may benefit from an API allowing AT navigation commands such as "jump to next heading" or even "find text" to trigger an event or other type of listener on the site causing the relevant data to be fetched.

It is definitely tricky to weigh up how best to allow web page authors to offer an ideal experience to AT users while also ensuring that users have the opportunity to refuse consent without losing access. But I'm not sure that ruling out giving users that opportunity at all is the best solution.

@LJWatson and @jcsteh both advocated strongly for this principle; they may well have further thoughts here (and they may well disagree with me!)

@jcsteh
Copy link

jcsteh commented Dec 5, 2024

"If an API provides access to this information without the user’s consent, this sensitive information may be revealed to others (including state actors) who may wish them harm."

Even if the user does give consent (whether given freely or coerced due to broken functionality), it's still true that "this sensitive information may be revealed to others (including state actors) who may wish them harm." Consent just ensures that the user is providing this information knowingly; it provides no assurances about whether it will be used harmfully or not.

There may well be good reasons why users may be be pleased to give sites (free, informed) consent to know that they are using assistive technology.

This might seem pedantic, but I'd argue most users would never be "pleased" to give this consent. If I understood the constraints and that the site truly had no other choice other than to know this information, I might grudgingly provide consent, but I would not at all be pleased about it. The reason this distinction matters is that even if there were such a mechanism, it should be an absolute last resort.

There are optimisations which are not possible without revealing to the site that the user is using assistive technology. For example, a site which lazily loads data may benefit from an API allowing AT navigation commands such as "jump to next heading" or even "find text" to trigger an event or other type of listener on the site causing the relevant data to be fetched.

I think there are other ways we could solve both of those problems, but that's beyond the scope of this issue. Honestly, I haven't seen a use case yet which justified a consent mechanism in my opinion.

It is definitely tricky to weigh up how best to allow web page authors to offer an ideal experience to AT users while also ensuring that users have the opportunity to refuse consent without losing access. But I'm not sure that ruling out giving users that opportunity at all is the best solution.

Despite my arguments above, I could perhaps be convinced that ruling it out completely might be a step too far. This does make me wonder whether we need guidance around when such a consent mechanism is reasonable, though. For example, all information and features must be accessible regardless of consent; consent may only be used to improve the efficiency of access. But even that's a slippery slope: a site could make the experience so utterly inefficient that users felt they had no choice but to give consent.

@alice
Copy link
Contributor

alice commented Dec 5, 2024

Thanks Jamie! I realise thanks to your comment that I misunderstood the edit, but I think your comment stands anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants