Extended meetings Pt1 Minutes

Hi Everyone,

Here are the minutes from the early meeting this morning:
https://www.w3.org/2020/03/24-ag-minutes.html

Items 1-3 are from this morning, other items will be added with the second meeting.

Important: We'll be deciding on Touch Target spacing at the start of the 1st meeting tomorrow, 15:00 - 17:30 GMT / 11:00 - 13:30 Boston.

Overview of the meeting:

  *   Custom interactions: We decided to defer this one, the crux being that the interaction (e.g. keyboard short-cut, gesture) could be standard or not, but it is whether the result is expected or not that is the issue, and that is very hard to define.
We probably need some more research on that aspect to take a different approach to the issue, and possible solutions.

  *   Dragging: We approved this for inclusion in the draft, pending a review to the understanding & techniques.

  *   Touch target spacing: Long discussion, the core issue being that the user-need is for reasonably large (and/or separated) targets, and an interface need to have visually compact menus / toolbars.

We left Touch Target Spacing open and we will give it the first 10 minutes tomorrow.

The edited version is here:
https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#heading=h.6u4xclqrczua

What changed were the exceptions, which are now:

  *   Resize: A mechanism is available to change the size of all targets so that the width and height is at least 44 CSS pixels;
  *   Inline: The target is in a sentence or block of text;
  *   Layers: If the target is part of additional content (such as a menu drop-down), the targets from the lower layer are not in scope for the targets on additional content;
  *   Essential: A particular presentation of the target is essential to the information being conveyed.

However, there is still a problem which I'll try to summarise:
There is a trade-off where making menus/toolbars meet 44px size/separation increases their size, a lot in some cases. That increases the need to scroll and/or scan those lists.
The increase in hit-ability decreases the visibility.

Defining the size in CSS pixels means that even when zoomed, something twice the physical size is still the same size in CSS pixels. If we rely on zoom, then this SC is not needed but that doesn't seem to meet the need.

What would be better is a method of saying: From a default size, the user can increase the size of targets to an equivalent of at least 44px. That could be zoom, or a UI switch, or just meeting the minimum size in CSS pixels.

If someone can think of a good solution to that we can discuss it tomorrow. Otherwise it is a case of approve (or not) the latest revision.

Kind regards,

-Alastair

--

www.nomensa.com<http://www.nomensa.com/>
tel: +44 (0)117 929 7333 / 07970 879 653
follow us: @we_are_nomensa or me: @alastc
Nomensa Ltd. King William House, 13 Queen Square, Bristol BS1 4NT

Company number: 4214477 | UK VAT registration: GB 771727411