Re: Target definition

I’ve spoken with my engineers about this and they don’t see the confusion here. The target is the area that bubbles the event up to the listener, and even if the listener is on the body that doesn’t mean that the entire page area is a target. It seems that we agree on this in terms of the intent of the SC and the question is whether the definition text is actually causing confusion.

Regarding errata – it is pretty easy to create an errata, where there is confusion is that people don’t check the errata for changes or clarification. I think that adding something as a note or in Understanding tends to be higher profile.

That said, the errata would be incorporated into 2.2 so it would be in the primary document, and perhaps even 2.1 could be republished with editorial errata.

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 9:24 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
Subject: 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.

Yes, but some people don’t think it is clear (enough) that other areas are not a target.

If you take off the example:

“Target: region of the display that will accept a pointer action”

Any area of the display will “accept” a pointer action (e.g. a tap), they just don’t do anything with it. For developers familiar with event-bubbling, this is especially confusing.

The clarity of this becomes more important with the target-spacing SC as we are talking about the target with non-target spacing around it.

I might not be weighing the hassle of errata enough though, it hasn’t been an issue whilst I’ve been a co-chair. In which case please let me know what difficulties that generates!

-Alastair