Mobile Accessibility Task Force Teleconference -- 09 Feb 2017

<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

- DRAFT -

Mobile Accessibility Task Force Teleconference

09 Feb 2017

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output