W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

03 Mar 2015

See also: IRC log

Attendees

Present
Jeanne, Kim_Patch, Kathy, Jan, Judy_Brewer, Shadi_Abou_Zahra, TomB, Katie, Henni, Steve_Lee, Kenny, Eric, AWK, Jon, Accessible_Joe, Mark, David, Kim, GreggV, Michael_Cooper
Regrets
Chair
Kathy_Wahlbin
Scribe
jeanne

Contents


<trackbot> Date: 03 March 2015

<scribe> meeting: Mobile Accessibility F2F

Input methods

Katie: Are we making a decision for what the device should be doing

KW: We have things working differently under different OS
... a wide variety of things that work differently on different platforms

JA: A keyboard should be an option, but it shouldn't be required to use an app.
... the touch gestures should be required.

JR: The gestures should be as accessible as the keyboard, AND there should be the ability to add different input methods

KW: The decision about keyboard is already made. We are going beyond WCAG, what should we be inlcuded in addition to WCAG. WCAG is very important, but it is already required.
... what are the needs for mobile accessibility

Steve Lee: What does it cover?

KW: web, mobile web and native apps. the Note was covering all aspects of mobile. We reference the WCAG2ICT note.

Steve Lee: Are we doing also doing ARIA and Pointer Events

Katie: It's not done yet.

Steve Lee: I want to interact with all types of input. I want to be able to input in a variety of ways. Switch people tend to like joystick interfaces.

scribe: there are bluetooth gaming joysticks

JR: Tecla Shield works differently on Android. It emulates a keyboard interface
... on iOS it works over the Voiceover interface or the Switch interface

KW: We get into complex situations on various platforms. Like iOS doesn't work well with Voiceover on.

JR: There are going to be bugs and issues at the browser and platform level.

Katie: We want keyboard plus...

JA: Accessboard has a new section @@

Kim: You can use regular keys without Voiceover, but the Control keys.

JA: There are so many alternatives

TB: That's too complicated for users

JR: It is the browser and platform problem, we should not make it the problem of the developer

KW: Some of this is UAAG and not WCAG.

DD: WCAG requires keyboard, but not mouse. When we wrote WCAG, we never expected that blind people could be using a touch screen.
... sometimes the Gesture will be the accessible gesture, not the keyboard

JR: We can't say "keyboard is the accessible" we have to think about accessibility in the general.
... when there is a keyboard interface, the app should support that keyboard interface.

JA: The AccessBoard is saying to meet WCAG is enough, but the reality is that WCAG isn't enough.

KW: What about hardware buttons? Touchscreen size?

<Henny> BBC Mobile Accessibility touch target size: http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/touch-target-size

HS: the BBC said they recommend 7-10mm as a recommended size.

Katie: What is the drawback of 10mm?

KW: Screen realestate space. Overlapping touchsize.

HS: In the BBC, it is a should, because of the problem with overlap

DD: Will Indie UI help us?

Katie: Yes, but it's 5 years away .

JR: Can we set a minimum size?

KW: MIT did a study.
... Amputees may be using a touchscreen, they can use a touch, but it needs a larger size

DD: Can we require a magnification of 200%

JR: BBC says 5mm with a 7mm exclusion zone, or the 7-10mm.

JA: When does the use of a stylus become an acceptable solution?

JR: Android has a mouse interface as well

BBC had a usability team also working on the issue who came up with the saame solution

JS: A W3C staff person is working on a mobile checker. he wants to include accessibility tests.
... he is going to start testing with the button screen size

JB: Because people interpret things as a requirement, we have to link to research, not just discuss it casually.

Platform Characteristics

Katie: Accessibility settings in the 508 refresh?

JA: In the closed device, there is a text height size and @@

AWK: 503 has a section that references

Mark: mobile applications are excluded if they meet WCAG

JA: I would like to set limits in dynamic type.

KW: It's not everything that expands, it's just blocks of text that expand
... what is impacting the overall user experience for people with disabilities

Gregg: We don't know how big the size is. The only things I have seen that work are things that reflow.
... you can't say people to make it a specific size, because the developer doesn't know that

KW: If people say they want a text size, we want developers to respect that.

GV: People want to set it, and then it can be scaled up as needed.

KW: As a user, I have set a size, and I want any content to respect that size

GV: GPII has been looking at this for 3 years. we have to look at the resolution between devices.
... if you don't have a preference for this app, it uses a generic size
... but if the size is changed in a particular app, then it is remembered for that app.

JR: What is honoring? Some other text on the page, like the time and day, might not be respected.
... and leave some flexibility for developers who have low priority text on a page have to be able to go below the size.

GV: But you have to allow flexible operation. Some people will want that low priority text to be larger.
... COnsider proposing to have the settings under the hood, and allow tuning of applications
... without a interface that is too complex for users.
... GPII can have an interface with advanced settings
... there are tools and environments coming in 18-24 months, to parameterize all these things
... some don't like it because it is difficult to test
... in the last few months, discussion of WCAG that not all documents are required to. But this is what people are working toward with reflow.
... working with elders it is obvious that scrolling is a disaster

Katie: Images vs Text. My experience is that people who need large text don't care about large images.

JR: Form controls and radio buttons need to be enlarged as well. If you zoom and don't get everything zoomed, you can't use it.

Joe: The Cognative Accessibility Task Force is talking about an alternate interface that is simpler.
... like people who push a button by accident mess up their phone.
... Disney found this with people at the Parks have so much on their minds, that they had to reduce the interface of the app becaause people had such a high cognative issue

GV: Clayton Lewis has a paper about this.

KB: Mike Pluke recently said that ETSI was working on a project for Mobile and Cognative

GV: Amazon on the mobile has a simplier user interface
... whatever you think is simpler, do it simpler.

Mark: People want all the features, not the simpliciy

GV: most apps, you can make simpler without reducing functionality
... one of the ways to do it is to have Advanced
... you can layer them

SteveLee: Mobile First idea

JA: But some people hide it behind gestures that you don't know exist.

GV: Or you can have More and Advanced with a Back button so people can get out of it.

EE: This is useability. If an interface element is too small, it will come up in usability testing
... do we need separate standards for the interface and the content?

GV: Poeple who need the fonts increased more than 200%, they need to increase everything. Running paragraphs generally have to larger than controls.

Readability

Do we need a minimum font size and increased contrast.

DD: CDC is asking for WCAG AAA for mobile apps

GV: Some people need lower contrast. Some people want lower fonts.

KW: Would there be different sizes. What would be the recommendation for the default?

JR: I would not require a higher contrast.

GC: There should be a minimum
... this is also a screen reader issue, they want to fit more on the screen.

GV: These are not requirements, which is an advantage that the TF has over WCAG.
... WCAG choose 4.5 because there would be layers of a color, 5 only allowed one color.

JR: There are some new platform settings coming about high contrast.

JA: Why reduce the field of vision?

GV: They got it backwards, why would you want to reduce the field of vision?
... your app should be useful if you are trying to read it through a toilet paper tube? Most apps are usable, but spreadsheets aren't.
... There are things where, if you force high contrast, some apps become unusable. Like text in a piece of art.

JA: Some people don't want high contrast, but just a better contrast

GV: If the browsers enhanced text, then developers wouldn't have to do it.
... put pressure on browsers to include more AT.

JA: iOS has added so many accessibility features to compensate for reduced natural accessibility. It used to be fine to read text, now I need to turn on accessibility features.

GV: when WCAG was talking about 3 to 1, the resolutions were somewhat stanadardized.

JR: 1/72 of a inch.

GV: WCAG was talking about the 14 points
... points in HTML and points in physical side

JA: If it is 1.5 times the default height then the contrast should be able to be lower.

GV: Low vision users shouldn't be buying iPhone 6.
... There is a compact that people should try to come as far as they can.

Design, sceen orientation, indicate actionable elements

KW: Less linear, less of a typical screen orientation

JS: second screen is also an issue

GV: When you zoom in, how do you swipe left and right/

JR: Sometimes it works, sometimes it doesn't, and sometimes the screenreaders read it inappropriately

KW: ease of use is a part of what we do
... honoring Dynamic Type, when we reduce the amount on the screen it changes the user experience\
... if you have Voiceover on, it doesn't work. This is not always covered by WCAG. It is happening with second pages and swiping content in and out.

TB: There are two reasons not to fit on the screen 1) it doesn't fit, and 2) structurally it doesn't make sense on the page

GV: In voiceover, what gesture do you use to refresh the page?

KW: There is a bug in 3 finger swipe?

GV: Hidden button, that pops up when you reach the focus. It helps everyone who can't swipe.

DM: Has anyone done a study of interference between side swipes?

KW: Yes, it is an issue. But it is more of an issue when content is zoomed.

GV: Content that is on both Tablet and iPhone, people are already redoing their apps to be on both phone and tablet.

JR: This the same problem with AccessKeys, that it conflicts with browser and platform gestures
... the same issue is now happening with gestures.

GV: Every normal gesture has a voiceover equivalent, and every gesture has a keyboard equivalent.

JR: and the web app can make gestures that conflict with pinch zoom

DM: The left and right swipes are are the problem with zoom. Keep it simple

GV: Also gestures from the edge and gestures from the center are different.

DM: We need a gesture specialist

JR: Indie UI helps with this.

GV: Any thing you can do with a gesture, you should be able to do other ways.

MC: There needs to be an underlayer where someone who has an accessibility need can use their prefered input method

Kim, there is a focus problem. If you touch, you are putting the focus. If you use speech, then you don't know where the focus is.

scribe: single key shortcuts are terrible for speech users
... as long as I can change the single key shortcuts, so I can't trigger them accidently, then the problem is solved easily.
... custom controls and the ability to share them, so they can be crowd sourced.

GV: The ability to allow users to remap the shortcuts, you can't know what all the key mapping is for AT.

Kim: But sometimes you need both. Some voice users don't use AT.

katie: if there is a way to show focus, would that help?

Kim: but there are focus problems that don't show up except for voice users.

What are the other things we should think about?

GV: Honoring the settings for cursor and focus

SAZ: The things we have talked about will be useful beyond mobile. Some are related to smaller screen. Some are short term, others need development. In what degree are we focusing on these?

KW: We are focused on mobile. We did have the flexibility to look beyond mobile
... whether that should extend beyond mobile is up in the air

SAZ: I would hate to see something that we are talking about for mobile ONLY apply to mobile when it is useful elsewhere.

JB: We are expecting issues to come up in Mobile that relate from WCAG, ATAG and UAAG. You may be interested in more discussion about this in the WAI2020 discussion at CSUN on Wed at 6
... and Friday at 4:20 in Seaport B
... I appreciate that Kathy, Kim and jeanne are trying to keep scoped to the Mobile Accessibility Note, and those who want to talk more about the structure of the future of WCAG, should attend those session.

GV: If people get the idea that you are requiring things, it will become more difficult to implement, because people who will want to object to it.
... Best Practices are also required in some industries.

KW: Thanks for coming and participating.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/03/03 23:59:46 $

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)

Succeeded: s/Ploot/Pluke/
Succeeded: s/vaireity/variety/
Succeeded: s/under different iOS/under different OS/
No ScribeNick specified.  Guessing ScribeNick: jeanne
Inferring Scribes: jeanne
Default Present: Jeanne, Kim_Patch
Present: Jeanne Kim_Patch Kathy Jan Judy_Brewer Shadi_Abou_Zahra TomB Katie Henni Steve_Lee Kenny Eric AWK Jon Accessible_Joe Mark David Kim GreggV Michael_Cooper
Found Date: 03 Mar 2015
Guessing minutes URL: http://www.w3.org/2015/03/03-mobile-a11y-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]