See also: IRC log
<trackbot> Date: 03 March 2015
<scribe> meeting: Mobile Accessibility F2F
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.
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.
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.
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.
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.
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]