Re: Target definition

Hey Andrew,

I fully agree that adding to the understanding document is a good idea. I
also like the idea of having a note that says that "target" isn't the same
as the "target" property on a DOM event, to make this explicit.

From your last email I can't tell if you still have concerns with the
proposed change to the definition. Can you clarify?

W

On Thu, Apr 23, 2020 at 3:32 PM Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> 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.
>
>
>
> My response to this is that this interpretation doesn’t stand up to a
> reasonableness test. There isn’t an accessibility expert anywhere, and
> probably no engineer that would stand by a claim that this was what was
> intended by the WG.
>
>
>
> 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
>
>
>
> This was what my engineers and I thought that you were saying, yes. This
> seems to be a possible area of confusion similar to the definition of name (
> https://www.w3.org/TR/WCAG21/#dfn-name) where we felt the need to
> explicitly state that name is not the same thing as the name attribute in
> HTML. Perhaps we need to clarify that the target is not the same thing as
> the target property for a specific event?
>
>
>
> 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?
>
> I think that the best way is to clarify this in the Understanding document.
>
>
>
> 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.
>
>
>
> I think that adding that would still leave your #2 above as a possible
> source of confusion and we would need to clarify in Understanding.
>
>
>
> AWK
>
>
>
>
>
> 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
>
> *Error! Filename not specified.*
>
>
>
>
> --
>
> *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 Wednesday, 29 April 2020 11:11:15 UTC