Mobile Accessibility TF Minutes from June 20th, 2014.

http://www.w3.org/2014/06/20-mobile-a11y-minutes.html



[image: W3C] <http://www.w3.org/>
- DRAFT -Mobile Accessibility Task Force Teleconference20 Jun 2014

See also: IRC log <http://www.w3.org/2014/06/20-mobile-a11y-irc>
Attendees

*Present*

*Kathy_Wahlbin, +1.910.278.aaaa, kathleen, Jeanne, [IPcaller], wuwei, Jan,
Detlev, Tim_Boland*

*Regrets*

*alan*

*Chair*

*Kathy Wahlbin*

*Scribe*

*Jan, jon_avila*
Contents

   - Topics <http://www.w3.org/2014/06/20-mobile-a11y-minutes.html#agenda>

1.   15. Use simple navigation concepts with consistent interaction patterns
<http://www.w3.org/2014/06/20-mobile-a11y-minutes.html#item01>

2.   #16 Allow users to interact with hardware device buttons.
<http://www.w3.org/2014/06/20-mobile-a11y-minutes.html#item02>

3.   #17 ensure interface can be used with bluetooth keyboard.
<http://www.w3.org/2014/06/20-mobile-a11y-minutes.html#item03>

4.   #18 Add shortcuts to allow users to jump to sections of page.
<http://www.w3.org/2014/06/20-mobile-a11y-minutes.html#item04>

5.   #19 Provide a way for users to change font.
<http://www.w3.org/2014/06/20-mobile-a11y-minutes.html#item05>

6.   #20 provide support for alternative mechanisms for devices that do not
have or support a physical or equivalent keyboard
<http://www.w3.org/2014/06/20-mobile-a11y-minutes.html#item06>

   - Summary of Action Items
   <http://www.w3.org/2014/06/20-mobile-a11y-minutes.html#ActionSummary>

------------------------------

<*trackbot*> Date: 20 June 2014

<*Kathy*> meeting: Mobile A11Y TF

<*Jan*> scribe: Jan

<*Kathy*> https://www.w3.org/2002/09/wbs/66524/20140512_survey/results#xq16

*Kathy:* Over past few weeks we've been going over survey to see where the
techs fit
... I want to get through next 5
... We are on num 15
15. Use simple navigation concepts with consistent interaction patterns

*Detlev:* Hard to define in a way that has a clear test....

*Kathy:* Is there anything around consistent nav patterns...
... that might be necessary for responsive design or mobile?

*Detlev:* Rephrase?

*Kathy:* Often with responsive desing, nav mechanisms do change.

*Jan:* Maybe this is a note on 3.2.3 to say it is ok if nav mechanisms
change between responsive design

*Kathy:* Would orientation be a problem?

*Detlev:* No as long as same functions are available...multiple ways

*Jon:* If it's broken for everyone, then its not accessibility related
... Within that view, you need consistency
... Idea of conformance claim to just one responsive version

*JAn:* Can see a problem with that

*Jon:* I agree its an issue

*Kathy:* What is Alastair putting together?

*Jon:* A technique....I will put in a link

*Detlev:* Can I add...from evaluation methodologies mtg....
... Whether different versions are different.....EM group will say that
different responsive design versions are NOT different versions...just
different states

<*jon_avila*>
https://www.w3.org/WAI/GL/wiki/Using_a_script_load_toggle_for_feature_detection_libraries_to_provide_a_conforming_alternate_version

*Detlev:* Nomensa Alastair?

*Jon:* We decided to base on progressive enhancement, not responsive design
... So different, but it becomes a lot to test
... What are yoyu saying?

*Detlev:* Even the designer has catered for different versions with queries
etc then those versions should be covered as states for the test

<*jon_avila*> scribe: jon_avila

<*Detlev*> 1+

*kathy:* summary of #15 is that we would map to 3.2.3 and 2.4.5. Put in
mobile note on consistency within a viewport size. No new technique, we can
incoporate into other techniques

<*kathleen*> +1

*RESOLUTION: #15 is that we would map to 3.2.3 and 2.4.5. Put in mobile
note on consistency within a viewport size. No new technique, we can
incoporate into other techniques*
#16 Allow users to interact with hardware device buttons.

*kathy:* some respondants say advisory and others say sufficient techniques

*jan:* discussion if this is UAAG crossover or not.

*kathy:* make a note in the technique about device buttons

*detlev:* May want to widen device buttons to include other input
mechanisms such as shaking, etc. to dismiss or undo, some of these are
device specific.

*kathy:* you're saying if the device allows a gesture or physical buttons
then they should be supported?

*detlev:* not sure if we want to stop at button or include other potential
input mechanisms. May need a refererence to IndieUI

*jon_avila:* concern over allow it to meet a SC without providing other
types of access beyond just this gesture.

*RESOLUTION: Advisory technique under 2.1.1*
#17 ensure interface can be used with bluetooth keyboard.

*kathleen:* modify way it's word. If it's supported by the platform. Maybe
changed bluetooth keyboard to input devices.

*jan:* also USB to go to connect USB.

*kathy:* ton of bluetooth devices that would get included - never ending
stream including switch devices - alot to test.
... could add a mobile note to current keyboard techniques. Could be
different devices based on what you have identified as accessibility
supported.

*detlev:* set base level of accessibility support on a particular device
with keyboard., theoreticaly example.

*kathy:* if we look at creating a new one or incorporating, what is
preference?

*jon_avila:* g202 is a general keyboard technique that might be used.

*kathy:* any objections to adding to g202?

*RESOLUTION: Add note to g202 about other external devices. Add in notes
about support for device or bluetooth device.*
#18 Add shortcuts to allow users to jump to sections of page.

*kathleen:* if it was advisory you should still pass, is that right?

*kathy:* either with a ST or AT

*kathleen:* we could show them how to do it but they won't necessarily have
to, correct?

*kathy:* correct.
... already covered, perhaps app would be different. Could use app specific
things like heading traits

*jon_avila:* keyboard shortcuts covered under advisory already as future
link under 2.1.1.

<*Detlev*> fine

*kathy:* any objections to build out advisory technique

*RESOLUTION: Advisory technique to 2.1.1*
#19 Provide a way for users to change font.

*jeanne:* sounds like UAAG
... capabilities should part of browser and OS not developers responibility

*jon_avila:* concern over lack of support in current devices. Could perhaps
be an advisory technique or best practice for current state -- it would be
good if user agents did this -- but most mobile devices are not doing this.

<*Detlev*> Sone apps like Pocket allow this I think

*kathy:* could we point to UAAG and then say if device doesn't support it.

*kathleen:* are we talking about font size, color, font face, etc.

*kathy:* that's currently not listed.

<*jeanne*> UAAG 1.4.1 http://jspellman.github.io/UAAG/UAAG20/#sc_141

*detlev:* additional settings in apps are welcome to users with low vision
because settings do not propogate.

*kathy:* if we were to re-write to incorporate what we mean?

*kathleen:* what is the benefit of font type.

*kathy:* people with dyslexia

*tim:* c22 is a technique that talking about using CSS to control
presentation.
... c22 is advisory for 1.3.1

*detlev:* technique for native apps more than web apps?

*tim:* c22 is also advisory for 1.4.4.

*jon_avila:* put in c22, but also have a style switcher technique as a best
practice or advisory, etc.

<*Detlev*> sounds good

*kathy:* propose advisory technique for 1.4.4 or 1.4.8 to adjust visual
presentation on mobile

*RESOLUTION: advisory technique for 1.4.4 or 1.4.8 to adjust visual
presentation on mobile through a style switcher*
#20 provide support for alternative mechanisms for devices that do not have
or support a physical or equivalent keyboard

*kathy:* pick up next time.
... summarizing on wiki, meeting next week, no meeting on the 4th.

<*Detlev*> Bye

*kathy:* Thanks everybody
Summary of Action Items

[End of minutes]
------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version
1.138 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2014-06-20 15:00:17 $
------------------------------
Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11

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



Guessing input format: RRSAgent_Text_Format (score 1.00)



Found Scribe: Jan

Inferring ScribeNick: Jan

Found Scribe: jon_avila

Inferring ScribeNick: jon_avila

Scribes: Jan, jon_avila

ScribeNicks: Jan, jon_avila

Default Present: Kathy_Wahlbin, +1.910.278.aaaa, kathleen, Jeanne,
[IPcaller], wuwei, Jan, Detlev, Tim_Boland

Present: Kathy_Wahlbin +1.910.278.aaaa kathleen Jeanne [IPcaller]
wuwei Jan Detlev Tim_Boland

Regrets: alan

Found Date: 20 Jun 2014

Guessing minutes URL: http://www.w3.org/2014/06/20-mobile-a11y-minutes.html

People with action items:



[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



703-637-8957 (o)
Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter
<http://twitter.com/#%21/SSBBARTGroup> | LinkedIn
<http://www.linkedin.com/company/355266?trk=tyah> | Blog
<http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>