See also: IRC log
<scribe> scribe: jeanne
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
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.
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]