MATF Minutes March 5, 2020

*MATF Minutes March 5, 2020

Link:  https://www.w3.org/2020/03/05-mobile-a11y-minutes.html*
*Text:*


  Mobile Accessibility Task Force Teleconference


    05 Mar 2020


    Attendees

Present
    Detlev, Kathy, kim_patch, JakeAbma
Regrets

Chair
    SV_MEETING_CHAIR
Scribe
    kim_patch


    Contents

  * Topics <https://www.w3.org/2020/03/05-mobile-a11y-minutes.html#agenda>
     1. Quick look at touch target
        <https://www.w3.org/2020/03/05-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <https://www.w3.org/2020/03/05-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2020/03/05-mobile-a11y-minutes.html#ResolutionSummary>


------------------------------------------------------------------------

https://drive.google.com/drive/folders/1Q9md2AvmeTgvsT9GB62BsGvCaalDGtE6?usp=sharing


      Quick look at touch target

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

Kathy: Jennifer comment – should we add example of menu?

Detlev: she implies that the drop-down menu having 44 x 44 for each menu 
item makes it quite a long menu
... why create pushback for those types of things – if we are going to 
have such an exception, how to phrase that without being too specific. I 
don't know whether we should have that exception

Kathy: for example W3C is 41 pixels so they would be off by three 
pixels. If we want to add that as an example we can see where that is 
currently at

<Kathy> https://imgur.com/a/t7GZjMG

Jake: just a general sense for every interactive element or the distance 
between

Detlev: I think it's quite clear for the general layout that you want to 
keep that but I can imagine there are situations where you have a design 
trade-off between being able to present drop-down menus with a longer 
list without getting to a problem you can't get to those menu items 
because once you start to scroll the manual disappear possibly for at 
least it's awkward to have to scroll to reach the end of the menu even 
if it stays around
... or it will force you to create a layer of submenus were reorganized. 
That's why think there would be pushback – there is a trade-off between 
visibility of longish menus and the target size and that's not easy to 
defeat. If someone's arguing that way you have a point

Jake: the user need was targets are too close together and to small
... but the two of you saying more on the screen is better

Detlev: yes different types of new users – if that's thrown at us what 
are we going to do, keep it a pure way and risk that it moved to AAA, or 
we try to be flexible and work on some kind of compromise whereby we say 
for drop-down menus if it's awkward – for all things that are visible in 
the default state third drop-down menus it's admissible to make use of 
vertical size of the target to two pixels or whatever. It just makes it 
more awkward [CUT]

Jake: I don't see the value of taking off two pixels

Detlev: 32 instead of 44, so 12 pixels off which is significant if you 
have a longer menu

this is a user clash – cognitively easier to be able to see more things 
at once and also not have to scroll more versus target size

Detlev: also argument for screen readers

Kathy: I put in some language under the plain language summary about the 
vertical list and menu items

<Kathy> 
https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#

I like that – acknowledging there's a clash in giving some advice about it

Detlev: width, although different internationally

Jake: so a vertical list item – I'm just trying to think from the other 
perspective. Isn't it so that most the time we click on the wrong 
elements is twofold – there in a sentence, which is accepted, or there 
are on a list – and those are the ones where it goes wrong. So with 
these exceptions do we kill 80% of use cases we are trying to solve?

Detlev: we still have a decent fallback requirement of 30 pixels which 
is better than many implementations we see

Jake: most are between 23 and 32
... I'm trying to say that if I take myself as an example in all the 
times I click when I didn't want to click because I click right next 
with those are in some way a list of menu items – everybody can say well 
but that's our link list

Detlev: different if stuff is there permanently – if it's there on the 
page and you can scroll you don't have usability issue with menu opening 
up and it can be below the full then your screen
... you could argue that a linked list on a page is fine with 44 because 
you can scroll, but the drop-down stuff is a problem

Jake: but it doesn't say drop downs
... I don't see what the differences between a menu or we put it in a 
drop-down menu

Detlev: you can never see the full menu because it's implemented in a 
way that it won't stay up – you can implement both ways but you probably 
wouldn't be able to acquire. So you would make it unworkable for someone 
who works on a small screen or uses magnification. That wouldn't happen 
if you have a left or right column list of things because you can just 
scroll the page and the list stays there.

Kathy: I just put in an example
... in my mind drop-down menu or sidebar menu isn't much difference – 
same issue for seeing, or not being able to see at once
... it's a sidebar menu on the W3C – 332 pixels length and then 31 for 
horizontal list
... I'm saying ideally the vertical list would have at least 30 pixels

Detlev: we can see if we get pushback otherwise take out 30 pixels. I 
don't see the problem in looking at this page to see that we should 
increase. That's a minor problem compared to the dynamic drop-down 
problem where you can't reach stuff. I think that's a different category 
of problem

Jake: situation mentioned – if you can have directive elements like 
buttons and links this one also doesn't cover it yet. So you have a 
button, may be a panel. You can click on the whole panel, you can still 
put buttons in there, but there is in this case that a space between 
them and they are not part of a sentence, then we didn't solve it yet. 
Just throwing it out there

Detlev: it's a niche case
... maybe this can't cover everything but if this does cover the main 
navigation parts or decide which are the most used elements that would 
be a big win. I wouldn't get caught up in those exception scenarios. I 
still think the drop-down menu thing is something we need to worry 
about. Maybe one answer is not to worry and just leave it and see what 
pushback we would get.
... it could be that people were happy to reorganize into shorter menus 
or submenus although those could cause problems as well – I'm not sure 
that's just a guess

Kathy: maybe caveat vertical menu items that have more than seven items 
or something like that

Detlev: I don't think we need to quantify people will have a uniform way 
of implementing
... I wouldn't put in a different number I would just say there's a 
general exception

Jake: Amazon example, interactive elements

Kathy: Amazon's menu 348.33 horizontally vertical width is 42

Jake: talking about account settings 28 pixels high

Detlev: cut off at the bottom – I have to stay inside the menu so it 
doesn't disappear and then scroll with the mouse we, but if I didn't 
have a mouse wheel I would have to scroll by using the scrollbar and as 
soon as I move over to the scrollbar it disappears, so I can't see my 
absent items at the end of the list
... or change their information architecture so they don't have such a 
long menu

Jake: the more you zoom in targets bigger and stuff will not all be in 
your viewport. I'm trying to see why 30 or 32 would be better than 44 in 
this case

Detlev: if we were enforcing 44 it would force Amazon to either redesign 
the menu or force people to scroll more. It can cause issues, I'm not 
sure that they are not solvable. I'm also not sure that we want to have 
an exception

Jake: if we are lowering down all those issues to 30 or 32 I know that 
Sean mentioned Google spacing between touch targets the other bar with 
all the bold underline etc. they are not 44 x 44he already gave me 
pushback in Japan at TPAC that they don't want to make them bigger 
because they won't fit
... so you might change the whole success criteria

Kathy: exception – if you have a vertical list of menu items that's 
going to extend beyond the typical typical screen size, 1024 x 448 that 
may be exception. We can make a note to Detlev's point – keep the menus 
shorter.
... I put a screenshot of Amazon's other menu on the third page. 
horizontal width is only two pixels off. If you added one of the 
padding's you would have it
... it's an interesting use case – I hear your concern Jake about 
there's a huge long list in the my account stuff.
... when you look at that it's 39 x 23, touch will have issues

Detlev: tools all the pretty close to 44, may be a pixel less. List at 
the left side, inbox etc. for many people that will be fine because you 
want to see these things together. There are usability trade-offs and we 
need to somehow account for those cases. I don't think it will be a 
winner to say I don't care we just have to change the design. The 
reality of many implementations tells us that there are cases where 
people use less
... and there are also good reasons to use less – need to respond to 
that in some way

Jake: will get people who say I have a good reason. If you want to fix a 
user need should fix user need for all developments otherwise half of it 
is good usability other half not

this is useful for us to point out that there's a user clash here – that 
some users need to see more on a screen and some have trouble scrolling 
and some need large target sizes

Detlev: at least someone for users is better than having it relegated to AAA
... let's flag we are aware of those clashes and are looking for advice 
about the best way to tackle this

+1

Jake: please also note the toolbar that Sean mentioned – they do not 
want to change
... I don't think the end is finding issues for where people say we have 
good reasons. I don't think it stops at drop-down menus but it's also 
not feasible to have success criteria where you accept 20 different 
cases and explain also to the general public which case counts for the 
success criteria and which one not
... specifically if they reuse certain menus and sometimes they are in a 
drop-down and dialog and sometimes not an they have to change them every 
time so they cannot reuse those building blocks – that makes it pretty hard

Detlev: understand it's hard – also could lead to people not accepting this

Google sheets is an example of different size drop-down lists

No meeting next week because of CSUN, see everyone in two weeks


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes manually created (not a transcript), formatted by David Booth's 
scribe.perl 
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 
1.154 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2020/03/05 17:07:14 $


*
*___________________________________________________________

Kimberly Patch
(617) 325-3966
kim@scriven.com <mailto:kim@scriven.com>

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

PatchonTech.com <http://www.linkedin.com/in/kimpatch>
@PatchonTech
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________