Re: Target definition

Hey Andrew,

Yeah, I do think we all understand this to mean the same thing. I would say
this is a clarification.

> 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

I don't think that's quite it either. You can have a button like the one
below, where there's content inside it. If someone clicks the info-icon,
that becomes the "target" property of the click event, but that isn't
necessarily the element you want to have the 44x44 size. In this example,
it should be the button. What matters is the area from which you can
achieve some specific function, irrespective of what the event target is or
where the event handler lives.

<body onclick="doStuff()">
  <button><i class="info-icon"></i> Info</button>
  ...
</body>

Taking this to a slightly more extreme example, you can have a canvas
element, where clicking different parts of it does different things. It
doesn't matter what the event target is, or where the event handler sits,
just how much the size (and shape) of that area in the canvas is that
triggers a certain function.

> 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.


Why would the errata not be incorporated into 2.1? I agree adding to the
understanding doc is a good idea too. I may have misunderstood what it
means to do an errata. Wouldn't the doc on w3.org/tr/wcag21 be updated if
we do an errata?


W



On Wed, Apr 22, 2020 at 3:55 PM Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> 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
>
>
>


-- 
*Wilco Fiers*
Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R

Attachments

Received on Wednesday, 22 April 2020 16:37:02 UTC