Open question: do we want a justification string?

Note: developers should not be able to determine whether accessibility is enabled based on timing information, so we shouldn't block the main thread waiting on that dialog

When I've talked about this to people in the past, the best option I could think of is to do what the browsers to with the Geolocation API. A browser setting can globally tell any site not to ask, or it can show the (out of page chrome?) banner prompt if you opt into sites allowing you to ask.

We can always add the ability to query this permission via the permissions API:
https://w3c.github.io/permissions/

But before, I'd like to understand why, exactly, "we may need to ask a user's permission before a web page is allowed to listen for accessibility input events". The OP does not state what the permission is trying to mitigate.

What are the privacy and security concerns?

Enabling authors to determine that someone is using an AT is an invasion of privacy. It effectively exposes the fact that the person has a disability, and that is information we should protect to the same extent we protect other pieces of personal information like gender, race, orientation, or faith.

Opt-in is not a solution. It asks AT users to choose between privacy and accessibility. Opt-in may be viable for geo-location, but sharing your location and sharing your disability are two distinctly different things.

I'd like to echo @LJWatson's concerns regarding privacy. It's not reasonable that my experience should be degraded unless I choose to expose the fact that I have a disability.

I realise that native applications do have access to this information. However, just because native apps do something doesn't necessarily mean it's always a good idea.

As some food for thought regarding an alternative, I question why these events need to be "accessibility specific". Why "accessibleclick" and "accessibleincrement" instead of just "click" and "increment"? In order to fill the gap in current experiences, what we really need here is input agnostic events, not accessibility specific events. "Increment" could be just as useful for cases where a user isn't using a traditional 'assistive technology". That allows for new input methods that might be used by anyone and abstracted by the operating system. Essentially, I'm suggesting something more like IndieUI Events.

Duping to #81, let’s leep discussion in one place