https://drive.google.com/drive/folders/1Q9md2AvmeTgvsT9GB62BsGvCaalDGtE6?usp=sharing
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.)[End of scribe.perl diagnostic output]