W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

27 Jun 2014

See also: IRC log

Attendees

Present
Jeanne, Tim_Boland, kathyw, wuwei, JonA
Regrets
gavin, alan
Chair
KathyW
Scribe
jeanne

Contents


<trackbot> Date: 27 June 2014

<kw> 1. /invite rrsagent

<scribe> scribenick: jeanne

<kathyw> https://www.w3.org/2002/09/wbs/66524/20140512_survey/results#xq21

Number 20 in Survey - support for physical keyboard

KW: We have already talked about this issue and IndieUI

JA: If IndieUI was supported, that would allow this to be met, but if you didn't use a device independent method, you would have to work with these versions.
... there would be other ways to meet it with the platform, like iOS Switch Access

KW: Detlev was it was too hard to write test procedures for it.

JS: Jan said it was a duplicate of #1

Resolution: Duplicate

Different Screen Sizes, #21

JA: It goes beyond WCAG, i think it should be a best practice

KW: I'm not sure what we are solving

JS: It is blocking responsive design, it could increase problems for people with low vision. I could see same navigation across orientation as a best practise for people who are targeting an audience with certain cognitive disabilities.

KW: Where should we place it?

JA: This is from the Funka Nu gap analysis.

KW: 2.1.1 for keyboard

Users can see what page they are on #22

KW: Comments from Jon and Detlev recommend it as sufficient technique under 2.4.8 AAA

JS: Recommend tighting up the wording

RESOLUTION: 22 as a Sufficient technique under SC 2.4.8 AAA and fix the wording when we work on it.

Use Vertical Navigation #23

<jon_avila> *my audio is not working correctly. I am going to try to call in again.

KW: Detlev said "should be more descriptive, I guess what is menat is "Provide vertical navigation mechanisms that work without horizontal scolling on narrow width screens )whih I admit may be too wordy)"

JS: I don't think it should be ruled out, particularly for people working with fixed orientation portrait mode

KW: I can't see anyone doing this because it would cause such a bad user experience. I don't think we should add something to the guidelines for unique cases.
... I recommend dropping it

JS: +1

<jon_avila> * I'm having trouble getting into the audio system now -- it says the passcode is invalid

<kathyw> I just dropped

<kathyw> calling back in

RESOLUTION: drop #23

<jon_avila> * passcode is 6283# right?

<kathyw> yes

botie, tell Kim we miss you

<botie> jeanne: what?

botie, inform Kim we hope you had a great vacation

<botie> will do

<botie> i already had it that way, jeanne.

Links with the page contents to key pages #24

KW: jon remarked that it was already in 2.4.5
... are there any things that are different for mobile?
... can we say this is already covered under 2.4.5?

RESOLUTION: Sufficient technique already covered under 2.4.5

Provide Open/Closed state in information in menu icon #25

KW: This describes the "hamberger" menu icon to indicate whether or not a menu is open or if there is information available under it.

JA: If it is ambiguous for everyone, it is not really an accessibility issue, except possibly for people with cognitive issues
... visually, what happens when the menu is closed, the icon is the same. If the menu is open, then the icon moves or has some visual indication
... would this be advisory or sufficient?

KW: This would be a case where ArIA haspopup or ARIA expanded as a technique
... it's not necessarily apparent whether this should be apparent on a mobile device

JA: I could support it as a sufficient, but not a failure
... we are talking about whether the user knows it is expanded or collapsed
... aria-expanded can only be used in [list]
... if people used valid markup, @@
... it would be ambiguous to users who can't see

KW: Make a sufficient technique under 4.1.2

TB: I think it should also go under 1.3.1

KW: I think of 1.3.1 as semantic, but I can see it in both places

RESOLUTION: #25 as a sufficient technique under 4.1.2 and 1.3.1
... #26 is a duplicate

Menu can be zoomed to 200%

KW: It's already a technique under 1.4.4
... we can addresss Detlev's comment when we actually work on it.

RESOLUTION: Sufficient technique under 1.4.4

Links and actionalbe elements must be clearly distinguishable

Kw: [reads comments]

RESOLUTION: Change wording of #13 to match #28 and consider them duplicates.

<botie> jeanne: that doesn't look right

Next meeting

No meeting 4 July

Next meeting 11 July, we will start with #29

trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/06/27 14:55:51 $

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)

Succeeded: s/Resolution/RESOLUTION/
Succeeded: s/Resolution/RESOLUTION/
Succeeded: s/Resolution/RESOLUTION/
Succeeded: s/Resolution/RESOLUTION/
Succeeded: s/Resolution/RESOLUTION/
Succeeded: s/Resolution/RESOLUTION/
Succeeded: s/uner 2.4.5/under 2.4.5/
Found ScribeNick: jeanne
Inferring Scribes: jeanne
Default Present: +1.978.760.aaaa, kathyw, Jeanne, [IPcaller], wuwei, Tim_Boland, [GVoice]
Present: Jeanne Tim_Boland kathyw wuwei JonA
Regrets: gavin alan
Found Date: 27 Jun 2014
Guessing minutes URL: http://www.w3.org/2014/06/27-mobile-a11y-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]