Mobile Accessibility Task Force Teleconference -- 30 Mar 2017

<Kathy> https://github.com/w3c/wcag21/issues/60#issuecomment-277159966

<Kathy> The size of the target is at least 44 by 22 CSS pixels for pointer inputs except when a link or control has an alternative link/control that is at least 44 by 22 CSS pixels, or is part of a block of text.

touch target size

Kathy: it can be either way, 44 x 22 or 22 by 44.
... if you have in-line links on a block of text you can get links stacked on top of each other. if 44 x 44 there is overlap or spaced out too much
... if 44 in at least one direction okay. If you had one in-line link and another in-line link right below 22
... the thought process is generally speaking 44 x 44 but exception for in-line links 44 x 22 because that's what we can do realistically

Shadi: for links it's different than buttons. Buttons are the bigger issue

Kathy: the only challenge that I see is discussion about users being able to zoom to do it but within blocks of text if you zoom you then lose the context and you have the same problem that low-vision users are saying with the fact that you have to then scroll horizontally and vertically. Maybe that's not such a big issue because if you are magnifying the screen you probably want to be...
... clicking on that link so you're going somewhere else anyway

Shadi: if there are many links in that paragraph it's probably a bad paragraph – an issue somewhere else. But if it's a list, a table of contents or something that's maybe one of the issues that I can imagine
... forms on mobile – keep expanding to hit the button and then making it smaller again to get an overview of where you are in the form – that's tedious, that's my most frequent. Table of content I can imagine that that might be an issue – but if I expand once then click to the place I want to go through that's fine. So I'm thinking this is a good compromise.
... form – when you have a lot of buttons close to each other could be radio buttons and links. Very often sometimes you have the label which is linked and then the side of it might be a help page, a link inside the label sometimes so if you don't hit the label correctly or if you want to hit the link and not the label or the label but not the link it causes a bit of a challenge

Kathy: we really shouldn't have things within labels

Shadi: or even close by

Kathy: so in general we think that 44 x 22 is a compromise we can live with for in-line text links

Shadi: I'm happy to be used as a use case – want to make sure not to generalize, could be other cases

Kathy: probably not many scenarios where we are going to have overlapping text, but may have a bigger issue at that point with too many links anyway

<chriscm_> Kim: Make sure language does not imply one particular platform.

https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.0_understanding_that_needs_language_update

https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Subset_of_WCAG_2.0_Techniques_Applicable_to_Mobile_without_Changes_that_need_language_update

<chriscm_> Kim:The second example includes "mouse" which is very desktop centric wording.

<chriscm_> Kim: Guideline 1.1 "...link to an audio clip..." in mobile all you get is the audio player, so considerations for mobile are different.

<chriscm_> Kim: This serves as a list of items that are directly applicable with updated language.

<chriscm_> Kim: Items are marked fixed in the document. You might take the suggestion and fix it differently.

<chriscm_> Kim: Can leave notes that "change not going to be made" in the document. Might be a better method than pull requests.

<chriscm_> Shadi: Might be best to coordinate with the chairs on workflow. Overall makes sense.

<chriscm_> Kim: Workflow within the group, need help reading techniques and spotting these.

<chriscm_> Kim: Fine just saying this needs a fix, without a fix suggestion.

<chriscm_> Kathy: We need to coordinate efforts. Will try and help.

<chriscm_> Kathy: There is an August deadline for success criteria to make it into 2.1.

Kathy: anything you can do to push the conversation further on these to get these to a finalize point is going to be key
... we also have some of these with no manager
... that's why I've been spending a lot of time talking to people – for example trying to get touch target size to the point where it can be accepted
... August deadline even though it's not going to be out until later. In order for the working group to have time for comments they need those success criteria to be locked down. That means they have to go and satisfy all of the requirements for a success criteria – so it has to be testable, implementable across different technologies and there has to be technology to support it so it has...
... to be doable by the developers etc.
... so that's where we need to make sure that we are pushing this. Over the next weeks I plan to try to get at least one or two of them that we are working on and try to see if we've got some things that we can do to address people's comments to try to move this to a point where we are not taking the success criteria in a place we don't agree with, but we are compromising and looking at...
... all the different concerns to see how we can address those
... that's where we are going to spend some time. There's going to be a coordination process – I'll have more on that next week. For now just know that we really need to be spending some time pushing these getting people's feedback trying to get these to the point where were actually finalizing them
... I've taken the priority order we did on the call and started working on them from there. If you have some extra time and you can start driving the conversation in these, putting comments, suggesting if you see something or we need to drive the conversation further if you can help do that
... we've got a lot of work to do before August

- DRAFT -

Mobile Accessibility Task Force Teleconference

30 Mar 2017

Attendees

Contents

touch target size

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output