- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Tue, 24 Nov 2020 14:50:59 +0000
- To: "WCAG list (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>
- Message-ID: <DB8PR09MB33398B308A452D136111DBEDB9FB0@DB8PR09MB3339.eurprd09.prod.outlook.com>
I’m not sure there is a good word in English for “the thing plus its spacing”? I didn’t think the spelled-out version was much more wordy though: The size and spacing of a target is at least 24 CSS pixels, measured from the farthest point of the target to the nearest point of each adjacent target, except if: -Alastair From: Michael Gower > I'm not sure "displacement" is the right word for this SC. I'd encourage us to consider "offset", then. "the amount or distance by which something is out of line." I do think something that conveys the sense that what we care about is how the targets are juxtaposed to one another will be helpful. Like I said, I'm 'okay' with distance, but I'd love a term that more clearly conveys the notion of assessment targets relative to one another. Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Melanie Philipp <melanie.philipp@deque.com<mailto:melanie.philipp@deque.com>> To: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> Cc: Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>>, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>, Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Date: 2020/11/23 06:33 AM Subject: [EXTERNAL] Re: Target spacing refinement ________________________________ I'm not sure "displacement" is the right word for this SC. The... This Message Is From an External Sender This message came from outside your organization. I'm not sure "displacement" is the right word for this SC. The definitions for "displacement" that I find generally involve movement: e.g., movement of something from point A to point B or the displacing of an object by another (as in displacing fluid by a floating body). https://www.merriam-webster.com/dictionary/displacement While "distance" can also apply to the movement of an object, it is also commonly used when measuring the distance between two objects, and is, I think, more appropriate for this SC. https://www.merriam-webster.com/dictionary/distance Melanie Philipp, CPACC, WAS | Senior Digital Accessibility Consultant | 540-848-5220 Deque Systems - Accessibility for Good www.deque.com<http://www.deque.com> Join me at axe-con<http://deque.com/axe-con>2021: a free digital accessibility conference. On Mon, Nov 23, 2020 at 5:40 AM Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> wrote: Hey folks, > Nested or Overlapping : If a target overlaps, or is enclosed within another target, each target has an area of 24X24 CSS pixels with no other targets This creates various other issues. In my examples (https://codepen.io/wilcofiers/pen/abZxPow?), that would cause I2, J2, K1 and K2 to fail. How about an exception like this: - Large: Any target larger than 24 by 24 CSS pixels must instead have an area of 24 by 24 CSS pixels within it that has no other targets. > So I think we're right back at the core question: idiot-proof outliers, or help improve common design conventions? Well, another way to put that is "do we want false positives and false negatives in the success criteria"? I don't think that's something we can avoid, we're going to miss things. But I don't think we should publish an SC that we know has them. Wilco On Mon, Nov 23, 2020 at 6:40 AM Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> wrote: Yeah, I realized that gap earlier, but I also have to ask: Is our job to prevent someone from making a truly horrible user experience for everyone, or ensuring that more common designs are more accessible? I was assuming that the nested guideline was there in a situation where a large target had a smaller target inside -- with the intent to make sure the smaller target was operable. I believe you can pass this SC by putting a 24x24 inside a 25x25 target. But who would ever buy-in for designing what amounts to a 1-px stroke target? So I think we're right back at the core question: idiot-proof outliers, or help improve common design conventions? Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> To: Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> Cc: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>, Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Date: 2020/11/22 11:33 AM Subject: [EXTERNAL] Re: Target spacing refinement ________________________________ Hey folks, No preference on "displacement". I was looking to... This Message Is From an External Sender This message came from outside your organization. Hey folks, No preference on "displacement". I was looking to implement this as an experimental rule in axe-core when I realised this has a gap in it still. I updated my examples: https://codepen.io/wilcofiers/pen/abZxPow The particular example is H4, two elements 24x24 pixels, on top of a 36x60 element. The outer element has a distance of 30px from its farthest point to the closet point of either element, despite the element having very little space available. Any thoughts on how to address this? [cid:image002.png@01D6C271.39057400] Wilco On Fri, Nov 20, 2020 at 6:28 PM Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> wrote: I'm actually quite happy with 'displacement'! I could also go with substituting "offset" or another 'synonym'. Does that work better for you, Alastair?. I'm not rejecting "distance", but I think 'displacement' does a better job of conveying that we are talking about how to improve operability, we need to assess the positioning of two objects relative to each other. Here it is in full, to take in how it all shakes out. I changed the title (again). Still not entirely satisfied with that, but the SC text is more important IMO. i also did minor tweaking to Nested. Distinct Pointer Targets The displacement between targets is at least 24 CSS pixels, where the displacement is measured from the farthest point of one target to the nearest point of an adjacent target, except if: * Inline: The target is in a sentence or block of text; * User Agent Control: The size or spacing of targets is determined by the user agent and is not modified by the author; * Nested: A smaller target is enclosed within another target and the smaller has a minimum height and width of 24 CSS pixels. * Essential: A particular presentation of the target is essential to the information being conveyed. I haven't included Wilco's Diameter exception, because I couldn't figure out what it was covering that isn't covered now. Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> To: Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> Cc: Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>, Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> Date: 2020/11/20 08:46 AM Subject: [EXTERNAL] RE: Target spacing refinement ________________________________ Displacement doesn’t seem right, but I can’t think of a more appropriate... This Message Is From an External Sender This message came from outside your organization. Displacement doesn’t seem right, but I can’t think of a more appropriate term. I’m in two minds about whether it’s an improvement, I tried re-writing it and almost ended up back where it was: The size and spacing of a target is at least 24 CSS pixels, measured from the nearest point of each adjacent target to the farthest point of the current target, except if: ? -Alastair From:Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> Sent: 20 November 2020 16:14 To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> Cc: Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>>; WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> Subject: RE: Target spacing refinement I hear you, Alastair. How about we consider something like "displacement". 'The displacement between targets is at least 24 CSS pixels, where the displacement is measured between..." In regards to Wilco's 'either direction' I think that is very simply clarified in the Understanding doc. Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> To: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>, Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> Cc: Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Date: 2020/11/20 02:43 AM Subject: [EXTERNAL] RE: Target spacing refinement ________________________________ Hi everyone, I find the concept of measuring ‘between targets’... This Message Is From an External Sender This message came from outside your organization. Hi everyone, I find the concept of measuring ‘between targets’ and then measuring througha target odd, but I might be in a wood-for-the-trees situation. If others find it at least as understandable as the other options, then it works for me. -Alastair From:Wilco Fiers Hey folks, Rereading Mike's suggestion freshly caffeinated. I think this works. The "from either direction" thing I raised is probably sufficiently addressed just because it says "at least 24px", so if it passes measured one way, but not measured the other way there's nothing in the SC text that might lead someone to conclude that is okay. Glad to see we may have a solution! Wilco On Thu, Nov 19, 2020 at 7:47 PM Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> wrote: Okay, I'm going to remove both of those preambles, rename the SC, and make it a bit wordier. Is this easier to parse? Adjacent Pointer Targets The distance between targets is at least 24 CSS pixels, where the distanced is measured between the farthest point of one target and the nearest point of an adjacent target, except if: Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> To: Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>>, Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> Cc: Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Date: 2020/11/19 09:59 AM Subject: [EXTERNAL] RE: Target spacing refinement ________________________________ I think it helps to establish the focus at the start with “For each... This Message Is From an External Sender This message came from outside your organization. I think it helps to establish the focus at the start with “For each target”. The problem is that we can be dealing multiple adjacent targets, so the “furthest point” changes depending on the adjacent targets. I.e. it will be a different point for each adjacent target. Starting with the “furthest point” makes it seems like there is only one. Does swapping it around help? For each target, the distance from the closest point of each adjacent target to the farthest point of the current target is at least 24 CSS pixels, except when: When it is that way around it implies: “…to the farthest point of the current target [from the adjacent target] is at least 24 CSS pixels”. -Alastair From:Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>> Sent: 19 November 2020 17:11 To: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> Cc: Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>>; Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>; Sarah Horton <sarah.horton@gmail.com<mailto:sarah.horton@gmail.com>>; 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 spacing refinement This might be better For a target, the farthest point on the target is at least 24 CSS pixels away from any point on each of its adjacent target, except if : On Thu, Nov 19, 2020 at 12:09 PM Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>> wrote: For all adjacent targets, the farthest point of one target is at least 24 CSS pixels away from the other target, except if: I see what you're saying. Definitely agree that the understanding document will help clarify. The current wording (above) still remains ambiguous with level 1 confusion of what is 'one' and what is 'other' and level 2 runs into the same problem as the second wording of not specifying where on the 'other target' and might be interpreted as picking one point. How's this? For each target, the farthest point on the target is at least 24 CSS pixels away from any point on each adjacent target, except if : On Thu, Nov 19, 2020 at 11:38 AM Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> wrote: Sorry, accidental send.... The distance between the farthest point from a given target to any point on all adjacent targets is at least 24 CSS pixels, except if: The problem here is that it now suggests to pick one point in the target that is furthest away from every adjacent target, instead of picking a different point for each adjacent target. I understand the lack of specificity in what I'm suggesting, but this language is accurate. I think the way to create more clarity on how to test this is better done in the understanding document. Wilco On Thu, Nov 19, 2020 at 5:24 PM Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> wrote: Hey Sukriti, I looked at phrasing the SC the way you suggest before: The distance between the farthest point from a given target to any point on all adjacent targets is at least 24 CSS pixels, except if: The problem On Thu, Nov 19, 2020 at 4:36 PM Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>> wrote: For all adjacent targets, the farthest point of one target is at least 24 CSS pixels away from the other target, except if: The language here is pretty confusing - we need to be more clear about what is 'one target' and what is 'other target'. Here's a crack at one The distance between the farthest point from a given target to any point on all adjacent targets is at least 24 CSS pixels, except if: On Thu, Nov 19, 2020 at 10:30 AM Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> wrote: Actually, we could even consider making diameter a defined term, thus making those measurements normalized. Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Michael Gower/CanWest/IBM To: Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>> Cc: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>, Sarah Horton <sarah.horton@gmail.com<mailto:sarah.horton@gmail.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>, Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> Date: 2020/11/19 07:27 AM Subject: Re: [EXTERNAL] Re: Target spacing refinement ________________________________ Suktriti, I think the various methods of calculating the diameter of shapes (rectangle, triangle) can be provided in the Understanding document, including for irregular shapes. Note that the language Wilco put forward (and for which I have suggested minor edits) would replace the language you have listed. The preamble would become the following (with the addition of a new diameter bullet) For all adjacent targets, the farthest point of one target is at least 24 CSS pixels away from the other target, except if: Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Sukriti Chadha <sukriti1408@gmail.com<mailto:sukriti1408@gmail.com>> To: Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> Cc: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>, Sarah Horton <sarah.horton@gmail.com<mailto:sarah.horton@gmail.com>>, Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Date: 2020/11/19 07:14 AM Subject: [EXTERNAL] Re: Target spacing refinement ________________________________ Thank you Alaistar, Wilco, Detlev and Michael for all the examples,... This Message Is From an External Sender This message came from outside your organization. Thank you Alaistar, Wilco, Detlev and Michael for all the examples, those are incredibly helpful! While I like the approach of diameters from a mathematical standpoint, it might be confusing when implementing as a developer, given most targets are confined in rectangular spaces, even if the visible targets might be irregularly shaped. This was brought up before and the group decided not to pursue that route for similar reasons. I have one small edit to #5 to clarify where on the adjacent target. The SC reads, where "from the closest edge" is the new text : For each target, the distance from the closest edge of each adjacent target to the farthest edge of the current target is at least 24 CSS pixels except when” On Thu, Nov 19, 2020 at 10:05 AM Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> wrote: Wilco and Detlev, thanks for working up another treatment. I agree with Wilco that the parenthetical wording isn't required (it can be clarified in the Understanding), so we end up with For all adjacent targets, the distance from the farthest point of one target is at least 24 CSS pixels away from the other target, except if: * Diameter: The smallest diameter is at least 24 CSS pixels; I believe this rewording could even be further reduced by having "distance from the" removed, to become For all adjacent targets, the farthest point of one target is at least 24 CSS pixels away from the other target, except if: Wilco, thanks for all those examples. My only request going forward if you ever go to this trouble again, that you label or otherwise provide a key for your expected outcome. (made up example: 'All example Ds should fail'). That would help each of us scan to see if we're in agreement on that outcome, and then scan to see what the real outcome was. IMO, a matrix of examples like this would be beneficial in the Understanding document. Sarah, I echo Alastair's comments on size. For example, those little Xs in the corners of dialogs are universal (and have another mechanism for dismissal on the desktop, via the keyboard) and if we come up with wording that fails them, we would have a hard time getting traction. Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> To: Sarah Horton <sarah.horton@gmail.com<mailto:sarah.horton@gmail.com>> Cc: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>, "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Date: 2020/11/19 04:58 AM Subject: [EXTERNAL] RE: Target spacing refinement ________________________________ Hi Sarah, We do have an SC that addresses target size, but it is... This Message Is From an External Sender This message came from outside your organization. Hi Sarah, We do have an SC that addresses target size, but it is at AAA. This is the “other” SC that allows more flexibility so is aiming at AA. If we try and incorporate a minimum size as well as size+ spacing into one SC, I think that would make it more convoluted. Also, if the user-need is met by targets+spacing (as described in the previous email), we would get significant push-back on asking authors to spend lots of time doing things that don’t actually help users. I appreciate the need, but we also have to note that it conflicts with other needs, such as some people with low-vision (https://github.com/w3c/wcag/issues/1381) and the ability to create information-dense interfaces. We’ve reduced the size requirement to compromise, it’s then a balance between competing requirements. With user-group conflicts the better approach is often personalisation options rather than author requirements. So the question becomes: Is this SC a baseline worth having? Kind regards, -Alastair From:Sarah Horton <sarah.horton@gmail.com<mailto:sarah.horton@gmail.com>> Sent: 19 November 2020 11:22 To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> Cc: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>; 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 spacing refinement Without an SC that addresses minimum target size I think this target spacing SC is going to end up confusing and convoluted, and will not address the real and significant user need for a minimum target size. What about trying for two new SCs, one for target size and one for target spacing, either as part of the WCAG 2.2 effort or in whatever comes next (2.3 or 3.0)? Best, Sarah On Nov 19, 2020, at 11:06 AM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote: > The only two that I question are A4 and D1. Those are just so small... If we added an absolute minimum diameter of 12px for every target those two would fail without changing any of the other ones. Part of the reasoning for this SC was that, in touch-scenarios, the devices use heuristics to guess which thing you meant to tap. I.e. if you tap reasonably close to a link it generally works because the device finds the nearest link. However, if you have small links close to each other that heuristic can make the wrong choice because you accidentally tapped closer to an adjacent target. That’s why it is size+spacing rather than just size, and why we weren’t trying to set a minimum size as such. (Although it Patrick were reading this, he’d pipe in with “what about mouse users?”, which is fair, but it’s hard to accomplish everything in one SC.) Also, I’m worried about adding complexity to (necessarily) convoluted SC text… -Alastair From:Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> Sent: 19 November 2020 10:36 To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.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 spacing refinement Hey Alastair, You are correct, I made a mistake on H3. There is just enough space for the outer box to pass. I've fixed that, and added an example that's similar but where the box is rounded (N1 - N4) As for E3 and E4, I think it is okay for those to fail. They are more difficult to hit than some of the other fails like G4 and H4. I think this actually strikes a good balance. The only two that I question are A4 and D1. Those are just so small... even if someone isn't likely to hit the wrong thing, it'll be hard to hit. If we added an absolute minimum diameter of 12px for every target those two would fail without changing any of the other ones. On Thu, Nov 19, 2020 at 2:04 AM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote: HI Wilco, That’s great! Thanks for putting that together. > Unfortunately, none of the proposals actually gets all of them right. I think we might need to discuss ‘right’ in this context. The previous wording from the FPWD did allow examples like E3/E4 assuming there were no other targets to consider: <image007.png> But is that a good thing? The newer wording means that the proximity of the small targets to another target causes a fail. I think that aligns with the intent. When we get down to the overlapping examples I’m not sure that interpretation is correct? Taking H3 as an example: <image008.png> The red square is 60 wide, the green is 24 + 12 left-padding, so there is 24px of the parent on the right-hand side. With a wording of “For each target, the distance from each adjacent target to the farthest edge of the current target is at least 24 CSS pixels except when” The green target fits the exception bullet, but for the red one: * We can consider the green target as “adjacent”; * The farthest edge of the red target from the green target is 24px – pass. I agree that H4 would fail, and I think most of the others. I’m not clear about L2, I can’t see how much space is between those circles? For a circle I think we have to treat the furthest point as the ‘edge’. Kind regards, -Alastair From:Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>> Sent: 18 November 2020 16:16 To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> Cc: Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>>; 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 spacing refinement Hey folks, I did what I always do when rules get too complex. I write test cases. Here's what I wrote. I used color gradients to indicate passes and fails. Light green to dark green is passed, dark red to pink is fail. https://codepen.io/wilcofiers/pen/abZxPow Unfortunately, none of the proposals actually gets all of them right. So this is going to need more work. I'll see if I can come up with a proposal that gets all cases right. Probably worth for folks to have a look, see if we're all in agreement on these. Maybe most noteworthy are E3 and E4. Those corner blocks pass with the currently published SC text, but they fail in all of the new . On Wed, Nov 18, 2020 at 4:41 PM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote: Hi Michael, Tackling the second one: > The distance from each target's mid-point to the mid-point of adjacent targets is at least 24 CSS pixels, expect when... Measuring from mid-points allows for tiny targets next to larger ones, e.g: <image009.png> Although easier to understand (slightly), I don’t think it aligns to the goal quite as well. For the re-write of option 5, I think it would need to start with the thing you are evaluating, e.g: For each target, the distance from each adjacent target to the farthest edge of the current target is at least 24 CSS pixels except when: If others think that scans ok, I’m happy with that. Regarding the ‘objectives’, I think we can easily include that on the new understanding docs at the top of the intent, and work back through the 2.1/2.0 docs later. The upcoming re-design looks like this for the understanding doc: https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-understanding.html We can add a CSS class to the objective paragraph and work out the styling in parallel. Cheers, -Alastair From:Michael Gower I agree option 5 seems to scan best, but I also think there is a missing preposition. There are 2 ideas here: 1) we are talking about the edge farthest from an adjacent target 2) we are talking about the distance from that edge to the adjacent target (or between them) So I think we need 2 prepositions, one to describe which edge and one to describe the distance between two points. i think a rejig of the sentence still allows that to scan okay: The distance from each adjacent target to the farthest edge of the current target is at least 24 CSS pixels. I think we need to bear in mind that this is a design-centric consideration. As such, it is even more important to get the language/concept simple. As such, I want to advocate for a variation I pasted into the channel yesterday: The distance from each target's mid-point to the mid-point of adjacent targets is at least 24 CSS pixels, expect when... AWK said that this wouldn't work for some edge cases, but I'd like to see some examples to understand what gets through the net. Regardless of wording, this is another SC where a quick blurb summarizing the objective would help with rapid comprehension. For instance: Objective: Ensure separation of targets for ease of operation. I wrote such blurbs for all the 2.1 additions, which were supposed to be included in the Understanding documents, but were never incorporated. Michael Gower Senior Consultant in Accessibility IBM Design 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com> cellular: (250) 661-0098 * fax: (250) 220-8034 From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> To: "WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>)" <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>> Date: 2020/11/17 04:34 PM Subject: [EXTERNAL] Target spacing refinement ________________________________ Hi everyone, After the long discussion on target spacing today,... This Message Is From an External Sender This message came from outside your organization. Hi everyone, After the long discussion on target spacing today, I tried to collate the options into one place and add a couple of diagrams: https://docs.google.com/document/d/1Q9zWT1OjdCrts2xuadVEaJ2wpyLzxnysFQCSTs72L2o/edit?usp=sharing Personally, I’m leaning towards option 5 as the simplest which measures the size+spacing of the target, which would be: For each target, the distance of the target’s edge farthest from each adjacent target is at least 24 CSS pixels, except when: * [3 bullets unchanged] * Nested: The target is enclosed within another target and has a minimum height and width of 24 CSS pixels. If you’d like to add something (options, positives/negatives, diagrams etc) please let me know and I’ll add you as an editor of the doc. It is open for comments. Kind regards, -Alastair -- @alastc / www.nomensa.com<http://www.nomensa.com/> -- Wilco Fiers Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R Join me at axe-con<http://deque.com/axe-con>2021: a free digital accessibility conference. -- Wilco Fiers Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R Join me at axe-con<http://deque.com/axe-con>2021: a free digital accessibility conference. -- Wilco Fiers Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R Join me at axe-con<http://deque.com/axe-con>2021: a free digital accessibility conference. -- Wilco Fiers Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R Join me at axe-con<http://deque.com/axe-con>2021: a free digital accessibility conference. -- Wilco Fiers Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R Join me at axe-con<http://deque.com/axe-con>2021: a free digital accessibility conference. -- Wilco Fiers Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R Join me at axe-con<http://deque.com/axe-con>2021: a free digital accessibility conference.[attachment "deque_logo_180p.gif" deleted by Michael Gower/CanWest/IBM] -- Wilco Fiers Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R Join me at axe-con<http://deque.com/axe-con>2021: a free digital accessibility conference.
Attachments
- image/png attachment: image002.png
Received on Tuesday, 24 November 2020 14:51:22 UTC