Re: Target definition

Hey Andrew,

> In your example, are you saying that people would determine that the
target area for the doStuff() is the 30x30 <i> element and not the 60x44
button it lives within and therefore flag a false failure?


There are three options here:
1. My own reading of this definition, the target would be the body, because
you can click anywhere on it and have an event bubble up to it.
2. The target property of the event is the icon, basically this is ignoring
the definition and just going by what in the DOM is meant by "target". I
think that's how your engineers are explaining this
3. The button, which I think we all would agree is supposed to be the
target, problem is; how do you draw that conclusion from the actual wording
of the definition?

By adding "to trigger a function", it is made explicit that what matters
isn't the event target or the handler, but whatever area of the display can
be clicked / touched to achieve some function.

W


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

> WCAG 2.1 _*could*_ be updated to show the errata in the WCAG 2.1 document
> directly, but we’ve never been successful in doing that in the past, which
> is why the 2.0 errata are still in the errata page.
>
>
>
> In your example, are you saying that people would determine that the
> target area for the doStuff() is the 30x30 <i> element and not the 60x44
> button it lives within and therefore flag a false failure?
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Head of Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
>
>
> *From: *Wilco Fiers <wilco.fiers@deque.com>
> *Date: *Wednesday, April 22, 2020 at 12:36 PM
> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>
> *Cc: *Alastair Campbell <acampbell@nomensa.com>, WCAG <w3c-wai-gl@w3.org>
> *Subject: *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
>
>

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

Attachments

Received on Thursday, 23 April 2020 11:15:43 UTC