W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

17 Sep 2020

Attendees

Present
Kim_patch, JakeAbma, Kathy, Jennifer, Sukriti, Detlev
Regrets
Chair
Kathleen_Wahlbin
Scribe
Kim_patch

Contents


Trackbot, start meeting

<trackbot> Meeting: Mobile Accessibility Task Force Teleconference

<trackbot> Date: 17 September 2020

touch target spacing feedback

Jake: minimum 44 with no pixels why not 28 in total – all those discussions. That gets a lot of pushback. I'm not saying I'm in favor of that but it seems like if we want to get something out there may be a target size in AA where we don't have the 44. At the moment combining target spacing with target size we will get all kinds of different questions.
... gray area is close to 44 if you are doing some kind of spacing why not including the minimum spacing and target size – we are going into circles with that

<Kathy> The size of the target for pointer inputs is at least 26 by 26 CSS pixels unless a particular presentation of the target is essential to the information being conveyed.

Detlev: you've raised an important point the possibility that people designing this may have overlapping targets so a check checking individually would work, but only the top one would have the full with and the other three pixels less because the one on top overlaps it slightly. That may be a situation which is very difficult to test. I don't know how smart these tools are to work out target sizes in context.

It would already be difficult for them to look at spaces between – easier to just look at target size

Detlev: Jake and I on github the last few days discussion
... I think getting rid of all the spacing and gap thing and just having a target size requirement seems to be the easiest way forward and I think that's reflected also in some comments
... I feel a bit bad about backtracking on this, I said whatever the task force comes up with and then poking holes in the argument because I felt it wasn't quite right

<Kathy> The size of the target for pointer inputs is at least 26 by 26 CSS pixels except when: • Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels; • Inline: The target is in a sentence or block of text; • User Agent Control: The size of the target is determined by the user agent and is not modified by the author; • Essential: A particular presentation of the target [CUT]

Jake: one question – say we have 28 pixels and then you have a list of links and they are all 28 pixels high so they would pass. I think Kathy you are one of the initiators – there is a problem we were trying to solve when we started with the pixels target spacing.
... if we have a 28 minimum size my pushback is the barrier, the user need, the intent of the criteria is not fulfilled. We still do not have that eight pixel or four pixel or whatever we agree on target size spacing
... that's not what we wanted when we started out

Kathy: the bottom line is we need to have something in there. If it takes getting away from all of the issues that people are posing and we can actually get something and because we are running out of time, then maybe we just go towhat I put in the IRC

<JakeAbma_> https://www.w3.org/

Detlev: what's the scenario for the first exception

Kathy: two buttons that do the same thing person can press the alternative button. We could have something in a sentence that was much smaller but we could have a bigger button that did the same thing

<JakeAbma_> https://www.nu.nl/

Kathy: in that case they didn't need to meet the minimum size for the first one so if there's an alternative way to do it we are fine but we need to have these figures target size and their

Detlev: but it's not in-line links

Kathy: yes – if there's another link somewhere in a menu that smaller is there another way to get to it

Jake: links, just default text links and filters on the right side of W3C donations etc. they will all fail, they are between 18, 19, 20

Detlev: it would be easy to increase the padding of that to meet the target

Kathy: we are trying to solve for a problem. If you have less than 26 x 26 spacing it's difficult to touch them. I believe that no matter what we say in the AA that this is going to be an issue that is going to be de-prioritized and in a legal setting would not come up as something that is blocking a person with a disability necessarily
... and so I think we shouldn't be necessarily concerned about things that are existing but things that we are moving forward in design
... I don't think 26 x 26 is an unreasonable size

Detlev: the headings for a CSS person it would be five minutes of work changing the padding and it wouldn't even change the visuals of this, so maybe that's acceptable

Jake: but lots of websites will fail
... it's not that I don't want to I just mentioned that almost all are 26 – we should just be aware

Detlev: there's precedent – hover, close, escape, auto complete, lots of sites that don't do

Jake: maybe that's why we are here

Kathy: I think if the site is optimized for mobile they will have already solved for this. This is just extending it to the target sizes

Jennifer: the equivalent part makes me a little bit uncomfortable but I think that's just because I'm used to doing native mobile development where it's not recommended to have two targets that do the same thing.

Kathy: what if we took that one out? We could just leave that at a AAA level.

Detlev: I would like it very much to have it in because I fear that we get a situation where people do the main navigation with very compressed drop downs – 20 lists which are close together and just in order to meet this they have a content site map at the very bottom of the page where they have the same links widely spaced and that wouldn't help anyone
... I'd rather get rid of it and then respond if people say there's something needed, but I wouldn't go for right now
... recommending take it out of AA and see how it goes. I'd rather recuse the default size to accommodate concerns that it cannot be done or think of some way of having an exception for having targets – is it possible and useful to have the option to have those 26 pixels where it cannot be shared
... it makes it more complex though so maybe it's not a good idea to bring that in as an alternative

Kathy: I'm fine with taking it out

Kathy so that leaves in line, user agent control, and essential

Kathy: and this is just target size AA, not spacing
... I never expected to have this much pushback on it. But I would rather have something in there the nothing

Detlev: argument that designers will make the targets very small and argument that drop downs get really really long because the list issues need spacing – I think that's a real usability issue as well on a small screen if you have a longer drop-down having 44 with spacing makes it really really wide
... even overlapping where you reduce the text size, but that's not a solution. So I think they had a point

Sukriti: I don't quite agree that designers would make those choices – some of the pushback was about people are going to try to navigate around this by making the actual targets much smaller and then having the spacing – I don't buy that that will be a side effect

<Kathy> Target Size (AA) The size of the target for pointer inputs is at least 26 by 26 CSS pixels except when: • Inline: The target is in a sentence or block of text; • User Agent Control: The size of the target is determined by the user agent and is not modified by the author; • Essential: A particular presentation of the target is essential to the information being conveyed.

Sukriti: agree that getting something is better than nothing

Jennifer: I would hope that the designer would be these don't fit on the mobile device that means our design is bad. I would hope that is what a designer would do.

Detlev: I've seen some bad apps

Jennifer: especially old apps

Jake: I'm sure if our teams can fix it by making a tweak they will do it

Kathy: I was responding to just the last thread on the target definition where Alister had brought up– on spacing

Jake: I know we had done something on focus. In this case since we have legacy wording and target spacing, can we refurbish for silver

Detlev: you suggest to have that as a AAA requirement?
... wording purely based on target spacing, at least use that for AAA

Jake: basic separate criteria, then when we do silver target size, extra credit if it's bigger or add spacing
... but if we don't we don't have it out there

Kathy: maybe what I sent out to everybody as a response to that is just that the mobile accessibility test forces recommending the following changes to the target spacing
... first, change AA requirement to a target size of 26 x 26 with the three exceptions
... then move a version of the target spacing to AAA

Detlev: do we have a sufficient technique for the AAA target size? We would need one.
... I wonder whether it should also say something about the stacking issue. As developers Sukriti, Jennifer, is this something developers would do

Jennifer: this isn't something they would do – maybe on smaller devices you get overlap because they didn't do proper testing with dynamic type turned on

Jake: I know I've done tricks like that to make mobile – start tweaking some margins if you don't spend time doing much on accessibility
... but we can probably fix that by just saying a target should not overlap
... they may overlap the actual clickable area should still be

Sukriti: for things like tables if there's alignment issues it seems like some of the areas could overlap – it would be bad design, but it could work that way

Kathy: what if we said the target spacing is at least eight CSS pixels for each target smaller than 36 pixels in both height and width where the areas do not overlap except when in-line and essential

Detlev: so four pixels all around, if two of them touch that would be eight pixels

<Kathy> Target spacing is at least 4 CSS pixel target spacing for each target smaller than 36 by 36 CSS pixels where the areas do not overlap; except when:

<Kathy> Target spacing is at least 4 CSS pixel target spacing around the target for each target smaller than 36 by 36 CSS pixels where the areas do not overlap; except when:

<Kathy> Target spacing is at least 4 CSS pixel around the target for each target smaller than 36 by 36 CSS pixels where the areas do not overlap; except when:

Sukriti: we run into again the area between 36 and 24. The last time we had a better wording for avoiding that corner case between 36 and 24

<Kathy> For each target that has a width or height less than 44 CSS pixels, the target area has a width and height of at least 24 CSS pixels with a minimum spacing on the height and width of 4 CSS pixels where the spacing cannot overlap, except when: • Inline: The target is in a sentence or block of text; • Essential: A particular presentation of the target is essential to the information being conveyed.

Jake: if we just mention that it is at least 34 pixels but the total is 44.

Sukriti: we had a somewhat reasonable wording for it last time

Kathy: if we go back to that –

Detlev: we wouldn't need any reference to the target size now because that's covered by another success criterion

<Kathy> The target area has a width and height of at least 24 CSS pixels with a minimum spacing on the height and width of 4 CSS pixels where the spacing cannot overlap, except when:

Detlev: it should kick in at a target size smaller than 36

Sukriti: remove the size requirement and leave the rest the same…

<Sukriti> For each target that has a width or height less than 44 CSS pixels, targets have a minimum spacing on the height and width of 4 CSS pixels where the spacing cannot overlap, except when: • Inline: The target is in a sentence or block of text; • Essential: A particular presentation of the target is essential to the information being conveyed.

<Kathy> Targets have a minimum spacing on the height and width of 4 CSS pixels where the spacing cannot overlap, except when:

Jennifer: …where the spacing cannot overlap except when the target height and width is already 44 pixels

Sukriti: tthat's just the 44 case

<Kathy> Target Spacing (AAA) Targets have a minimum spacing on the height and width of 4 CSS pixels where the spacing cannot overlap, except when: • Large Size: The total width and height exceeds 44 by 44 CSS pixels; • Inline: The target is in a sentence or block of text; • Essential: A particular presentation of the target is essential to the information being conveyed.

Kathy: we have a AAA, so we can't have a requirement exceeding 44 x 44 because then there's a conflict

Jake: mention in the note for targets between 36 and 44
... is it possible to add the gray area exceptions in the note because that would be normative – for targets between 36 and 43 pixels it doesn't need to exceed 44.

Sukriti: the question we should try to answer is the current wording – is it unclear or ambiguous

Detlev: conflict with extra requirements tackling situations where the target is smaller
... that's the main issue. It could work on AA as an additional requirement by don't think on AAA

Sukriti: should we suggest this one is a AA instead of a AAA?

Detlev: possibly – I think it makes more sense. It's better

<Kathy> Target Size (AA) The size of the target for pointer inputs is at least 26 by 26 CSS pixels except when: • Inline: The target is in a sentence or block of text; • User Agent Control: The size of the target is determined by the user agent and is not modified by the author; • Essential: A particular presentation of the target is essential to the information being conveyed. Target Spacing (AA) Targets have a minimum spacing on the height and[CUT]

Sukriti: are we back to square one from next week where we were at 24 but now we were at 26 but with spacing?

Kathy: I think we should just do the target size.
... anybody disagree with that

no disagreements

<scribe> ACTION: Kathy will send out just target size

<trackbot> Created ACTION-87 - Will send out just target size [on Kathleen Wahlbin - due 2020-09-24].

Summary of Action Items

[NEW] ACTION: Kathy will send out just target size
 

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/09/17 16:02:32 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
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: Kim_patch, JakeAbma, Kathy, Jennifer, Sukriti, Detlev
Present: Kim_patch JakeAbma Kathy Jennifer Sukriti Detlev
No ScribeNick specified.  Guessing ScribeNick: Kim_patch
Inferring Scribes: Kim_patch
Found Date: 17 Sep 2020
People with action items: kathy

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]