<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

https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_Feedback

Understandable Technique

<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?

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: 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