See also: IRC log
<trackbot> Date: 21 May 2015
<scribe> scribe: jeanne
[discussion of WebEx issues and WebEx Captcha
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
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_Feedback
<Kim> 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?
<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: 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 hamberger 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 perscriptive
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.
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 Cognative 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 Cognative Accessibility Task Force and ask for their input on Understandable section of Note and specifically on positioning important elements above the scroll. [recorded in http://www.w3.org/2015/05/21-mobile-a11y-minutes.html#action01]
<trackbot> Created ACTION-31 - Reach out to cognative 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.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/okay// Found Scribe: jeanne Inferring ScribeNick: jeanne Default Present: Jeanne Present: Jeanne Jan Kathy Kim Jon Regrets: Alan David_McDonald Henny_Swan Mike_Shebanek Found Date: 21 May 2015 Guessing minutes URL: http://www.w3.org/2015/05/21-mobile-a11y-minutes.html People with action items: jon[End of scribe.perl diagnostic output]