See also: IRC log
<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)
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
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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 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: Kim Inferring Scribes: Kim Default Present: patrick_h_lauke, jon_avila, Kathy, Kim, marcjohlic Present: patrick_h_lauke jon_avila Kathy Kim marcjohlic Jeanne David Chris Regrets: Henny Alistair Alan Found Date: 05 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/05-mobile-a11y-minutes.html People with action items: chris[End of scribe.perl diagnostic output]