Mobile Accessibility Task Force Teleconference -- 09 May 2014

<trackbot> Date: 09 May 2014

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Scribe_List

<scribe> scribe: Kim_Patch

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments

Mobile techniques

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments

Kathy: based on everyone's notes as they went through the techniques – anything that said we needed to have any modification to the technique or it was something that we needed to modify in any way I put into this list
... this is a list of everything and I put links so you can click on the number to see what it was that we wanted to make modifications for
... review this list at a high level, identify anything that is missing or if you have comments about things that are in here or things that are not in here – we will start that discussion
... the new mobile techniques that are in there now are based on the BBC gap analysis that Jan did – some might be advisory or best practice
... also new mobile techniques and responsive design brainstorm, we need to go through those and see if there are any techniques that need to be added
... the goal is to have a detailed set of techniques that need to be modified and that need to be written. Then we will start assigning those out for people to work on
... and we will coordinate that with other groups who are working on techniques, and monitor closely any new techniques WCAG is working on now, for example responsive design
... are there any that aren't in here the you expected or anything else you would like to see

Kathleen: Silverlight is not in there because it's not supported

Kathy: I'm also going to create another list of techniques that don't apply to mobile web, there are a few

<Detlev> no, unfortunately...

<gavinevans> not yet sorry

Kathy: it's really important that we start looking through this now that we have it all on one page, if you could take some time over the next week to really look through this list and identify anything that you disagree with or that you have comments about
... I will create a survey to collect all the comments for this
... another thing we have to talk about is how we are going to handle keyboard access and what's going to be our approach to that in the techniques. So as you are going through these over the next week – make sure to think about how we are going to address think specific to how users are interacting with content

Detlev: list assignments – doesn't seem to refer to the other wiki page where people went through techniques and commented on them – that would be useful

Kathy: you can get to all of the comments by clicking on, for instance, G4
... Most of them are linked, I was also going to link the original technique to the link page – haven't done that yet
... these are really working pages, click on, for instance, G4 to add comments
... tables aren't easy to edit, if we just have a couple of people editing tables that's better– discussion pages for each of techniques
... this will be the landing page where you can get to all the other information

Jan: any contact with BBC folks so we don't have to redo that work?

Kathy: I'm going to talk to Judy

Kathleen: volunteering to make the original column links, will have done by Monday morning

:-)

Jon: does user agents and webpages cover everything – some just say webpages, would we have to change them to webpages and something else?

Kathy: whole discussion about what are we going to do with mobile apps. Right now this list is specific to mobile web. We have to figure out what we are going to do with mobile apps, especially hybrid.

Jon: non-web documents and software – not sure if we want to use that term

Kathy: applications are software. There's a lot of work done on WCAG to ITC. We have to evaluate and figure out what we are going to do. Do we think we should focus on the mobile web stuff first, which is primarily this list and then go back and look at applications, or should we finalize this list and then look at the overlap
... how to approach techniques for mobile apps versus mobile web. Obviously mobile web is easier because it will more closely maps to the language in WCAG

Jan: we need to have a placeholder. I like how the BBC does it which is this is how you do it in HTML, android, iOS. We need that top-level decision whether we are going to include code examples for iOS and android. If that is off the table that it's very hard to provide actual techniques.

Kathy: we could create another column in the techniques table and we can have some notes and there in terms of applicable in the two mobile apps. In BBC guidelines you see that – some just web, some just apps
... ccould do new column, notes in individual pages for recommending changes and start planning it to create the applications in there. I think our focus should be web first to get those techniques out just because it will be easier, and we still need to figure out how the mobile apps are going to fit in – how will they be presented – that's a whole other discussion. That doesn't...
... mean we...
... can't plan for it and as we go through make some notes like the BBC has done it, or on each of these techniques as well

Kathleen: I like the idea of a placeholder. I wouldn't ever want anyone to think that the work we are doing does not apply to mobile apps – if they see that gap they might think it's just the web. Also to the end-user it doesn't matter, the issues are still the same

Kathy: when you are looking at app you often don't know that it is web content, or what is an app – that line is blurring for users

<kathleen> +1

<Detlev> sounds good

<Jan> 1+ to another column for mobile native apps

<gavinevans> +1

<jeanne> +1

<Zakim> Jan, you wanted to another column for mobile native apps

Jon: +1

Kathy: I'll add another column into the spreadsheet and we can start documenting app information to
... other comments on this list and how we are going to start reviewing it over the next week

Kathleen will add column

Kathy: right after technique, then we can say applies to and put web and apps – that way we can easily see it
... scroll down, section on new techniques and mobile best practices. With some techniques that are in here right now are the BBC ones that we identified – this is exactly BBC language and so we have to talk to the BBC about that or rewrite those
... two documents linked – brainstorm for mobile techniques and responsive brainstorm

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques

Kathy: things that apply to both mobile web and apps, specific to web, specific to apps. Some identified as best practices some aren't labeled. Go through label technique, advisory, best practice, and add anything else missing
... start with those that identify to mobile web and mobile apps
... links below or above a certain size – where does that fit in in terms of techniques best practice

Detlev: could be physical pixels, virtual pixels, resolution based measurement

Kathy: can make a note to make it resolution based as well. Android and iOS often talk about pixels. A lot of research out there talks about more resolution. A lot of confusion because 29 pixels by 29 pixels might not be the same on every device
... does anyone know of research out there that we can be on in terms of measurements?

Detlev: article by Peter … Will look for article

<jon_avila> perhaps advisory

Kathy: best practice or technique? I don't think it fits under any of the WCAG

Detlev: no absolute minimum size, so wouldn't fit anywhere well at the moment

Kathy: best practice then? thoughts?

<Detlev> PPK article: http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html

<jeanne> best practice, imo. zooming really confuses this issue

<jon_avila> I'm not sure it's a technique and not best practice. I don't feel it fits under a WCAG guideline.

Kathy: we will list under best practice for now

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/index.php?title=New_WCAG_2.0_Techniques&action=edit&section=1

Kathy: next, this is talking about development of applications, best practice or does it fit under a WCAG guideline

Jon: specifying types of input to make things easier for people so you don't have to pick up automatically – best practices, but not requirements for things that could be used to meet any of the success criteria. If we make this a technique I guess we are saying it's a technique to pass one of the success criteria, so if there's not one to map into we really can do that.

Detlev: couldn't it be an advisory technique?

Kathy: sufficient, advisory and best practice
... if it doesn't fit under any of the success criteria it's a best practice
... for example resolution sizes, it doesn't really fit under success criteria, so it's a best practice. If it would fit under success criteria we could list it as advisory
... mobile related technologies, I added information about filling in a form field, good point and best practice
... next – focus in touch regular versus Lock states

<Detlev> What we need in the future is WCAG 3.0 Guideline 2.2 Touch Accessible: Make all functionality available from a touch screen

Detlev: important to bring up in any future revisions of WCAG

Kathy: next – define the hover focus, is it sufficient, advisory or best practice

Jon: it could map more strongly to some of the success criteria potentially,1.1, 3.2.1, 3.2.2 – and perhaps of these were used incorrectly there could be a failure on a mobile device

<Detlev> There is a good resource for that: https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/

Jon: I don't fully understand the details of what this covers – long press, if we have a failure would hope there's a technique to tell you how to do it correctly

<jeanne> It could also map to UAAG 1.3

Kathy: we need to look at this further
... next – touch target size

Kathleen: it could fall under keyboard if you were talking about a custom screen keyboard, making sure that the keys were large enough, but that's kind of circular

<Detlev> Touch target would map to a new Guideline 2.2 Touch accessible...

Kathy: being able to activate something with a keyboard – touch target size, minimum, space requirement, so the question is what does this fall under, or is this best practice

Detlev: could put it under keyboard 2.1.1, but it's important to note that it's an ill fit and it really calls for a new guideline touch accessible

Tim: seems like a stretch to put under keyboard

Jon: at most be advisory right now– we need another item to cover touch – but advisory for now – that would cover other types of touch events and make sure they are accessible. A lot of these advisory items were never completed they are just bullets

Kathy: even if we have things just under advisory it's important that we pull these out into a separate list of advisory because a lot of advisory never gets looked at
... under advisory, but noted it's better as a new guideline
... spacing requirements – best practice?

general agreement

<jon_avila> advisory to 2.1.1 perhaps?

Kathy: next – touch controls

Kathleen: is this specific to iOS – what is up touch and down touch?

Jon: when someone puts finger down to touch a button but not quite the correct location, that the button should activate without the user lifting up their finger. The idea is to prevent users from accidentally pressing things they didn't intend to press. But you have to be exceptions to this
... it would have to be advisory or best practice. If advisory, under 2.1.1
... possibly 3.2.1

Kathy: next – use of enhanced contrast, currently best practice
... advisory technique under color contrast?

Jon: how is this different from the AAA requirement? 1.4.6
... may be it was around inverse color high contrast or on mobile devices because of where they are used you need better contrast all the time, so AAA unless it was on a mobile device and then AA

Detlev: because of size on a mobile device?

<Detlev> that was Josh I think

Jon: when it's on a device we don't have a good way to test for font size

<gavinevans> it was me :-)

Kathy: for now put items that are smaller may require more contrast, and mobile devices may need higher contrast most of the time. It's already technique, 4.5.1, need to think about whether we need stricter for mobile
... made notes as I was going through, those are now up on this page. Next week: go through mobile development techniques– discussion about what's missing, what needs to be added. Add your comments and we can pick up the discussion next week.

<gavinevans> thanks everyone have a good weekend

- DRAFT -

Mobile Accessibility Task Force Teleconference

09 May 2014

Attendees

Contents

Mobile techniques

Summary of Action Items

Scribe.perl diagnostic output