W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

02 Apr 2015

Agenda

See also: IRC log

Attendees

Present
Kathy_Wahlbin, Detlev, Alan_Smith, Marc_Johlic, Jeanne, Mike_Pluke, Jan, [IPcaller], AWK, +1.408.425.aaaa
Regrets
Kim, David
Chair
Kathy
Scribe
alan

Contents


<trackbot> Date: 02 April 2015

<Kathy> meeting: Mobile A11Y TF

<Detlev> I put in 6283 as pass code but Zakim tells mie it is not valid...

<scribe> scribe:alan

takeup next

<HennyS> I'm unable to access the conference bridge. I just get static feedback.

New time for meeting

<Detlev> worked now

one item on on the agenda is first item is taking about new time for this meeting.

many interested in joining but in asia but this time is difficult

can we have it earlier in the day or other creative solutions?

Jeanne, anyone on west cost?

<Jan> JR: I can do do as early as 9am ET

<Detlev> What would be the new time suggestion?

Kathy, yes one person.

+ Alan for earlier

Mike Shivanik is on west coast

can we do survey?

David McDonald has conflict with this exact time. Only can join every other week.

Mark, 9-2 on thursdays is okay

I think Jan said okay with Thursday mornings

<Detlev> should we have a scribe?

Kathy suggested two diff times for meetings for techniques. Review meetings at specific times.

<Detlev> Ah - overlooked that, sorry.

Review meetings to two different times?

Asian request for Beijing

currently 11:13 pm for them.

Mike Shebanek is on west coast usa

Difficult challenge for this with people in different countries. Starts to get to be where time of day is barrier.

Call for concensus on list and not on calls.

Who is speaking? sorry

Andrew, thanks

Trying to be more asinchroneous.

Consensus in list rather than in meetings.

Yes, I know.

Jan, hard when you have some that go to one meeting and some to another.

<AWK_> There is a lot of value in being able to thrash topics out on the phone, but the CFC process on the list is more inclusive

Move to making sure we do concensous through the list via survey or others.

<Kathy> https://www.w3.org/2002/09/wbs/66524/20150330_survey/results

jakim: next item

Survey

Started on operable.

<Kathy> TOPCI: 1. 3.1 Keyboard Control for Touchscreen Devices

discuss different one, any missing, have people walk through their suggestions.

3.1 Keyboard control for touchscreen devices

Reviewing each response.

don't need to be in WCAG but anything new as well.

Touch and mouse control also important

Mouse could be other device as well.

Detlev, perhaps pointer control.

for example mouse

Kathy also taking notes of comments.

for touch devices in brackets (using touch and keyboard)

David made comment on not seing keyboard trap and do we need discussion of drag and drop.

<jeanne> I agree that we need keyboard trap

Kathy did see trap recently, so it is important

detlev; are we also talking about keyboard and screen readers and swipe?

<marcjohlic> I also agree that we need to address keyboard trap (or trap in general)

Kathy, touch and pointer control also not being trapped for touch.

Is opporability is better wording?

Ensuring touch access control for all functionality' sounds more like it should be associated to 3.3 Touchscreen Gestures as 3.1 focuses on keyboard operability.

"Defining the hover, focus, selected and touch (regular, long) states": these states mostly have a platform-specific implementation so what should the content author define here apart from adequate visible focus (SC 2.4.7)? This might be rendered as "Use focus, hover and select states consistently and in a way that follows the respective platform conventions", or similar.

Kathy, only thing worried about neet to have focus state that is visible.

May need to clarify further, have behaviors of all the ways we interact.

hover, and other have the affordance that something is there.

Mike: trap issue.

<Mike_Pluke> where input focus can be moved to a user interface element, it shall be possible to move the input focus away from that element using the same mechanism, in order to avoid trapping the input focus

Mike could not get his results entered.

Kathy saw this this morning, not sure what is going on with survey.

His comments are in there, no worries.

Kathy when we are looking at keyboard or touch. Kim would share on voice control if on call. More for UAG site.

Anything we should say or include for other ways people are interacting?

Andrew: how to plan for a good voice interaction model.

sumarizing for action.

Sorry, that was Mike

Kathy would we group voice with touch ?

Or specific techniques for switch.

Jan, can emulate both.

Jeanne, likes idea of addressing switch directly.

Give the appearance of not addressing it otherwise.

Have section for "other"

Kathy, what if touch, point and other input devices

Jan, not quite sure about this.

What is keyboard is sequential, touch is ability for random access. Voice is another random access method

Into the ui even with out actual button there.

Alan, keyboard can also do next paragraph, sentence, etc.

Jan, this is an access issue

Mode, is a radial thing.

Voice we can do voice sequeential and randomly.

Kathy put this into three groups in document.

any techniques for random and seq.

Not putting notes on wiki put on seperate word doc.

Detlev, may get things not focusable.

Kathy what about grouping, and how people actually access it.

Jan, still seq. but hierarcial. Are you asking about random?

Kathy, any technique in voice or switch we need to have in here?

Jan, when a switch emulates a mouse, button size is still important.

May not be something to address here. Will think about this more. will look at a whole later.

Touch Target Size and Spacing

next item is 2.3.2

Providing adequate touch target size / Ensuring that touch targets are large enough to touch accurately without magnification Provide adequate spacing between touch targets

Jan talking about his comment: Another maybe advisory thing is to provide a viewer showing what's under the finger in apps taking path input (maybe that's for the touch/mouse section)

Many apps these days you want to do fine work.

One technique is a viewer under your finger.

Kathy to go under touch and pointer control.

Kathy, goes with Mikes point on affordance.

Alans comment on zoom maginication when touching close to a link button.

Mikes comment: Touch target is not defined. It is not uncommon to use software to disambiguate the intended touch target. In such a case the concept of spacing between touch targets is difficult to define. Also, the visible target can be quite small (e.g. a down arrow) as long as it is sufficiently far away from other active controls.

really talking about area inwhich the actual area where you touch the control.

What are talking about with touch target. area in which you touch it it activates a specific control.

Detlev, area that activates the target,

Much larger area that actually activates the target. Or little area you see.

Jan, agrees. To him, the surrounding area is still the touch target.

Provide adequate spacing, the space in between is inactive.

When targest are small inactive area is more important.

Need to be careful of sugesting spacing.

More concerned that when you touch an element you don't activate the wrong one you did not want to touch.

Provide adequate spacing between elements. Have two items on this.

Mike, avoided putting size and spacing in european guidelines.

There are minimum sizes defined in dev docs for ios and android.

<jeanne> UAAG says they have to follow dev docs.

Mike is okay with have both.

detlev: on his comments for touch: better to say imput mode independent.

<jeanne> UAAG SC on following dev docs -> http://w3c.github.io/UAAG/UAAG20/#sc_512

One technique avoid techniques when screen reader is turned on some dont work.

Provide fall back to drag and drop

fall back for delete icon via drag and drop to trash can.

Alan, is that same as keyboard equiv for all touch

detlev; may have long press and delete key may not be mutually exclusive.

kathy, any more.

Device gesture 3.3.3

Jan, wording needs to be explained, using device buttons are rair on things.

actually going over 4. 3.4 Device Manipulation Gestures

David: might need to rename the second technique to make it clearer... I'm bouncing between arrow on a keyboard and home button on device in my mind.

Are these hard or soft buttons?

Things like android back button.

Is this software or hard key?

Jan, considers this a hardware key.

<scribe> new android 5 active actually has hardware keys for these that are soft on other devices.

Some use this for other functions, and actions are not consistance.

Jan, same within device useage.

any last comments?:

Kathy will put wiki page together for these notes.

Will create survey for next week for list of techniques.

Kathy thanks and bye.

rssagent make minutes

rssagent, make minutes

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/04/02 16:03:48 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
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: Alan_Smith
Found Scribe: alan
Default Present: Kathy_Wahlbin, Detlev, Alan_Smith, Marc_Johlic, Jeanne, Mike_Pluke, Jan, [IPcaller], AWK, +1.408.425.aaaa
Present: Kathy_Wahlbin Detlev Alan_Smith Marc_Johlic Jeanne Mike_Pluke Jan [IPcaller] AWK +1.408.425.aaaa
Regrets: Kim David
Agenda: http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Mar/0029.html
Found Date: 02 Apr 2015
Guessing minutes URL: http://www.w3.org/2015/04/02-mobile-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]