See also: IRC log
<trackbot> Date: 30 May 2014
<KimPatch> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques
<KimPatch> https://www.w3.org/2002/09/wbs/66524/20140512_survey/results
<KimPatch> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques
<KimPatch> https://www.w3.org/2002/09/wbs/66524/20140512_survey/results
kp: think we made it to number 11
on survey.
... Position form fields labels above the field is first
one.
... comments are that it should be before. May need exception
for radio buttons or when a change is made to landscape.
alan: comments on changing wording rather than above with respect to field.
jan: suggests adjacent to.
alan: left above may be easier for users.
kp: vote for adjacent to
kathleen: depends on the space you are working with on different devices
ja: issue would also occur on web that is non-mobile.
kathleen: don't need a new technique if there is already one.
<kathleen> http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-cues
<kathleen> http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140311/G162
ja: g162 should cover this.
... 11 position form fields labels above the field - already
advisory for SC 3.3.2 and covered by G162.
topic 12: Links should be adapted to screen width
kp: comments from Detlev it should be technique because links may need to be longer to distinguish them from others.
ja: what if the link wraps? Is that covered?
kp: could see it being an issue -- but not sure if it is any different from current requirements of text not being width of 80 characters indicated by 1.4.8
kathleen: links may contain other items other than text.
alan: Concern over wording.
kp: seems like its covered under 1.4.8 as it includes reference to measuring on desktop and not app to mobile screens
topic 12: Long link length covered in SC 1.4.8 - so keep this as best practice
topic 13: design clickable objects to look clickable.
kp: 2 votes for advisory, 2 sufficient, Jon and Kathleen for advisory
ja: important issue - iOS has included an option to make buttons look buttons and not flat objects.
kp: does UAAG have something that would apply?
Jeanne: UAAG guidelines are specific for highlighting, but I'm not sure if "make it look clickable" can be tested
ja: may be more important on mobile because there is no hover and not always a way to reach it with the keyboard.
<kathleen> http://codecraftingblueprints.com/make-clickable-things-look-clickable/
<kathleen> http://jimmymacsupport.com/make-buttons-look-like-buttons-ios-7-1/
kathleen: No hover on
mobile
... buttons get a box, currently selected tab has blue shading,
links get underlined - in 7.1 turn button shapes on.
kp: Important issue, there are solutions are other on different platforms. So do we add this, or this sufficient as it stands?
alan: wise to have something --
Apple has realized it wasn't sufficient to make it more
acceptable for users.
... what is the difference between sufficient and advisory.
jeanne: best practice can be
described but not tested. ST can be tested.
... make all focusable object meet the design standards of
their platform -- something like that.
ja: reference other standards and
one that might change.
... if you are creating something for multiple platforms then
you can't guarantee that it would work correctly
everywhere.
alan: some things may look actionable by themselves such as numbers in a keyboard. Perhaps more discussion is needed.
kp: What do we want to do? something is needed, but at what level?
jan: If you wrap something as a link -- that is telling the user that it's actioanble. The author has done what they. Could say don't say surpress something of being actionable
jeanne: what would the steps of the test be?
kp: Tim Boland joined.
<KimPatch> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/New_WCAG_2.0_Techniques
<KimPatch> https://www.w3.org/2002/09/wbs/66524/20140512_survey/results
jeanne: hard to make a test for buttons - links would be easier.
jan: if user overrides the button appears with CSS that would be suppression of it.
jeanne: get push back from
developers who say they can't modify the look of the
button.
... form sub group to work on it.
<scribe> ACTION: Jeanne work on this topic [recorded in http://www.w3.org/2014/05/30-mobile-a11y-minutes.html#action01]
<trackbot> Created ACTION-15 - Work on this topic [on Jeanne F Spellman - due 2014-06-06].
kathleen: interested in it
Alan: interested as well
topic 14: pages should be viewable and portrait and landscape.
<jeanne> ACTION: Jeanne to work with Kathleen and Alan to design a testable solution to survey #13 - Make clickable objects appear clickable. [recorded in http://www.w3.org/2014/05/30-mobile-a11y-minutes.html#action02]
<trackbot> Created ACTION-16 - Work with kathleen and alan to design a testable solution to survey #13 - make clickable objects appear clickable. [on Jeanne F Spellman - due 2014-06-06].
Alan: ST - added clarification. Functionality often changes when the screen is rotated.
<jeanne> trackbot, close action-15
<trackbot> Closed action-15.
kathleen: responsive design on phone with menus that change -- functionality is there it is just presented differently.
kp: do we need more for mobile?
alan: something added without loss of functionality
<Zakim> jeanne, you wanted to say that this is important for people with fixed devices, like tablets on wheelchairs.
kp: so we should make this an advisory?
jeanne: important for people with fixed orientation such as when device is in wheelchair.
jan: perhaps it has to do something intelligent in other modes.
kathleen: game is non playable in certain modes such as Words between friends.
jeanne: API is being worked on to assist developers with this issue.
kp: what category?
Jeanne: should be ST.
Kathleen: agree ST
ja: disagree - shouldn't be ST, advisory only
kathleen: says fixed device. Generally locked devices are always in landscape mode.
kp: have to pick.
ja: am concerned about hard requirement that may affect design of games, etc. and may get push back from people -- would like to see research on this.
jan: Is there a success criteria
for this?
... would support option user interface has to operate in both
orientation to the extent that the user can escape from the
orientation and that it doesn't have to fully operate in both
orientations.
ja: +1 to jan
jeanne: split into two levels, Jan's recommendation, and the high level one that requires functionality work in both.
<Jan_> JR: +1 to jeanne's idea
<AlanSmith> I will need to drop for an 11 meeting. Please communicate via email any meeting time/dates to discuss #13
kp: out of time. Any other questions?
<Tim> +1
Jeanne: updated survey date so it is still open.
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) Succeeded: s/Jeanne: Not sure if UAAG has an guidelines/Jeanne: UAAG guidelines are specific for highlighting, but I'm not sure if "make it look clickable" can be tested/ No ScribeNick specified. Guessing ScribeNick: jon_avila Inferring Scribes: jon_avila Present: Alan jeanne jon kathleen kim tim wuwei Regrets: Detlev Agenda: http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2014May/0015.html Found Date: 30 May 2014 Guessing minutes URL: http://www.w3.org/2014/05/30-mobile-a11y-minutes.html People with action items: jeanne WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]