Mobile Accessibility Task Force Teleconference -- 14 May 2015

<trackbot> Date: 14 May 2015

WebEx link: https://mit.webex.com/mit/j.php?MTID=m523c9f623a4979f4952a9bb93531b909

password for webex: matf

WebEx link: https://mit.webex.com/mit/j.php?MTID=m523c9f623a4979f4952a9bb93531b909

<Alan_Smith> I am only in on irc, password for webex did not work and I cannot call from Italy

<Kathy> it needs to be all lower case

<Alan_Smith> Kim's email had password as 6283

<Alan_Smith> ok, I'll try. Thanks

<Alan_Smith> Working on ipad mini and windows 8 tablet from italy

<jon_avila> I wish there was a way to stop Cisco from flashing

<Kathy> http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Perceivable_Techniques

Perceivable Best Practices - nonlinear and screen layout

Kathy: best practices, advisory or sufficient – what issue should we have listed pertaining to nonlinear screen layout
... is there anything more we need or is this more of a best practice

Marc: would focus order or meaningful sequence come into play

Kathy: this is where you have a whole page coming in from the side – it could have a focus order

Marc: if you swipe from the side and it covers only a quarter of the screen like a menu wouldn't change focus

Jeanne: along the lines of ignoring the Dom we should have an extensive conversation about this everywhere in the accessibility field.
... ignore Dom and use accessibility APIs instead but accessibility APIs don't always provide all information.
... if browsers ignore Dom there are huge implications
... ignoring the Dom can increase speed of browser
... there's a proposal to PF called WAPA that talks about this. Not going to download ARIA information unless they get the query from an API I don't know how much aria is used outside assistive technology, but if it does… I don't know how much this will affect things, but we need to think about these issues

Jon: there are a lot of other things that can rely on those things that aren't necessarily accessibility – headings. I'm also concerned about just in time loading of accessibility features.

Jeanne: maybe that's something we can say here pretty simply. Anything working outside the DOM has to be properly communicated to the accessibility API. I don't want to write that technique but I know people who we can go to who do
... highly recommend talking to colleagues who are in PF with these issues. If they have looked at this issue and have said it's not a problem we need to know the reasoning

<jeanne> Anything working outside the DOM must communicate it to the accessibilityAPI

Jon: looking things up – if you use speech recognition and you want to use your voice to programmatically affect an element it's not a two-way street
... one of the things that is proposed is the assistive technology should be able to communicate back to platforms which includes browsers to get a set of the actions that are available to control and to be able to perform those actions that are available from the assistive technology
... the concept is good because it provides assistive technology another way to get access to the information. What concerns me is if we solely rely on that and not the Dom you going to block a bunch of technology that can't access the API. It really depends on if there's fall back support provided in the Dom. I think it's good but there could be consequences that are negative

<jon_avila> https://github.com/cyns/wapa

Kathy: we will leave that for now we can come back and review that again
... the other thing that we had in our list from before and this came from the BBC guidelines

<jeanne> DId we already discuss the need for signalling to the user that there is information that can be pulled from the side.

Kathy: M19

Jeanne: back to nonlinear – we need to signal users that there is something available

Kathy: I think it's important to have the correct affordances

Jeanne: also focus

Marc: focus order

Alan: question about nonlinear – is that a side menu coming into the screen

Jeanne: the use case I was thinking of is swiping into an article, how do you know

so you don't lose your location on the main page

Jeanne: I think we have a lot in nonlinear

Alan: do we have a list - focus, reading order, should something come in and take focus over the reading order that's hidden

Mike: on the nonlinear case it seems like at least two cases – when something slides in from half the screen that the user doesn't initiate an ad or something. The other thing is when something happens and when the user intends to go to that spot

Kathy: what's an example of where we would do that programmatically. I think that would fail WCAG right from the start – changing action not from the user focus but automatically

Mike: example, notification on the screen. Or I tap on a hamburger and something slides over half the screen but I intended to do that. Sometimes something happens, sometimes user causes it to happen in both cases it can be outside the DOM

Jeanne: useful to have these as use cases – browsers really want clear use cases for accessibility problems

Mike: here's another example I think we do this in Yahoo mail so I wont suggest whether it's good or bad. If you take an action and a message pops up about that action the message will pop up and become part of the swipe order on that screen – it's something the user initiated but it's not necessarily happening instantly it's happening sometime later
... another example is pop up banner ads that you don't want to take focus to, but that's just the way the website works

Jon: that last case would be a failure of 2.2.2. The first example sounds like a non-modal pop-up. I think they are working on that for aria 1.1

Kim: if a speech user doesn't realize the focus is going to change, they can get in trouble because they're issuing a command that goes to the wrong place. You can issue a stacked command and if the focus changes in the middle of command execution half the command can execute at a different focus point

Kathy: the last one in this list is metadata
... is this a technique that we should also include. Is this something that is specific to mobile – I don't think it is but would like to get your thoughts

Jon: could this be advisory? There are some meta-techniquesu under 1.1, says future technique, others audio only future technique

Kathy: we could add these in his advisory technique – is this something people think we should tackle? This is really relevant to what the BBC is doing.
... it does have some benefit for mobile because you could get an alternative version. Can you actually switch the sun mobile – the alternate version of webpages?

Marc: I'm over you can switch to the desktop version

Jon: on the mobile browser generally it's not very apparent

Kathy: maybe if it's not something that's readily implemented within the browsers lower priority item because it would be advisory right now

Jeanne: we should look at this in UAAG

<jeanne> ACTION: jeanne to research the use of metadata in UAAG as related to the M19 technique [recorded in http://www.w3.org/2015/05/14-mobile-a11y-minutes.html#action01]

<trackbot> Created ACTION-30 - Research the use of metadata in uaag as related to the m19 technique [on Jeanne F Spellman - due 2015-05-21].

Kathy: next week will get started on looking at feedback and questions from WCAG,, then take a look at understandable, then take a look at this as a whole to see if there are any other techniques that we want to do. We will also start talking about assignments. Some of them we already have in draft format that we can start passing over to the WCAG working group.

- DRAFT -

Mobile Accessibility Task Force Teleconference

14 May 2015

Attendees

Contents

Perceivable Best Practices - nonlinear and screen layout

Summary of Action Items

Scribe.perl diagnostic output