- From: Kim Patch <kim@redstartsystems.com>
- Date: Thu, 05 May 2016 12:11:24 -0400
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <572B70AC.7070708@redstartsystems.com>
*MATF Minutes 28 April 2016 link:
*https://www.w3.org/2016/05/05-mobile-a11y-minutes.html
*
Text of minutes:*
Mobile Accessibility Task Force Teleconference
05 May 2016
See also: IRC log <http://www.w3.org/2016/05/05-mobile-a11y-irc>
Attendees
Present
patrick_h_lauke, jon_avila, Kathy, Kim, marcjohlic, Jeanne, David, Chris
Regrets
Henny, Alistair, Alan
Chair
Kathleen_Wahlbin
Scribe
Kim
Contents
* Topics <https://www.w3.org/2016/05/05-mobile-a11y-minutes.html#agenda>
1. Status Mobile Touch & Pointer guideline and success criteria
<https://www.w3.org/2016/05/05-mobile-a11y-minutes.html#item01>
2. Review of next steps -- mobile guidelines: 2.6, 2.7, 3.4, 3.5
<https://www.w3.org/2016/05/05-mobile-a11y-minutes.html#item02>
* Summary of Action Items
<https://www.w3.org/2016/05/05-mobile-a11y-minutes.html#ActionSummary>
* Summary of Resolutions
<https://www.w3.org/2016/05/05-mobile-a11y-minutes.html#ResolutionSummary>
------------------------------------------------------------------------
<chriscm> I see so many connected to chat already, but nobody on the
WebEx. Am I in the right meeting? :)
yes -- b right there
<patrick_h_lauke> (sorry running a minute late, just dialing in)
Status Mobile Touch & Pointer guideline and success criteria
Kathy: Jeanne separated out touch and pointer, working on survey that
will ask people to put comments in github. Three weeks, feedback until
end of May, then we will take up comments
... also just had a call with the other task force coordinators and
working group chairs -- direction moving forward. Meeting on Tuesday
working group call. Because all of you are not only part of the task
force but are part of the WCAG working group you can attend that
meeting. About structure going forward. I highly encourage you to attend
this call on Tuesday. They've collected a lot of...
... different models and they've gone through the pros and cons of all
of those and they are going to present that on Tuesday. Call is at 11
o'clock Eastern standard Time
... you can also watch the mailing list for minutes of that meeting
... will forward the email for that meeting
... appropriate discussion links will also be in the survey
Review of next steps -- mobile guidelines: 2.6, 2.7, 3.4, 3.5
Kathy: two goals going forward
... get this finalized within a year -- have a good foundation but
techniques etc. Also coordinate with the other taskforces
... today review the guidelines outlined from our original notes
... talk about as a group where we want to focus next. Also, with a list
of items we want to coordinate with either the low vision or the
cognitive task force -- for example looking at color contrast on mobile
with low vision - talk about together
... next week after the call with WCAG we will talk more about getting a
timeline together
... any questions
... let's start by talking through the different items. We've been
talking for the last month of pout touch and pointer, which is out for
review now. Other guidelines: 2.6physical features of the phone,
2.7speech input users, 3.4content usable in different orientations,
3.5interactive elements distinguishable
<jeanne> +1 Kim for working on those that need coordination.
<jon_avila> I don't have a preference
<jeanne> I think it is better to work on coordinating before either one
of us is fixed into a position and have to re-do work.
Patrick: everything not strictly mobile?
Kathy: yes all of this is things that could be applicable across groups,
and the way we have it everything is going to be incorporated together
-- we may have a quick reference that allows you to see things
specifically for mobile but not specifically a mobile extension -- it
will be incorporated. Which is why the coordination is important
Patrick: speech input is there a group that's more suitable are do we
throw the doors open to an entire working group or is the understanding
we'll do a first pass
... maybe we haven't had the direct expertise on that
Kathy: Kim has the expertise and I'm also a Dragon user -- there is
expertise in this group and I'd like to see it go in otherwise it's
going to get lost. Kim's done work in that already that we can propose
to the wider group for feedback. It's not necessarily something were
going to focus a lot of time on but it is important. Also speech is
important for mobile but not just applicable for...
<patrick_h_lauke> reassured to hear that we do have expertise in this
area already in the group
Kathy: mobile
<patrick_h_lauke> is it just speech input, or also speech output? (just
asking as i heard mention of "when they get a text message, they hit the
speech button")
David: echoing that there's a gap with speech, and people are using
speech on mobile more than anything else now. Siri and the speech
button. It does need to get done. We have some difficulties on mobile
because you can't do everything with a keyboard.
... keyboard work in mobile browser is there a mobile browser that you
can do full keyboard
Patrick: not iOS -- without voiceover can't navigate everything
David: there are some things -- home screen
Chris: you can do quite a bit with the keyboard. It certainly works
better with voiceover active but both android and iOS have this
separated concept of keyboard focus versus accessibility focus. IOS
tends to link them more with AT on. Android actually better without AT.
But both roughly accessible with and without
... but it's not intuitive
David: Space is enter key.
Chris: arrow keys more than tab
David: overall is good enough, but a little bit of concern2.7 how are we
going to address this knowing that you can't do everything with keyboard
in iOS. That's one of the questions to solve
<patrick_h_lauke>
http://9to5mac.com/2015/11/20/ipad-keyboard-shortcuts-cheat-sheet/
<davidmacdonald>
http://9to5mac.com/2015/11/20/ipad-keyboard-shortcuts-cheat-sheet/
<scribe> *ACTION:* Chris blog item on keyboard shortcuts on iOS and
Android and send us the link [recorded in
http://www.w3.org/2016/05/05-mobile-a11y-minutes.html#action01]
<trackbot> Created ACTION-51 - Blog item on keyboard shortcuts on ios
and android and send us the link [on Chris McMeeking - due 2016-05-12].
<jon_avila> I agree with Patrick
Patrick: from a browser point of view you can do very little. If it
doesn't work on Safari it won't work on others because they are just
safari under the hood -- that's the general situation for Web content
under iOS. Don't think you can send JavaScript key commands already. So
a lot of the aria that have been explicitly written to -- user can just
use arrow keys and add event handlers for...
... keyboard like key down or keypress they will not be triggered --
keyword doesn't send any through the browser -- browser never receives
any key events
<marcjohlic> Bottom of this page has 4 levels of VoiceOver keyboard
commands: "VoiceOver Command Charts"
http://www.apple.com/accessibility/resources/
Chris: so you have to turn on voiceover.
Patrick: something needs to be focusable and actionable
David: I don't see a reason why iOS can't fill in the gaps. I think we
can be a bit ahead of the curve and push this
<marcjohlic> This may also be helpful:
http://www.interactiveaccessibility.com/education/training/downloads/Testing-BluetoothKeyboard-iOS.pdf
<jon_avila> My ARIA page lists issues related to keyboard access in
addition to other ARIA information
http://mraccess77.github.io/test_results/ARIA_Mobile_Browser_Support.html
David: I think we can push ahead with 2.7.2 and not hold it back
Kathy: which one do we do next? 2.5 collaboration with cognitive?
<jon_avila> sounds good
David: we overlap with both cognitive and low vision on this one
Kathy: we could pick up this one, create some success criteria, then
have discussion with low vision and cognitive and incorporate that in --
that's one approach. The other approach is to take one that's not
specific to any of the others, for example 2.4, which is more geared
toward mobile specifically
David: I would say we would want to work where we can find success
criterion. 2.5.3, Clearly distinguishable is not measurable
Kathy: all of these we want to work on. My thought is either guideline
3.5 or to continue on and talk about 2.7 because it goes along with a
touch and pointer as different ways to interact
<patrick_h_lauke> google doc where we documented some of the areas where
ARIA patterns fall apart on touch devices and in mobile+keyboard
scenarios
https://docs.google.com/spreadsheets/d/1gN9oRZPdrJxLDNtT6nVO4fn7E7sn1061L9Xl3__slZ4/edit#gid=0
David: low hanging fruit right now
... 2.4.1 looks like pretty low hanging fruit, changes in orientation
<patrick_h_lauke> referenced from
http://w3c.github.io/aria-in-html/#aria-touch
David: Chris, how would I programmatically orientation
<patrick_h_lauke> https://www.w3.org/TR/orientation-event/
David: the problem I think that were trying to solve here is a guy is in
a wheelchair, landscape you, can't switch. AT that he might be using, in
this case scanning would be able to know and change orientation
Jeanne: can set fixed orientation in a webpage
Chris: can set orientation in devices themselves -- that's a device problem
Jeanne: this was for Web browsers that have set page
Chris: ... Webpage doesn't know device setting
<patrick_h_lauke>
https://drafts.csswg.org/css-device-adapt/#orientation-desc
<jeanne> https://www.w3.org/TR/orientation-event/
<jeanne> https://www.w3.org/TR/screen-orientation/
Chris: portrait versus landscape -- on a tablet and you are oriented in
a kind of portrait mode things are going to lineup up and down instead
of side to side. For phone users that's not really an issue. Screen is
still small enough that pixel density is small enough that you're still
gonna have that mobile looking layout. But on tablets enough screen real
estate that it switches to the...
... desktop layout -- the problem is the differences in layouts that you
get when switching, especially on tablets
<davidmacdonald> Some mobile applications automatically set the screen
to a particular display orientation (landscape or portrait) and expect
that users will respond by rotating the mobile device to match. However,
some users have their mobile devices mounted in a fixed orientation
(e.g. on the arm of a power wheelchair).
<davidmacdonald> Therefore, mobile application developers should try to
support both orientations. If it is not possible to support both
orientations, developers should ensure that it is easy for all users to
change the orientation to return to a point at which their device
orientation is supported.
<davidmacdonald> Changes in orientation must be programmatically exposed
to ensure detection by assistive technology such as screen readers. For
example, if a screen reader user is unaware that the orientation has
changed the user might perform incorrect navigation commands.
<jon_avila> You can detect orientation but you can't change it from
JavaScript
<jon_avila> Correct
Chris: for native applications it's completely different -- you can lock
in and that's really bad for someone who can't change orientation -- for
native apps this is a huge issue
Jeanne: dropped in orientation specs
<patrick_h_lauke>
https://drafts.csswg.org/css-device-adapt/#orientation-desc
Patrick: authors do in a haphazard way currently because they can detect
the orientation -- many games for mobile which are only designed to work
in landscape and if you view that particular page in portrait all you
get is please turn your device to landscape mode. So some, however valid
or not, already do this. So I'm assuming for mobile this area can be
problematic
... I think in general there's a lot of crossover -- falls along the
lines of the more responsive approach in general of making sure that you
are not blocking users based on the aspect ratio of their viewpoint.
Don't block your content to only work in specific aspect ratios
<jon_avila> Some Android Keystrokes
http://freaktab.com/forum/tv-player-support/general-tv-player-dicussions/19428-android-external-keyboard-shortcut-keys-documentation
Chris: is that an accessibility issue or user issue. Looking at screen
and saying is my X real estate greater than my Y real estate -- issue
for everyone. Is there a use case that calls for X to be greater than the Y.
Patrick: might be a softer AAA, but there are groups it would affect
more than others
Kathy: just needs to be usable at a specific orientation -- might be the
ideal
Chris: with the real issue be just not allowing the orientation to change
Kathy: yes
... it's not that you're locking into a specific orientation, just that
you're not allowing them to change. if it's not locked, you can use it
in portrait size on the landscape screen
David: a mechanism is available to change the orientation... If they've
overridden the mechanisms that will fail.
... if we just keep people from locking it we may have a pretty easy
success criterion to get through here
Patrick: instead of making it about the mechanism making it about the
content -- content can be experienced at different orientations. The
idea of a mechanism to switch it is sufficient technique, possibly
exceptions for things like if the content actually requires -- is only
one aspect ratio providing that is a, similar to playing piano on the screen
<jon_avila> What if you need the landscape area to display content?
David: we had quite a few discussions during WCAG 2 about that. Passive
to say can change the orientation, the more active a mechanism is
available. I think they say the same thing. A mechanism is available is
saying it could be anywhere, just somehow this can be done. And then you
can have a failure technique to change orientation or something like that
<patrick_h_lauke> to me "mechanism" just makes me think of "authors need
to provide a switch", when in most cases it's about "don't lock it /
don't do something"
Chris: I don't know what precedent is here but the reason I don't like a
mechanism is available is because screen orientation and setting are
heavily linked to the way the operating system wants to do things --
what it tells native apps, web browsers to render. So the reason I don't
like a mechanism is available to change the orientation is because what
if you are a user who has enabled that...
... locking of the orientation and so you are sitting there using it in
portrait mode and then what I'm envisioning if you use a mechanism is
available what you would allow to happen is for someone to come into an
application and have it initially be sideways. So they see this perhaps
I'd ways perhaps upside down version of the orientation and then there's
a toggle in the corner that the user...
... is reading upside down that says rotate 90°. That wording allows
that to happen. That's why I don't like it. I think you should say don't
override the OS or user agent perception of what up and down is
Patrick: that sounds to me like a sufficient technique
... it would satisfy the success criterion
Chris: but is it useful to the user if it's upside down
Patrick: when I read a mechanism is available that immediately makes me
think I have to do something, where in effect it's the opposite. I
shouldn't block orientation I shouldn't force a orientation, so it's
something less that I should do rather than having something
Chris: don't fight it working the way it wants to work
<davidmacdonald> 1.4.2 Audio Control: If any audio on a Web page plays
automatically for more than 3 seconds, either a mechanism is available
to pause or stop the audio, or a mechanism is available to control audio
volume independently from the overall system volume level. (Level A)
<davidmacdonald> Note: Since any content that does not meet this success
criterion can interfere with a user's ability to use the whole page, all
content on the Web page (whether or not it is used to meet other success
criteria) must meet this success criterion. See Conformance Requirement
5: Non-Interference.
David: example -- when they use this mechanism they always have a note
containing more information
... fallback is the author has to do something or the browser does it.
Came about with zoom. Some of the browsers could do it then and some of
them couldn't. Gives a guilt feeling on the author to do something, but
if it's not in the browser or the operating systems are going to have to
do it
Patrick: looking at some of the other SCs wordings. 1.4.1 use of color
-- actively says
<davidmacdonald> Natural orientationdoes not override the orientation OR
a mechanism is available
Patrick: subject is content rather than immediately jumping to the
opposite side with mechanism wording -- seems like a double negative to
get to the result
David: how about starting out with don't override
Patrick: cautiously yes
David: I think this could be a next candidate.It seems like we are
moving in a direction. Chris has a really great thing to think about --
the instruction is upside down
... I don't see another way out right now. You don't want to handcuff
the author so much that he can't make his game. Is there a way to suss
out the mechanism that's being used on the device and provide
notification to that mechanism in a way that is not broken and use
current orientation
Chris: there are for native apps but the only way to do it for apps on
websites are Hackey
Patrick: iOS and most recent android supported -- have to research it
Kathy: I think it's worthwhile to do research on that. Maybe a page on
the wiki and start that research
<patrick_h_lauke> deviceorientation supported in all current mobile
platforms http://caniuse.com/#search=deviceorientation
<davidmacdonald> Content does not override the user's device orientation
OR a mechanism is available to change the orientation.
Kathy: two different success criteria under that guideline. It doesn't
really cross over to the other taskforces right now
... if we can all start thinking about this will have a more detailed
discussion and will continue work. I'll send you the details about that
call on Tuesday
<patrick_h_lauke> while i'm here, can i shamelessly ask if anybody has
any comments on this?
https://lists.w3.org/Archives/Public/w3c-wai-gl/2016AprJun/0425.html
(just because it circles the same drain we went around of "physical
measures vs pixels") :)
<scribe> chair: Kathleen_Wahlbin
Summary of Action Items
*[NEW]* *ACTION:* Chris blog item on keyboard shortcuts on iOS and
Android and send us the link [recorded in
http://www.w3.org/2016/05/05-mobile-a11y-minutes.html#action01]
Summary of Resolutions
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/05/05 16:05:18 $
___________________________________________________
Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>
www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly
Blog: Patch on Speech
+Kim Patch
@RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________
Received on Thursday, 5 May 2016 16:34:21 UTC