- From: Kim Patch <kim@redstartsystems.com>
- Date: Thu, 9 Feb 2017 12:06:17 -0500
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <589CA189.3090800@redstartsystems.com>
*MATF Minutes 9 February 2017 link: *
*https://www.w3.org/2017/02/09-mobile-a11y-minutes.html***
*
Text of minutes:
*
Mobile Accessibility Task Force Teleconference
09 Feb 2017
See also: IRC log <http://www.w3.org/2017/02/09-mobile-a11y-irc>
Attendees
Present
chriscm, Detlev, Kathy, Kim
Regrets
Chair
Kathleen_Wahlbin
Scribe
Kim
Contents
* Topics <https://www.w3.org/2017/02/09-mobile-a11y-minutes.html#agenda>
* Summary of Action Items
<https://www.w3.org/2017/02/09-mobile-a11y-minutes.html#ActionSummary>
* Summary of Resolutions
<https://www.w3.org/2017/02/09-mobile-a11y-minutes.html#ResolutionSummary>
------------------------------------------------------------------------
<Kathy> https://github.com/w3c/wcag21/issues/60#issuecomment-277671449
<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
Summary of Action Items
Summary of Resolutions
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.148 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2017/02/09 17:04:33 $
__________________________________________________
Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>
www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________
Received on Thursday, 9 February 2017 17:06:50 UTC