Re: Script for calculating distance between UICs

________________________________
From: Shawn Lauriat <lauriat@google.com>
Sent: Monday, October 14, 2019 5:06 PM
To: Abma, J.D. (Jake) <Jake.Abma@ing.com>
Cc: Wilco Fiers <wilco.fiers@deque.com>; public-mobile-a11y-tf@w3.org <public-mobile-a11y-tf@w3.org>; Alastair Campbell <acampbell@nomensa.com>
Subject: Re: Script for calculating distance between UICs

Kathy mentioned that you, Shawn, possibly already have a script for that but as far as I remembered you only mentioned at TPAC that it "could be done". If you have something already we're very interested.

You remembered correctly, I do not have a script written for this.

Wilco, to answer your questions in my understanding of 2.2 SC Spacing Between Touch Targets<https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit> (others closer to this work, please correct me as needed!):

What exactly are you measuring the distance of? From the center point? From the corners? From the center of each edge?

Essentially a 2D hit test between all interactive elements on the screen (excluding mid-sentence things like links), the distance between the closes points on the boundaries of the interactive spaces.

Do you want to include elements that are close to each other because the user scrolled them to be close to each other? Do you want to ignore things in different scrollable regions?

If I wrote it, I'd probably start by just testing a given snapshot of the page, regardless of scrollable areas. A more robust testing script could run on an infinite loop or something in order to continually test rendering, interrupting or logging when elements get too close to each other (whether from scrolling or other interactions).

Do you need it to work across iframes?

Probably, since so many dialogs and third-party integrations happen in iframes these days, so at that point a browser extension would need a background page collecting all of the coordinates from each frame in the tab to handle the hit test logic holistically.

Do you want to take irregular shapes into account, such as those in wrapping text, SVG path elements, area elements on image maps, stuff with rounded corners / clipped using CSS path, shaped using CSS transform?

Mostly yes (the proposed SC excludes in-text things like links), though I'd call a script that doesn't handle those still useful, since it'd still catch the vast majority of cases in web pages. I would guess that 2D hit tests for complex (not predeterminable) shapes exist readily in things like canvas-rendered games, which would make this a lot easier to put together if open source and reusable JavaScript already handles that math, especially in a performant way that games tend to require.

The test would also need to take modality of panels and true visibility (visible and not completely covered by something else) into account, probably the most difficult and nuance-y aspect of this (since things like menus can have overlays making them modal, though they lack the semantics). The example of Amazon's top menu illustrates this in a way that looks like it passes this proposed SC even though it would fail an automated the hit test: expand the "Accounts & Lists" pane, which then covers other visible interactive elements. You can make the argument that they should use a modal dialog for that and aria-hide the rest of the DOM (you can navigate behind the panel with a screen reader, even if you can't click on things with the mouse), but I'd expect other similar examples of expanded states and overlays that would easily trigger hit detection (open menus in Google Docs overlap the toolbar and editable area below it - should each menu item have padding added to pass this SC?).

Probably the least complicated to make a hit test extension that exposes interactive elements too close together by the SC's requirements, and let a human being make the judgement call of whether it fails (already needed for the "Essential A particular presentation of the target is essential to the information being conveyed." bit, anyway).

Hope that helps!

-Shawn

On Mon, Oct 14, 2019 at 6:59 AM Abma, J.D. (Jake) <Jake.Abma@ing.com<mailto:Jake.Abma@ing.com>> wrote:
Thank you so much WIlco,

This will be enough food for further discussion I think.
Let me pass it to the MATF TF and see what we come up with.

Cheers,
Jake
________________________________
From: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>
Sent: Monday, October 14, 2019 12:54 PM
To: Abma, J.D. (Jake) <Jake.Abma@ing.com<mailto:Jake.Abma@ing.com>>
Cc: Shawn Lauriat <lauriat@google.com<mailto:lauriat@google.com>>
Subject: Re: Script for calculating distance between UICs

Hey Jake,
It depends a bit on how you would want to do it. What exactly are you measuring the distance of? From the center point? From the corners? From the center of each edge? Do you want to include elements that are close to each other because the user scrolled them to be close to each other? Do you want to ignore things in different scrollable regions? Do you need it to work across iframes? Do you want to take irregular shapes into account, such as those in wrapping text, SVG path elements, area elements on image maps, stuff with rounded corners / clipped using CSS path, shaped using CSS transform?

It can get pretty complicated. A simple version takes minutes of Googling. I found this one: https://codepen.io/ZachCB/pen/apMdwG?editors=0010 A more sophisticated one, one I'd be happy with for axe would probably take a few days to develop and test.

I would suggest you remove the word "adjacent" from the proposal. It raises more questions than it answers. Can something not be adjacent and still be within that 8px distance? Also I think you need to define what distances you are actually measuring. If you measure 8px between the center of the two closest edges you get something quite different from when you measure it from the corners:

Example 1: Close centers of edges:
|------|  |------|
| elm1 |  | elm2 |
|------|  |------|

Example 2: Close corners:
|------|
| elm1 |
|------|  |------|
          | elm2 |
          |------|

If you take these examples, the corners are at the same distance in example 1 and example 2, but the distance between the center of the two closest edges if bigger in example 2 than it is in example 1, which seems to me like what you may want. That works well for rectangles, but for other shapes you may want another solution.

Hope that helps get you in the right direction. The TLDR version of it is, I need the spec to be more precise to be able to write it. This leaves a lot open to interpretation.

W







On Mon, Oct 14, 2019 at 9:07 AM Abma, J.D. (Jake) <Jake.Abma@ing.com<mailto:Jake.Abma@ing.com>> wrote:

FYI: https://www.w3.org/WAI/GL/mobile-a11y-tf/track/actions/77
________________________________
From: Abma, J.D. (Jake)
Sent: Monday, October 14, 2019 9:05 AM
To: Shawn Lauriat <lauriat@google.com<mailto:lauriat@google.com>>; Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>
Subject: Script for calculating distance between UICs


Hi Shawn / Wilco,

For the possible new 2.2 SC Spacing Between Touch Targets we're wondering if you could help us with a script for calculating the distance between touch targets.

https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit

Kathy mentioned that you, Shawn, possibly already have a script for that but as far as I remembered you only mentioned at TPAC that it "could be done". If you have something already we're very interested.

Wilco, can you indicate what time it will take to make this script if Shawn doesn't have it or if you have to add it to axe?

In short the calculations has two challenges:


  *   Calculate all distances between touch targets, also when flexbox, percentages and grids are used (calculated on basis of screen position...?!)
  *   How to deal with all different view ports / break points (possibly 100s!)

Cheers,
Jake

-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------


--
Wilco Fiers
Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R
[X]

-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------

-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------