Draft minutes from telco Oct 13 2016

http://www.w3.org/2016/10/13-mobile-a11y-minutes.html


[W3C]<http://www.w3.org/>

- DRAFT -
Mobile Accessibility Task Force Teleconference
13 Oct 2016

See also: IRC log<http://www.w3.org/2016/10/13-mobile-a11y-irc>

Attendees
Present
Kathy, DavidMacDonald, jon_avila, chriscm, marcjohlic, detlev, shadi, alan, Detlev
Regrets
Kim
Chair
Kathy
Scribe
jon_avila
Contents

  *   Topics<http://www.w3.org/2016/10/13-mobile-a11y-minutes.html#agenda>
  *   Summary of Action Items<http://www.w3.org/2016/10/13-mobile-a11y-minutes.html#ActionSummary>
  *   Summary of Resolutions<http://www.w3.org/2016/10/13-mobile-a11y-minutes.html#ResolutionSummary>

________________________________

<Kathy> meeting: Mobile A11Y TF

<DavidMacDonald> test

<Kathy> https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m4.md

<Kathy> https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m10.md

<chriscm> Kathy:This deals with things that remap keyboard shortcuts.

<chriscm> Kathy: you could argue the same thing with touch

<chriscm> Detlev: AT traps events and uses them up.

<chriscm> Kathy: THere's still a hole in there, but we have this, it's solid, so push it through.

<Kathy> https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m4.md

<chriscm> Detlev: "Tied to a keyboard" is a little informal.

<Kathy> All functionality activated by a keyboard input can be operated when assistive technologies that remap keyboard controls are present.

<chriscm> Detlev+Kathy: editorial comments.

<chriscm> Jon: What can the author do at this time?

<chriscm> Kathy: Don't override keyup/keydown events.

<chriscm> Detlev: There's nothing specifically mobile about it, but it plugs a hole in certain keystrokes can be mapped by assistive technology.

<chriscm> Jon: I understand the need, but we should focus on mobile issues. We're only gonna get a couple of these in.

<chriscm> Kathy: We're going to be looking at all input type stuff together. There is some concern about number of Success Criteria, but there are no limits. Good criteria will be looked at.

<chriscm> Patrick: We could write an assistive technology that breaks this criteria.

<chriscm> Kathy: If you look back at WCAG2.0, conformance and AT, you would have to support this AT then this would apply.

<DavidMacDonald> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head

<chriscm> Detlev: WE have an accessibility support provision requirement specifying platform AT.

<chriscm> Kathy: Should we add something saying this only applies to ATs on the "Support list"

<Kathy> This success criteria would apply to the assistive technology that is accessibility supported and remaps the keyboard.

afk

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements

<chriscm> Detlev: All functions available by keyboard are still available by keyboard with AT attached.

<DavidMacDonald> All functions available by touch are still available by keyboard after platform assistive technology that remaps keyboard is turned on.

<Kathy> All functions available by keyboard are still available by keyboard after accessibiltiy supported assistive technology that remaps keyboard is turned on.

<chriscm> David: You'd probably have to say remaps keystrokes.

<Kathy> All functions available by keyboard are still available by keyboard after accessibility supported assistive technology that remaps keystrokes is turned on.

I am back

<chriscm> David: If we made our own AT this would break it.

<Alan_Smith> present

<chriscm> Kathy: Not if it's not in your platform support model. You can pick the AT you spport.

<chriscm> David: How many companies have a support document?

<chriscm> Jon: Most customers don't do full conformance, so they usually do a support statement.

<Kathy> This ensures that all users can operate the functionality when the keyboard is used with the assistive technology.

<chriscm> Kathy: Benefits sections needs to be built up on this.

<Kathy> 1. Turn on the assistive technology that remaps the keyboard 2. Use the keyboard to operate the functions on the page.

<Kathy> 1. Turn on the assistive technology that remaps the keyboard 2. Use the keyboard to operate the functions on the page. 3. Ensure that all functionality can be done.

<chriscm> Kathy: Testability sections, suggestions/changes?

<marcjohlic> Check that #3 is true

<chriscm> Marc: It's actually not easy to test, because you wouldn't know what keyboard strokes would be supported.

<chriscm> Oops Detlev: 10025 E Highland Rd, Howell, MI 48843

<chriscm> Detlev: It's actually not easy to test, because you wouldn't know what keyboard strokes would be supported.

<chriscm> Jon: It makes accessing the application challenging for the user. There's also pass key through.

<chriscm> David: The difference between this and desktop, is because touch pass through isn't an option.

<Kathy> 1. Determine what functions can be done with the keyboard. 2. Turn on the assistive technology that remaps the keyboard 3. Use the keyboard to operate the functions on the screen. Check all possible keystrokes and combinations of keystrokes. 4. Check that #3 is true

<chriscm> Detlev: The point is if AT allows you to use these keys, this is automatically passed.

<chriscm> Jon: I don't think it's a huge issue on Android, because the normal keystrokes are sent through to the browser anyway.

<chriscm> Detlev: This success criteria wasn't intended exclusively for Mobile Operating Systems.

<Kathy> https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m10.md

<chriscm> David: That was at the end when Patrick was trying to make one mega success criteria, it instead ended up split into multiple success criteria.

<chriscm> Kathy: Moving on to M10.

<chriscm> Detlev: Unless the function is essential, if the pointer input draws a line, you can't replace that with a keyboard.

<chriscm> Detlev: If the censor function is required for the functionality, this doesn't apply.

<Kathy> All functionality can be operated without requiring specific device sensor information unless the device sensor is required the activity.

<chriscm> Kathy: "All functionality can be operated without requiring specific device sensor information unless the device sensor is required the activity."

<Kathy> All functionality can be operated without requiring specific device sensor information unless the device sensor is required for carrying out the function.

<chriscm> Detlev: If an action occurs when you lift the device to your ear, but you can't lift the device, there should be a way to get that functionality otherwise.

<scribe> scribe: jon_avila

alan: is the only means?

<Kathy> unless the device sensor is essential for the function.

detlev: carry out isn't the right term, essential is right -- essential for function to work

kw: unless device sensory is essential for function.

david: is essential and would invalidate activity

<DavidMacDonald> is essential and extending it would invalidate the activity; or ... from 2.2.1

detlev: and not using it would invalidate the activity

<Kathy> All functionality can be operated without requiring specific device sensor information unless the device sensor is essential for the function and not using it would invalidate the activity.

detlev: fair enough

<jon_avila_> scribe: jon_avila

<jon_avila_> IRC stopped working for me, but I am back now

<jon_avila_> detlev: prefer term functionality, too specific to use of content.

<jon_avila_> ja: support using "of the content" as content is broad in WCAG and includes sensory and functionality

<jon_avila_> david: 3.3.3 and many other SC use "of the content".

<Kathy> All functionality of the content can be operated without requiring specific device sensor information unless the device sensor is essential for the function and not using it would invalidate the activity.

<jon_avila_> detlev: not pressing the case so put it in

<jon_avila_> kw: any changes? 3 minutes left

<jon_avila_> kw: hearing no changes, we will propose this, will create pull request

<jon_avila_> david: would be good to move this to our control rather than off of patrick

<jon_avila_> kw: under w3c mobile a11y extension. not sure why I don't have control -- I use to have control. Perhaps when Shadi made some changes?

<jon_avila_> detlev: had done some editing through pull requests

<jon_avila_> david: patrick does appear to have editing rights

<jon_avila_> kw: m6 is about input agnostic

<jon_avila_> kw: just going down through list

<jon_avila_> kw: go through orientation m13 and m6 next call

<jon_avila_> trackbot, end meeting

Summary of Action Items
Summary of Resolutions
[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.148 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/10/13 16:02:49 $
________________________________
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14

Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/



Guessing input format: RRSAgent_Text_Format (score 1.00)



Found Scribe: jon_avila

Inferring ScribeNick: jon_avila

Found Scribe: jon_avila



WARNING: No "Topic:" lines found.



Default Present: Kathy, DavidMacDonald, jon_avila, chriscm, marcjohlic, detlev, shadi, alan

Present: Kathy DavidMacDonald jon_avila chriscm marcjohlic detlev shadi alan Detlev

Regrets: Kim

Found Date: 13 Oct 2016

Guessing minutes URL: http://www.w3.org/2016/10/13-mobile-a11y-minutes.html

People with action items:



WARNING: Input appears to use implicit continuation lines.

You may need the "-implicitContinuations" option.





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<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> diagnostic output]

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)
Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>