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

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: Detlev, Kathy, kim_patch, JakeAbma
Present: Detlev Kathy kim_patch JakeAbma
No ScribeNick specified.  Guessing ScribeNick: kim_patch
Inferring Scribes: kim_patch

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 05 Mar 2020
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)