See also: IRC log
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[End of scribe.perl diagnostic output]