UNKNOWN_SPEAKER: different application for different parts of the service
... and received feedback
... so they formed task forces to address

<patrick_h_lauke> Scribe: AWK

Objective: share implementation practices from Alibaba

blind users use screen readers to navigate, on PC and mobile devices

presentation will share difficulties shared with team

use case 1: picture - no description

solution: alt attribute on img elements

case 2: verification code (CAPTCHA)

<patrick_h_lauke> AWK: as the slide contains HTML, are your apps native or hybrid (e.g. using phonegap)

screen reader users can't read it

solution: voice verification or SMS code verification

AWK: Which was better received?

KL: Not completely sure, think Voice

Case 3: Floating page

focus issues, closing issues

solution: ensure dialog is focused and able to be closed

case 4: focus

no focus on page, user can't select

for each element, ensure focus with attribute

case 5: controls

missing labels

solution: add labels

case 6: missing labels

solution: use for attribute

Gap analysis

In WCAG there is a need for more details

more techniques!

Next steps

detailed drafts will be submitted to document the issues and practices

AWK: These are the common issues, were there more

<patrick_h_lauke> AWK: now that you've addressed things as per your slides, do you still have issues that users are reporting?

KL: yes, some issues addressed but there were more

chunming: interested in the MATF
... talked with Judy Brewer, told that we are increasing mobile guidance in WCAG
... we may like to participate in effort

PL: Issues seem to be largely in WCAG 2.0
... seems to be following WCAG best practices well

AWK: the SMS integration is a solution that is more mobile focused but increasingly available on desktop also

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

IP: WCAG doesn't specifically speak to things like the dialog issue mentioned

(floating page)

<patrick_h_lauke> Patrick: here's some of the work we're doing specifically in the "Mobile" Accessibility Taskforce, particularly focused on different input modalitites https://gist.github.com/patrickhlauke/96110b10547770021e58f5098dd31087

AWK: speaks to a need for more techniques

PL: (sharing gist of current work of MATF)
... moving to a situation where there are many modalities that need to be covered for input
... currently in WCAG we have keyboard-specific items, but not touch
... or pointer devices
... also looking to address size of targets

to ensure that they aren't too small

scribe: avoiding accidental activation also
... and when running a keyboard and assistive technologies
... input independence is also needed - can't rely on just one way to interact
... for apps running in a closed environment (e.g. kiosk/ATM) may not need to support a keyboard if there is no way to add a keyboard
... The MATF also has SC proposals related to voice interaction
... And related to device sensors
... Some applications may rely on device sensors exclusively in some situations (e.g. a marble game where tilting the device is the game)

Non-interference with assistive technologies is the final SC being proposed.

IP: question: is that AT-specific?

Section 508 has criteria that says to not interfere with user system settings

PL: builds on that idea a bit

KL: question b/c mobile devices don't have keyboards - how to handle?

PL: can connect a keyboard via bluetooth and use it

AWK: WCAG covers a lot of what you need to do for mobile device support, but more is needed and that is why we have the task force and the WCAG 2.1 effort

PL: there are also issues for users who use mobile OS zoom features - some issues can occur when using mobile zoom and trying to pinch and zoom

KL: which issues affect users who are blind or VI?

PL: We don't generally differentiate since the success criteria impact more than one user type each

JS: China has very active blind user group

<patrick_h_lauke> AWK: reiterating that with SCs we try to not differentiate by user group/disability

<patrick_h_lauke> even if an SC may initially look/sound like it's only targeted at a particular disability, it has benefits well beyond those

KL: why have a LVTF?

<patrick_h_lauke> KL: and why not a blind user TF specifically

<patrick_h_lauke> AWK: there was feeling from specifically LV users that felt WCAG 2.0 doesn't address very particular problems of LV

<patrick_h_lauke> which is why there is a user group/disability specific TF

<patrick_h_lauke> jcraig yeah sorry it's not on the grid for some reason

<patrick_h_lauke> in 1.03 if you still want to pop in

KL ;question about keyboard trap

PL: explained
... that keyboard trap and focus trap are the same issue

KL: how to contribute?
... will go back to teams for more information

AWK: everyone's help is needed! Welcome to join the group...

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)

Succeeded: s/keybaord/keyboard/
Found Scribe: AWK
Inferring ScribeNick: AWK

WARNING: No "Topic:" lines found.

Present: chunming kepeng IanPouncey jeanne patrick_h_lauke AWK QingAn

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


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

Got date from IRC log name: 21 Sep 2016
Guessing minutes URL: http://www.w3.org/2016/09/21-matf-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