- From: Subramanian, Poornima (PCL) <psubramanian@hagroup.com>
- Date: Wed, 7 Dec 2022 22:23:31 +0000
- To: Wilco Fiers <wilco.fiers@deque.com>, Gregg Vanderheiden <gregg@vanderheiden.us>
- CC: Alastair Campbell <acampbell@nomensa.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
- Message-ID: <BYAPR07MB6022FF829FBE8A087E3FCB13C01A9@BYAPR07MB6022.namprd07.prod.outlook.com>
Though I agree with the fact this SC may not be passed for all elements that could cause trouble in meeting the compliance, I like the way a minimum px level is defined as a guide for design. As it's not easy to bring as many examples as exceptions, in my opinion, an exception could be something like 'if the 200% zoom can satisfy the 24 px size wherever visual spacing is limited e.g. footers, mobile resolution'. Thank you Best, Poornima From: Wilco Fiers <wilco.fiers@deque.com> Sent: Wednesday, December 7, 2022 11:35 AM To: Gregg Vanderheiden <gregg@vanderheiden.us> Cc: Alastair Campbell <acampbell@nomensa.com>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org> Subject: [EXTERNAL] Re: Target size CAUTION: This email originated from outside of the organization. ________________________________ Hey folks, I automated this SC for axe-core a couple months back and have been testing it out in different environments. By far the most common issue I see come up is from link stacks. Table of content, sidebar navigation, links lists in the footer, that kind of stuff. Most sites I looked at meet the 24px target. I don't think WCAG 2.2 is pushing the boundary beyond what is already standard practice. But then there are a good number of sites that have issues, including the footer on the W3C website that don't meet this minimum. I think it's really a good thing that we draw a line in the sand here that says "to there and no further". Honestly, 24 pixels seems pretty good to me. Obviously larger tends to be better. The same is true for many things in accessibility. But we need to set a minimum IMO. We have some loose ends to tie, but these don't look like deal-breakers to me. On Wed, Dec 7, 2022 at 6:42 PM Gregg Vanderheiden <gregg@vanderheiden.us<mailto:gregg@vanderheiden.us>> wrote: Boy Alastair - that is a good question. As others point out - there are places where this is a real problem. But it is not clear that we have found a solution to it - that doesnt cause other problems - or is not applicable in other situations. So we are stuck between a rock and a hard place (not unusual for WCAG WG). Sometime we have been able to negotiate this with a conditional (only applied here) or with exceptions (doesnt apply here -only ) * Using conditionals risks missing things if it is a list - but works if it the conditions focus on the problem itself * using exceptions is dangerous because you never think of all the places this should not apply For this one - my mind keep reeling. It combines important with collisions where it should not or can not be applied. No doubt there is a problem But I don't think we have the wording yet to make a solution fly Maybe - we find out the most egregious places and make a conditional that focuses on them? (Though I can't think of how to do this either) Hmmmmm continuing to ponder gregg ------------------------------ Gregg Vanderheiden gregg@vanderheiden.us<mailto:gregg@vanderheiden.us> On Dec 7, 2022, at 2:48 AM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote: Hi folks, I may be having a moment of (self) doubt on target size, trying to work through the various issues and possibilities on the spacing and inline exceptions. As mentioned in the survey, some people in the group (including people from the mobile TF) are concerned about the effectiveness of the SC. I want to check if the effort to resolve the remaining issues is worthwhile, or I'm falling into the sunk-cost fallacy<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.behavioraleconomics.com%2Fresources%2Fmini-encyclopedia-of-be%2Fsunk-cost-fallacy%2F&data=05%7C01%7Cpsubramanian%40hagroup.com%7Ce694c85cf83d4f79946b08dad88a4b23%7C9e37b9e905de4906b089536f19689074%7C0%7C0%7C638060385726672782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eo1gyiIzUmBWdgB7fmV0wYXX1MaCAwG2RtHh6dpnqO4%3D&reserved=0>. On the positive side: * Everyone knows small targets are problematic, and much more so for people with mobility impairments. * We have done considerable honing of the SC. On the negative side: * When you look around at most sites, particularly those which have put effort into the display on mobile devices, they tend to easily pass the SC. * Most things which are under 24px seem to fall into one of the exceptions anyway, either with spacing or being in text. * The most common fails I can find are on adverts (e.g. close buttons), and those ads also fail several other SCs already for other reasons. (I.e. they are unlikely to meet this SC either.) * Depending on the definition of "inline" we use, it will either provide quite a sweeping exception, or a relatively narrow one and capture a lot of (arguable) ok targets. It will also have a lot of potential for arguments. * Whichever definition of spacing we use will have some odd effects, either how to test it, or what passes. * Other SCs like text-spacing and reflow provide methods for increasing the size of targets in some circumstances. A lot of the problems this SC faces are inherent in the web, where the same site is provided to small touch screens and larger screens with a mouse/trackpad. Someone with low-vision and zoomed-in may not want larger targets in the toolbar for an editor. But it's the same interface as someone with good vision and tremors. If we could have a guideline that said "targets should be >44px unless there's a good reason not to", it would be fine. But in a binary pass/fail scenario that could become a legal requirement... Am I off base? Can anyone talk me down? Kind regards, -Alastair -- @alastc / www.nomensa.com<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nomensa.com%2F&data=05%7C01%7Cpsubramanian%40hagroup.com%7Ce694c85cf83d4f79946b08dad88a4b23%7C9e37b9e905de4906b089536f19689074%7C0%7C0%7C638060385726672782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cghSapWuugDT%2FwMIqV3KsJzym5vNlzIS%2BX%2Fm8WUmYxY%3D&reserved=0> -- Wilco Fiers Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force [cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4] The information contained in this email and any attachment may be confidential and/or legally privileged and has been sent for the sole use of the intended recipient. If you are not an intended recipient, you are not authorized to review, use, disclose or copy any of its contents. If you have received this email in error please reply to the sender and destroy all copies of the message. Thank you. To the extent that the matters contained in this email relate to services being provided by Princess Cruises and/or Holland America Line (together "HA Group") to Carnival Australia/P&O Cruises Australia, HA Group is providing these services under the terms of a Services Agreement between HA Group and Carnival Australia.
Received on Wednesday, 7 December 2022 22:23:50 UTC