Re: Target definition

I’m still not clear on what is the actual issue. It is pretty clear from the definition that an interactive area of a UI component is a target:

Target: region of the display that will accept a pointer action, such as the interactive area of a user interface component

I think that we can add a note that the group interpreted the acceptance of a pointer action as meaning that something was happening but that this isn’t worth an errata, but I’m not vehemently opposed to an errata if everyone else thinks it is needed.

Thanks,
AWK

Andrew Kirkpatrick
Head of Accessibility
Adobe

akirkpat@adobe.com
http://twitter.com/awkawk


From: Alastair Campbell <acampbell@nomensa.com>
Date: Wednesday, April 22, 2020 at 6:07 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
Subject: Target definition

Hi Andrew & everyone,

I said in the meeting I’d summaries the previous discussion on the definition of target.

The question we were trying to answer was: Is the update clarifying what we meant to cover, or is it changing the meaning?

The thread included other aspects, so I’ll print the relevant bits below in one place.

It started here with Wilco:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2020AprJun/0001.html

“In my opinion, the definition of "target" is insufficient. It needs to be specified along something like user interface component. The problem with "target", as it is formulated today anything that has an click / pointer event handler on it is a target.

Most JS frameworks today attach their event handlers to the body, or some other top level element, so the entire page is often a single touch target. I know it's not intended that way, but the phrasing of that definition "region of the display that will accept a pointer action", it's hard to argue that the element that has the event handler on it isn't the thing that "accepts a pointer action", that it's instead some other element.”

I replied:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2020AprJun/0008.html

“I don’t see the issue as (back in 2.1) we tried to define that independently of the  implementation… If you click on an area where events bubble up but do not activate anything, it is not an interactive area, therefore not a target. Of course it is possible to click anywhere, but it doesn’t lead to an action or interaction.”

Wilco replied:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2020AprJun/0010.html

“The way I read this, an interactive area is an example of a target; but this doesn't say that all targets are interactive areas. The part that I see as defining "target" does not say anything needs to happen in response to a pointer action.

Are you saying that "pointer action" refers both to the actual pointer event, and the thing that happens in response to it? If so, how can a display accept output of an event? A touch display accepts input, not output, right?”

I replied:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2020AprJun/0015.html

“To me, “accept a pointer action” means it does something with it.

Of course anywhere on the screen can be clicked/tapped, but if nothing is done with it (the “accept”), then it is not relevant.

Still, if it helps avoid confusion, we very much want to keep backwards compatibility (with the intent). We could create an errata, my proposal for that would be:
“region of the display that will accept a pointer action to trigger a function,”.”

Wilco thought that would be a good update, no one else commented.

Kind regards,

-Alastair

--

www.nomensa.com<http://www.nomensa.com/> / @alastc