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>
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>
> *Date: *Thursday, 30 March 2023 at 18:09
> *To: *Wilco Fiers <wilco.fiers@deque.com>
> *Cc: *WCAG list (w3c-wai-gl@w3.org) <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%7Cefd5dd1d11094052e1ae08db314190b9%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C638157929902928791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Kg0fyku9ZybTMTJwcZDW9%2FQqJBFEOYng4cYawz6t10E%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%7Cefd5dd1d11094052e1ae08db314190b9%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C638157929902928791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Kg0fyku9ZybTMTJwcZDW9%2FQqJBFEOYng4cYawz6t10E%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