- From: Jeanne Spellman <jeanne@w3.org>
- Date: Thu, 21 May 2015 12:51:31 -0400
- To: MATF <public-mobile-a11y-tf@w3.org>
Minutes:
http://www.w3.org/2015/05/21-mobile-a11y-minutes.html
Text of minutes (for archiving)
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Mobile Accessibility Task Force Teleconference
21 May 2015
See also: [2]IRC log
[2] http://www.w3.org/2015/05/21-mobile-a11y-irc
Attendees
Present
Jeanne, Jan, Kathy, Kim, Jon
Regrets
Alan, David_McDonald, Henny_Swan, Mike_Shebanek
Chair
Kathleen_Wahlbin
Scribe
jeanne
Contents
* [3]Topics
1. [4]Technique assignments
2. [5]Understandable Technique
3. [6]Best Practices - understandable
* [7]Summary of Action Items
__________________________________________________________
<trackbot> Date: 21 May 2015
<scribe> scribe: jeanne
[discussion of WebEx issues and WebEx Captcha
Technique assignments
Kathy: We are setting up a chart with the proposed techniques
on them
... we asked WCAG WG for feedback on the proposed Operable
techniques
... we need to set up concise wording for Perceivable and
Understandable
... they were sent to WCAG with insufficient context and
numbering that was confusing the WCAG WG members
... that has delayed the WCAG response
[8]https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_Feedback
[8] https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_Feedback
Understandable Technique
<Kim>
[9]https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Understandable
_Techniques
[9] https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Understandable_Techniques
Kathy: I want to get the list of Technques that we want to
create related to Understandable in the Mobile Accessibility
Note
... some of these are already tied to existing WCAG items
... we could alter some existing ones
... or we can propose new Techniques for mobile for
Understandable
<Kim> zakim take up item 1
Kathy: Consistent layout - portrait or landscape
Jan: We want to see the same layout for portrait and landscape?
Best Practices - understandable
<Kim> Kathy: consistency
Kathy: You have to have consistency across pages,
<Kim> Jan: so all pages should have similar layout
Jan: All of the pages across your site when displayed in
portrait should have consistency?
<Kim> Kathy: but you don't have to have consistency between a
portrait or landscape mode for example
Jan: So are we waiving the requirement between consistent
groups as long as it is consistent within the group?
Jon: That is consistent with current interpretation because the
user initiates a change from portrait to landscape.
... I think that would best go in an Understanding document
about portrait vs landscape
Kathy: agrees
<Jan> Here's the relevant tech:
[10]http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/G61
[10] http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/G61
Jan: It could be included as a note in the existing Technique
-- including info on changing landscape and portrait.
Positioning Page Elements before the Scroll
Jeanne: I would prefer to drop this because scrolling has
become a direction of modern web design, rather than including
all important elements cluttering the initial load. Unless it
is a huge accessibility issue, I would prefer not to use it.
Jan: I agree, the ubiquitous hamburger control is always above
the fold.
Kim: I don't use voice control on the phone. It is important to
see the important elements above the scroll in desktop
... we aren't there with controlling a mobile phone with
speech, so I don't have a strong opinion
... if the gap between putting words on the screen and voice
control on mobile closes, then it may be an issue. I would
prefer not to lock this down.
Jon: I think it belongs more in Operable.
Jeanne: I see long term problems of increasing clutter in above
the scroll, where designers are trying to de-clutter the
initial load
Kim: It seems more prescriptive
Kathy: SHould we put this under Navigation?
Jon: Would this help us meet a success criteria under Operable?
I don't see it.
Kathy: Maybe we leave it in the Note and not have any Best
PRactices or Techniques.
[11]http://w3c.github.io/Mobile-A11y-TF-Note/#positioning-impor
tant-page-elements-before-the-page-scroll
[11] http://w3c.github.io/Mobile-A11y-TF-Note/#positioning-important-page-elements-before-the-page-scroll
Jeanne: Maybe we should add a sentence to say that excessive
clutter is detrimental to users, so if there are many important
objects, make it clear that there is more information if the
user scrolls down.
Kathy: If you know where something is on the screen, it is easy
to get to it. As soon as you start scrolling, you lose
certainty to where things are, rather than at some random
scroll point.
... there is greater usability and understanding with the
initial loading screen.
Jan: I think we can just say it. I don't think it rises to the
level of Technique or Best Practice.
Kathy: There isn't research to back this. It is just an
observation.
Jan: Clutter doesn't come under WCAG.
Kathy: Maybe it doesn't belong in the Note
Jan: Maybe it goes with navigation and consistency of control
because it is hard to find things when there is a lot of
clutter in the page.
Jeanne: Maybe we should contact the Cognitive Accessibility
Task Force and see if they have identified information that
should be in this section.
Kathy: would someone volunteer to take an action item to
contact Cognitive Accessibility TF?
Jon: I was looking under Predictability, and this could be a
good location for it.
... if we contact CogoTF, we can ask this
<scribe> ACTION: Jon to reach out to Cognitive Accessibility
Task Force and ask for their input on Understandable section of
Note and specifically on positioning important elements above
the scroll. [recorded in
[12]http://www.w3.org/2015/05/21-mobile-a11y-minutes.html#actio
n01]
<trackbot> Created ACTION-31 - Reach out to cognitive
accessibility task force and ask for their input on
understandable section of note and specifically on positioning
important elements above the scroll. [on Jonathan Avila - due
2015-05-28].
Grouping Operable Elements
Kim: It is important that they follow the standard keyboard
shortcutes, but that probably belongs with Keyboard section
Provide clear indication that elements are actionable
Kathy: We have Techniques for this.
Jan: Often there is no need for this. If people use the
standard elements, there is not a problem. If you break it, you
have to fix it.
Kathy: C15, G165 using default focus indicator
... G195
... G149
Jon: There are aimed at visible focus. What we are saying is
that if you are using a touchscreen, you don't know if it is
actionable. So we are taking it a step further.
Jeanne: agrees
Jan: we have to make sure we don't ask people to have to
customize. When iOS changed to the flat format, it caused
problems, but that is iOS' problem to solve, not everyone
elses.
Kathy: Do we have something in UAAG.
Jan: Yes, from the web perspective
Kathy: On mobile, often we have no idea that objects are
actionable. We have a problem of knowing what is actionable,
and how to interact with it.
Jan: If it is a custom object, then you need to provide
affordances
... I don't wnat to see losing the consistency that platforms
provide in order to provide affordances
Kathy: Button shapes are a good example of how you can change
that in the OS and have it change the application.
... do we want a technique for Custom Controls?
<jon_avila> * have to jump off to another call
Jan: I think so. It is parallel with WCAG 4.1.2 - name, role,
value. You can make your own, but it is on you to make it
accessible.
... The affordances are on you.
Kathy: Let's pick this up on the next call. It goes with the
next section as well. Custom controls.
Summary of Action Items
[NEW] ACTION: Jon to reach out to Cognitive Accessibility Task
Force and ask for their input on Understandable section of Note
and specifically on positioning important elements above the
scroll. [recorded in
[13]http://www.w3.org/2015/05/21-mobile-a11y-minutes.html#actio
n01]
[End of minutes]
__________________________________________________________
Received on Thursday, 21 May 2015 16:51:32 UTC