W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

14 Jul 2016

See also: IRC log

Attendees

Present
Kathy, jeanne, chriscm
Regrets
Kim, Patrick
Chair
SV_MEETING_CHAIR
Scribe
jeanne

Contents


<scribe> scribe: jeanne

<kathy_> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision/modification/addition_to_Guideline_2.1_and_related_SCs_to_cover_touch%2BAT_scenarios

Kathy: If people have been following the long thread on the mail list on modifying 2.1.1, 2,1,2, 2,1,3

Three options:

1) Modify the 2.1.1-3

2) modify the keyboard definition to include touch interface

3) Add additional SC to cover touch interface.

Kathy: John FOliot is currently looking at options for 2.1
... we need direction on which way to go
... we are getting stalled in how everything is going to fit together
... on next Teuwsday WCAG call, JohnF will present options of how they can fit together and see what they mean.
... it's not theortical anymore, this is a practical example
... Patrick has done a good job in laying out how these can be modified.

+1 to follow the thread.

Marc: working my way through it

David: The difference in Gregg's concerns and Patrick's concern is that Gregg doesn't want to see multiple ideas in the same SC.
... gregg has concerns beyond a lack of understanding.
... when you have sufficient techniques, you want to meet the Technique to meet the entire SC. There would be a number of Techniques that would have to require "AND"s in order to meet the entire SC.
... he thought there would be misunderstanding
... I'm not clear on the abstract layer. I think the burden is on Patrick to demonstrate that everything that is covered in the old SC be covered in the new SC.
... how are we going to communicate that to the public. I don't understand it, and many others don't understand it. We have to be clear that it is an AND and not an OR.
... the easy way is to add new Success Criteria
... IndieUI crashed, and they are trying to figure it out in WAI-ARIA. I think it is premature to push this through. I'm leaning toward having new success criteria.

Kathy: I would like to have the wiki page modified with people's positions.
... summarize it on the wiki so it is all in one place

<kathy_> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision/modification/addition_to_Guideline_2.1_and_related_SCs_to_cover_touch%2BAT_scenarios

Chris: The sequential order shouldn't change
... tab navigation might not care about interactive elements

David: Sequential navigation isn't the tab order, its the arrow.

Chris: that's not true on TalkBack. It might be true for web ATs.

David: If you have talkback on, then things are not interactive?

Chris: With AT on, yes.

David: then that's a bug

Chris: they each have their own focus(next). If the devleoper doesn't define that, then it is left to the OS.
... do swipes vs arrows. If you change from one type of navigation to another, it is very confusing

David: It don't understand the layers of the APIs that are grabbing keystrokes vs APIs for swipes. I want to learn how to understand it.

Chris: that is my speciality. I'm happy to explain it offline.

David: When I get into the mobile space and APIs I don't know what to do. I guess I am not the only one.

?

Kathy: Chris, what do you think at the technical level?

Chris: I think we need a 2.1.4 to take care of some of the mobile issues. They would not be applicable in a keyboard-only environment.
... that will be too confusing for people who are not working in the mobile space. Where there are truly mobile specific things. Don't confuse the issue for non-mobile people

Henny: But we have situations where theere are touchscreens on desktop.

Chris: When we talk about mobile, we are including touchscreens.

Henny: we have to be careful about it.

David: Give a quick explanation.

Chris: using Android, but it applies to Apple as well. Apple does close the source, but it will work approxiamately the same.
... 3 different layers
... backend linux kernal that works like a desktop operating system.
... secondary OS layer that is the Android UI. Similar to the browser running on top of the desktop
... backend passes keystrokes to the OS.
... OS grabs the events
... the events that we care about: 6 events: 4 arrows and tab key and swipe events.
... unlike the other events that are passed through the OS, these get passed down to the Accessibility Service.
... these are the differ3ences between the desktop and mobile, it is confusing with developers, because they can avoid the accessibility events, and they do.
... the tab and arrow keys are handled well by default
... but the AT for swipe-forward and swipe-backward are only invoked with AT and therefore can be overlooked by developers.

<Detlev> sorry, can't get the webex .exe to run...

Chris: Those are the most important pieces pertaining to these SCs

David: Patrick is going to a higher level. Where does onclick relate to these layers

Chris: onclick events - when a person initiates a click, it is a hardware event and the OS handles it a specific way.
... you can use onmousedown and onmouseup, and that will not work with a keyboard.
... it is confusing, becaue the top layer (talkback) is not part of the OS and can be modified at will.

David: [gives example]

Chris: If you are on the thing you want. You double-tap. The SWervie will ask if it is actionable, and then send the Accessibility-click action. Then the OS will try to send it the appropriate action that it has.

<Detlev> checking

David: the more I hear about this, I think we should leave 2.1 as it is.

<Zakim> jeanne, you wanted to say that caution in increasing size of WCAG is important. Consolidate whereever possible.

Jeanne: We need to be cautious about adding a lot of new success criteria. If each group adds 10 success criteria, then we are increasing WCAG by 1/3

David: It won't be that many

Jeanne: We still have to pay attention to increasing the size.
... We should work to consolidate whereever we can. Obviously, we can't combine things we shouldn't, but we have to think about the size of what we are including.

Kathy: We are going back to work that we did weeks ago. We keep going back to different issues without resolvig them.

Kathy [recaps history]

David: Why can't we say that everything has to work with assistive technology turned on?

Kathy: that is one of the options - option 3 where we have a section on touch and pointer.

David: I think they are different things, what Chris says, then turning on Assistive Technology won't work
... Device manimputlation is not going to fix the problems at touch. When you turn on that 3rd level, that will when things start breaking. People don't test with assistive technology

Chris: There is no real need for the hardware separation. Isn't what we are really talking about is including swipe gestures in the OS at the same level as the tab and arrow.
... this should be handled at the OS level
... if we change the definition of keyboard to be sequential navigation than everything works.

Jeanne: +1. We should not be making complex solutions for authors, when it could be solved simply at the OS level.

David: Would that work?

Chris: yes, if someone comes along and invents mouse 2.0. Let's suppose it is not a hardware devcie, but it sending it's own weird modified events. That's not the proper wway to do things, because it requires authors to create hacks to allow the mouse 2.0 to work. When you make it the mouse 2.0 use the mouse 1.0 interface, then everything work the way it should. These ATs are sending

<scribe> new events to the OS and the developers don't know them, then things will break.

David: So you are saying to map them to the arrow and the tab keys?

Chris: Yes. Then they will be keyboard accessible even if talkback is on, because the talkback events will be interpreted as equvalent to keyboard events.

David: [recaps]
... because we think we can deal with it on another level, then we don't need a separate SC that says that things have to work even if assistive technology is turned on.

Kathy: It seems like we are repeating the same issues over and over. Patrick took the initiative to tweak the 2.1 guidleine to include these issues.

David: So if we do this, then when people turn on AT, it will just work. That seems very optimistic.
... IndieUI was torpedoed by the user agents, maybe I am wrong about this. They don't want to be mandated to do this.

Jeanne: there are browsers that add accessibility features without being forced. Zoom text is a great example. Chrome is adding accessibility features often, without being forced. I think giving clear advice to browsers how to fix a problem is better than forcing web developers to write lots of complex code just to fix a user agent problem.

Chris: Jeanne talked about the browser as a user agent. But on mobile, the OS is where this handled. It is an order of magnitude more to ask the mobile OS manufacturers to fix this.
... what would web devleopers need to do to make the AT work today? Is that david's question?

David: I want us to fix it today.

Chris: We are talking about multiple layers. For this example, keyboard happens at the OS level, and AT works at the accessibility layer. We want the web developer to make the acessibility layer work the same as the OS level. The only way to ensure that the tab order works the same way is to muck with the default ordering. That is the opposite of the way you want to make accessibility

work on the desktop level. We would be forcing developers to do the thing that is mostly likely to really mess things up.

David: We want tabbing to work like tabbing.

Chris: I've seen the settings screen that you are talking about, and it has a built-in trap.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/07/14 16:02:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Found Scribe: jeanne
Inferring ScribeNick: jeanne

WARNING: No "Topic:" lines found.

Present: Kathy jeanne chriscm
Regrets: Kim Patrick

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 14 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/14-mobile-a11y-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]