See also: IRC log
<Kathy> https://github.com/w3c/wcag21/issues/60#issuecomment-277671449
<Kathy> https://github.com/w3c/wcag21/issues?q=is%3Aopen+is%3Aissue+label%3AMATF
Kathy: it would be useful to make
sure to get comments in github as this process goes on
... concerned about the target size SC especially – comments
saying you can just increase target size and that should be
sufficient
... none of the mobile SCs that have been submitted have yet
gotten into the draft of 2.1
<Kathy> https://github.com/w3c/wcag21/issues/60
Kathy: target size – a lot of
discussion about what happens with smaller links, links within
paragraphs of text. Should we have an exception for that.
... there's also points of view of that – this isn't even
really a requirement because you can magnify the screen. The
content is bigger therefore the touch size is bigger. tremor
issue, has to magnify screen even if they don't have to for
vision
... Patrick had a good point about several SCs that are
similar, accessibility versus usability
Detlev: confused about the
process
... delusion of mail and github condiments – keeping up with
stuff difficult
Kathy: I thought we could focus
on a couple specifically. Trying to pinpoint what we need to
comment on, go from there
... Patrick and I have signed up to write a lot of text to go
into 2.0 and 2.1 just to clarify how mobile fits into existing.
We are currently working on that. We had done a lot of that
work early on the task force, we're getting things cleaned up
and getting those in their
... the mobile task force will be coming back and writing
techniques for each of the success criteria
... you're right, the SCs are in the hands of WCAG now, but we
do have to keep commenting on them otherwise they are not going
to go through
... the big one we have to talk about is touch target size
Detlev: assigned to Andrew, what's of comments, I don't know why that wouldn't go forward
Kathy: they're saying it's a
usability issue
... the position is there's a couple different points in this
big thread – one – they feel that having a size bigger than IOS
has recommended, 44 pixels, is problematic.
... second, Links overlapping areas, solution one
dimension
... third, you can just magnify screen so it's not needed
<shadi> +1 to Detlev's suggest to put as an exception
Devlev: 44 not that different
Detlev: exception for text
Kathy: Patrick had some
exceptions
... if there's an alternate way to get to it
Detlev: I think it's easy to have
an exception for in-line text – short words you wouldn't need
the one dimension requirement – you wouldn't want to extend
beyond the word boundary so if it is just a short word I don't
think that should be ruled out – text is different – so I don't
see harm an exception for in-line text
... regarding two dimensions, would probably have to specify
the second dimension as well
... maybe we could just half the value
Kathy: Andrew suggested in-line
text 44 x 22
... you could do what Patrick did – increased touch size
example short link with and or comma between
Detlev: footnotes too
... still best practice, but advisory technique for what
Patrick suggested
Kathy: exception for in-line text altogether?
Detlev: I think that would be acceptable and would make it much easier to accept this success criteria
Chris: I'm not a fan of putting links in the middle of text anyway, but I don't think that's a terrible exception to add
Kathy: if we have something that's in text-only and its short links like that and it's the only way to get to that information or perform that function that I think there's a problem – for the footnote example I don't think that is critical because you can scroll down the page to get to it usually that's just an in-line link
Detlev: or could go to another page
Shadi: or open a box
Kathy: I was getting to the point
of what that link actually does – is it critical to what the
user is doing or just makes it easier. An in-line link you can
get down the page – if it's hard to touch you can scroll down
it's not preventing them from doing it. But if we had something
that was a link to another page and you couldn't actually
activate that because the touch target was...
... extremely...
... small then we're still blocking a user from activating that
content
... that's where I'm still struggling
Chris: you can zoom in on it to me as a weird argument. You get into things about whether an element is focusable. Certain elements are not but are with voiceover on
Kim: argument that you can zoom in to make it bigger assumes that it's easy to zoom – worried about someone who needs to zoom out to orient then zoom in to click, if that person has trouble clicking a small target, how difficult is it for that person to zoom
Detlev: if the issue is this
requirement is limited to buttons icons and other controls
which are not in line text – if we have an exception for
in-line text you could argue there would be another requirement
– be able to increase text in one column view up to 300 or 400%
– someone would have the ability to increase the text size and
also increase the link text size to make that...
... bigger. That...
... applies more to in-line text into controls
Kathy: I agree but when we get into increasing text size it makes it harder to read – more wrapping. Might not need bigger text. And even if we do have been zoom that's difficult for a lot of users. So then we are having users do a trade-off between ease of reading versus being able to click on links. That to me doesn't feel right either.
Detlev: perhaps we could try the
other option – limit the size to address this point – icon size
and to say for in-line text one dimension has to be 44. I still
think there would be exceptions we have to spell out those
exceptions 44 with or whatever, but then enumerate exceptions
where this might not be possible
... if that's what Andrew suggested is something acceptable
that would fall short of having a full – but if that's
acceptable we get one step further
<Kathy> The MATF is fine with having 44 x 44px requirement with exception for inline text where one dimension is 44px and the other is at least 22px. Note: the 48x48px came from the research quoted in the Evidence section.
Kathy: does that summarize what we just said?
Detlev: I'm not sure about the 22
pixel – how quickly we would get to overlap issues
... whether that's 22 or even something like 16
Kathy: we could also put into the
exception that this is for essential functionality, but then
you get into the clarification of what essential is
... the COGA group is doing that
Detlev: doing have some deadline by which we need to create a pull request for it to be into 2.1?
Kathy: I think it's next week
Detlev: so someone has to take it to do the pull request
Kathy: they will be adding more
in later – not going to the first draft doesn't mean it can't
go into another draft but it does mean that we won't get it in
before CSUN
... I was hoping we could actually get this one in there
... the exception is for in-line links – if the in-line link
performs essential functionality then we would need to have 44
and 22
Detlev: for the rest of the links
there would be no requirement?
... most text links will be 44 pixels – some short words which
aren't. Exceptions are links which are intended to be just that
one word, and it just happens to be that word and nothing else
that would be a clear exception – there would be some in-line
text things were that exception would then hold. I think that
would be technically easier to assess than assessing whether
something is...
... essential or not which is always difficult
Kathy: you could argue that we need to have links which are longer
Detlev: there is another
requirement that things are meaningful, but that can be met
with context
... you could say links should be longer than that but there
are cases which they aren't
Kathy: but if we have in-line links that's not the only way to perform that action so it would be excluded from this requirement
Detlev: for example footnote links which go on a separrate page but a link at the top of the article that links to the footnote page?
<Kathy> The MATF is fine with having 44 x 44px requirement with exception for inline links. If inline link performs essential functionality or is the only way to perform an action then one dimension is 44px and the other is at least 22px.
Kathy: So if you have a link in the text and there's another way to do it, you don't have to meet those requirements. If it's in essential functionality you need to meet that or have another way to do it
Chris: I'm picturing somebody
down the road creating a link that's behaving as a button or
vice versa and wondering what version of this criteria meets
that. I would be tempted to leave the exception as simple as
possible.
... because we're talking about links you add ambiguity by
specifying
Kathy: in-line link, button or control
Chris: in-line control
... anytime you say link I hear people debating well it's a
button
<Kathy> The MATF is fine with having 44 x 44px requirement with exception for inline link, button or control. If inline link, button or control performs essential functionality or is the only way to perform an action then one dimension is 44px and the other is at least 22px. Note: the 48x48px came from the research quoted in the Evidence section.
Kathy: any objections to just posting this is a comment?
no objections
Kathy: in looking at the list of
all the other issues from the success criteria that we've put
in, if you haven't been following the been a number of one
slight touch with assistive technology, keyboard with assistive
technology, pointer ones – all the ones that we talked about
relating to the keyboard and if we could change 2.1.1 a lot of
this would go away – that whole discussion has come...
... up again. And now they are coming back and saying we might
be able to change 2.1.1. And so they are asking for suggestions
on that. I was going to go back to what we had already
stored
Chris: I'll go through the list and try to add a voice
Kathy: originally Patrick had
drafted when that was encompassing before we started down the
path where we said we couldn't change 2.0.
... there's a big discussion on that. In looking at this list
what are the other tough ones that we should be pushing to get
through?
Detlev: already have precedent in other guidelines no accidental activation
Kathy: big concern over up
events. My comment on that one is we actually defined up
events. I'll comment back
... I think that was the big thing people were getting confused
about with that. What do you think about the up event – I
thought our definition of that was actually pretty good
Detlev: I think what David says
at the end the activation happens as the user releases the
interactive control rather than when they selected – we could
find another name for it if that's what's grating people –
release event or whatever
... is there any other pushback why it shouldn't go into 2.1?
Anything related to testability? It seems a straightforward
thing to include those exceptions that have been noted for the
down event is essential. It seems a fairly straightforward
thing
Kathy: any other SCs Detlev that
you feel strongly about getting in
... device sensors – that seems like it's straightforward
too
Kim: single key shortcut alternative seems like it's ready to go – clarified by adding single *character* key in explanation
Kathy: Concurrent input mechanism
for silver
... pointer gestures – that seems like something that should go
through
... okay – we got a couple major things taken care of. I'm
going to go through these in more detail over the weekend. I'll
probably be sending out some emails – I'll try and keep up and
pinpoint things we really need to look at. I'm also going to
try to find out from Andrew what's really going to happen with
these. I think several of them really didn't have many
objections and aren't...
... moving just because they don't have a manager – they should
go into WCAG 2.1
... any other thoughts?
... if you have time to go through them please do and answer
questions that are in there
<Detlev> sorry you couldnt hear me anymore
<Detlev> I did nt get through, some failure
<Detlev> Pleas give feedback on what seems most important to do, I guess I can spare some time next week
<Detlev> bye
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim WARNING: No "Topic:" lines found. Default Present: chriscm Present: chriscm Detlev Kathy Kim Regrets: Patrick Found Date: 09 Feb 2017 Guessing minutes URL: http://www.w3.org/2017/02/09-mobile-a11y-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]