Re: Target size Pre-CFC

Hi Wilco,

I think that leaves us with:

Spacing Alternative: Targets that are not 24 by 24 CSS pixels are positioned with sufficient spacing so that if a 24 CSS pixel diameter circle is centred on the bounding box of each, none of the circles intersect another such circle or target.

Hopefully we can discuss this during the meeting (after the Parsing survey), and get this out for CFC.

> On "at risk"; You didn't mention my suggestion of having the latest target size definition as a "plan B" in an "at risk" note

I thought I had, but that is the plan. The previous CR text would be the fallback. Unless you mean a different target size definition? In which case I need to pointer to that.

Kind regards,

-Alastair



From: Wilco Fiers <wilco.fiers@deque.com>
Date: Tuesday, 4 April 2023 at 11:18
To: Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Re: Target size Pre-CFC
Hey Alastair,

Thank you for revisiting this. I think this is going in the right direction, but I don't think we're there yet.

On undersized targets; I do not support keeping that term "undersized" in there. Why does the spacing exception say "undersized target", but the other exceptions just say "target"? I think it's confusing. I'm happy that it's not confusing to you. That doesn't exactly change that it's confusing to literal-minded people like me.

I'm not trying to be nit-picky here. I'll note that I didn't raise anything about the phrase "positioned with sufficient spacing", which could simply be replaced with "positioned" or "spaced". Those 3 words aren't useful to me, but it's fine. I get you're trying to lead people's thinking in a particular direction here. Using a qualifier in one place, but not another, where you mean the same thing is unnecessarily confusing.

On bounding box; I disagree with leaving this to the understanding documents. Because of how overflow works in CSS, non-rectangular targets are everywhere. I'm not sure this group has fully appreciated how difficult it is to determine the real area of a target. It's not simply the bounding box of the clickable element. It's all of that element's client rects, the client rects of every one of its descendants, reduced by any clipping from any non-scrolling ancestor, and reduced by clipping from any obscuring elements that cannot be scrolled independently, and then merging all adjacent and overlapping targets. And that still doesn't get you a single target area for just one element.

Changing "center of each" to "centered on the bounding box of each" would solve this for me. Alternatively, if you think that makes it too difficult to read, you can create a definition of "centered", or you can add a note. I can accept this being in a note. I'm not on board with doing this outside the normative document.

On user agent offset; Thanks for revisiting. I do see your point about it potentially raising more questions. It's a small enough edge case that I accept it as is.

On the use of the term "circles"; I think it would be good to be slightly more explicit when we use that term. I would suggest changing the end of the exception from "none of the circles intersect another circle or target" to "none of these circles intersect another target or another such circle". I can live with it as is, but I think this is a little clearer in that we don't mean any circle, but specifically these virtual circles centered on the bounding box.

On "at risk"; You didn't mention my suggestion of having the latest target size definition as a "plan B" in an "at risk" note. I think we need a plan B so that if, while in CR someone finds problems with this new approach, we don't need a CR 4 to correct it. I think the centered circle thing works, but we've been burned before.



On Fri, Mar 31, 2023 at 6:43 PM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Hi Wilco,

We had a discussion about this on the Friday call, and were thinking that:

  *   We probably don’t need the ‘do not qualify’ bit, that might also make automated testing easier without it.
  *   “Undersized” seems reasonably understandable, it isn’t a defined term, but we can explain that in the understanding document. You need to deliberately read more into it in order for it to be a problem.
  *   Including bounding box in the text makes it longer and is something we can explain in the understanding doc, for the unusual cases where it is needed. We had a long discussion about other methods than bounding box, but nothing stood out as a solution. Overall: This is an exception, if you can’t use it, make it bigger.

Leaving us with:
Spacing: Undersized targets are positioned with sufficient spacing so that if a 24 CSS pixel diameter circle is centered on each, none of the circles intersect another circle or target.

Are any of the things above critical for you?

Regarding the ‘offset’ in the user-agent exception, we were struggling to think of a way to include that without making the exception very difficult to apply. If spacing is added/changed, what is it compared to? Browsers defaults for spacing are tricky to analyse, e.g. from a scroll bar to things near it. Unless you’ve thought of some un-ambiguous wording?
The checkboxes example may pass this SC, but will probably fail for lack of labels?

Kind regards,

-Alastair


From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Date: Thursday, 30 March 2023 at 18:09
To: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>
Cc: WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Target size Pre-CFC
Hi Wilco,

> 1. The user agent exception is still missing "offset". I raised this before, and was under the impression this would get added in

That doesn’t ring a bell, can you point me to that?

Would that be something like this? “The size and spacing of the target is determined by the user agent and is not modified by the author;”


> 2. I don't think we should use the phrase "undersized targets". It's not necessary, and could easily be misunderstood as some new term that gives room for interpretation, as opposed to what I think it means; Targets that don't meet the initial 24 by 24 pixel requirement.
3. The phrase "meet another exception" seems odd. You don't "meet" an exception, as far as I know. I think you can qualify for an exception?

I think that would result in:
“Spacing: Targets that are not 24 by 24 CSS pixels<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG22%2F%23dfn-css-pixels&data=05%7C01%7Cacampbell%40nomensa.com%7Cdf34ec516b914a1987c208db34f5ff0b%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C638162003380453988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qxhqHgFTujLsPc24%2BPcxzZZurSzjUN8S3oTqaCWFpmM%3D&reserved=0> and do not qualify for another exception are positioned with sufficient spacing so that if a 24 CSS pixel diameter circle is centred on each, none of the circles intersect another circle or target.”

It’s getting long, and slightly hiding the intent of that bullet. I think ‘undersized’ is fairly clear, and we can confirm the meaning in the understanding doc.


4. I think the phrase "targets that do not meet another exception" is confusing. WCAG already doesn't tell you whether these lists are conditional (A, or B, or C) or additive (A, and B, and C). This wording could create confusion about if these exceptions are conditional or not. There is no logical reason to have this in a conditional. What you're saying is: A, or B, or C (if A or B are not true).

The list (like others of the type) is conditional, so on a per-target evaluation any can apply.
What this is saying is that: Don’t draw a circle on targets which are excepted by other exceptions. The circle on the undersized target would need to intersect the other target.

Otherwise, something passing via the user-agent or essential exceptions would also be part of the circles calculation, even though we’ve said they are exempt.


5. I don't think we should use "centered" here. If we mean the center of the bounding box, let's say the center of the bounding box.

In that vast majority of cases these will be the same thing, so can we use simpler language for the common case? If you come across an odd (and small) shaped target, then look in the understanding document for what to do…

Otherwise we’re getting to:
“Spacing: Targets that are not 24 by 24 CSS pixels<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG22%2F%23dfn-css-pixels&data=05%7C01%7Cacampbell%40nomensa.com%7Cdf34ec516b914a1987c208db34f5ff0b%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C638162003380453988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qxhqHgFTujLsPc24%2BPcxzZZurSzjUN8S3oTqaCWFpmM%3D&reserved=0> and do not qualify for another exception are positioned with sufficient spacing so that if a 24 CSS pixel diameter circle is centred on the bounding box of each, none of the circles intersect another circle or target.”


> 6. I think it's pretty strange that we're going for a 24 by 24 square for the main case, and a 24 diameter circle in the exception. That seems fairly inconsistent, and looks like an artifact of our writing process.

It could look like that, but the exception is there to provide flexibility for edge cases and things like rounded corners. Personally, I like the clear “24px square” of the main text.

Also, we’d have to use different language anyway. E.g. in the bullseye case we couldn’t use centered circles, it would need to be any circle in the target. Otherwise larger targets would fail.


> 7. Overall the "centered circle" approach feels flimsy to me. Bruce's bullseye example shows there are clearly some edge cases it isn't handling properly. I can live with us not handling bullseyes, and small crescent shapes icons. I'm okay with us not having the optimal answer on those for the sake of simplicity, but I am nervous about the things we haven't thought of here.

I can understand the nervousness, personally I’m calmed by the thought that it is an exception to an already quite small target size. If there are niche cases, make the targets bigger…


> We should put this in as "at risk" and add a note that allows us to use the latest version that we have of the offset definition (the one with horizontal / vertical alignment) in case we find significant problems with the centered-circle approach.

That’s the plan, we just need to get to an agreed primary text state.

Kind regards,

-Alastair


--
Wilco Fiers
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]