W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

29 Jan 2015

Agenda

See also: IRC log

Attendees

Present
Kim_Patch, Kathy_Wahlbin, Jeanne, Detlev, Alan_Smith, Jan, [IPcaller], +1.703.637.aaaa, jon_avila, AWK
Regrets
Detlev_Fischer, Marc_Johlic
Chair
Kimberly_Patch
Scribe
Kim

Contents


<trackbot> Date: 29 January 2015

<Kathy> Kim - I will be joining shortly

Great

Kathy: focus for this call is walk through the sections of the document that we haven't reviewed together as a group and talk about other general comments about the document as we are getting ready to send this to the WCAG working group. Deadline end of month, so this is our last call before we send it , but that doesn't mean we can't be so making changes, just to get feedback

<jon_avila> I read them last week.

Kathy: we will talk about the different sections, we will pause to give people a chance to review the sections and then we'll talk about it. If you get a chance I don't need to send this to the WCAG working group until Tuesday, so we have the opportunity to edit a few things. If you have time after this call or tomorrow to get some feedback in please go through and added your feedback to...
... the survey so we can aand in those comments and make any necessary comments

Jeanne: I need to change this to a github document this afternoon – after 2:30 today ccomments only in survey, not on wiki

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Note:_WCAG_2.0_and_Mobile#A.2_Zoom.2FMagnification_-_READY_FOR_REVIEW

Mobile Accessibility Note – survey https://www.w3.org/2002/09/wbs/66524/20150126_survey/

A2 Zoom

Detlev walking through comments

Jan: okay with removing two lines from A1, general agreement

Detlev: some browsers like dolphin have pinch zoom to assist with reflow but in my experience most browsers don't. Maybe in the reader, reflect sizes in settings, but not browser. Best thing would be to take out font size settings of the user because often they will be ignored. Also controls commonly don't get up to 200% anyway. That's the issue

John: Safari does follow, if you use Apple fonts Safari will follow that at least with IOS8, but it may be limited, I'm fine with language saying that. As far as controls for pages. We should be more explicit – up to 200% would be one of the options

Jan: visa requirements on content authors. User agents have own requirements under UAAG 2. They should do their job in the author should do theirs

Detlev: really aimed at developers – may be areas where user agents take care of this, but very uneven. It's not commonly available to users

Jan: proposal to support pinch zoom because that's the most widely supported thing?

Detlev: I would put that first and mentioned that there are browsers that support pinch zoom with text reflow

Kathy: we do say that – this is most commonly met by pinch zoom – we have some of that but we could clarify it further.

Jan: made change on wiki

Detlev: better now, but that might not be the best way to put it. The main thing was the thing allowing page controls and system font size should be qualified – it could work but in many cases it won't work, especially for system size settings which are not for many browsers

Jon: we can solve the text size one by putting in at least 200%. The other I'm fine with qualifying – when supported by the user agent

Detlev: will not be supported by many common browsers at least so developers know that it's not well supported

Jan: 1.4.4 paragraphs are dense. My takeaway is developer will say what you want me to do

Kathy: bullets?
... Bullets that listed out the different ways, notes to quantify what we want the developer to do
... where it says to meet this requirement, instead this can be meant using one of the following methods, bullets, below that notes as far as qualifying limitations as far as user support and limitations on the devices

<Kathy> SC 1.4.4 requires text to be resizable without assistive technology up to 200 percent. To meet this requirement content must not prevent text magnification by the user.

<Kathy> SC 1.4.4 requires text to be resizable without assistive technology up to 200 percent. To meet this requirement content must not prevent text magnification by the user. The following methods can be used:

<Kathy> - ensure that the browser pinch zoom is not blocked by the page's viewport meta element so that it can be used to zoom the page to 200%

<Kathy> - support for system fonts that follow platform level user preferences for text size

<Kathy> - providing on-page controls to change the text size

Detlev: should the note be part of the bullet so it's kept together
... one more point that might be best practice– Ensure that custom dialogues and other pop-up windows that are intended for desktop browsers are rendered in a usable form in mobile browsers

Jon: it's an issue, is it an accessibility issue

Jan: weird to call out a specific type of UI pattern

Detlev: skip for now

Kathy: any other comments on section a?
... section B we had done last week, any major objections now?

section B

Detlev: 2.4.3 focus order, section B1

Kathy: level a

Detlev: Touch gestures taken for granted?

Jan: example shake phone, not great way, should also have alternatives

Detlev: keyboard is the only alternative

Jan: can add touch

Detlev: B5 minor rewording

Jan: redundant wording "should position interactive elements where they can be easily reached when the device is held in different positions". Already asking them to consider it.
... remove the second reference

Kathy: we need it if we are saying the last paragraph. Maybe sentence in between to tie the last two paragraphs together. The point of this is to say we should consider where we are placing buttons so it's easy to access, but we shouldn't just be designing for right-hand use, we need to be considering all the different placements

Detlev: second paragraph on top then, basic qualification

<jeanne> +1

C3

Detlev: wording "before the page scroll" confusing.
... minor quibble, can move on

Alan: typo in C1

C4 Grouping operable elements that perform the same action

Detlev: putting link element around several elements would be a good fit, has some problems with screen readers. If there is some technique like that maybe we should reference it.

Andrew checking to see if there is a technique to group elements in HTML 5

<AWK> just this one: http://www.w3.org/TR/WCAG20-TECHS/H97.html :)

Jan: changing to reduces the number of elements

C6

Detlev: hint text in voiceover – is there a gesture

C7

Kathy: no content now, we can remove and come back later – any objections

Moving to discussion page

D1

Kathy: D sections just written, could add information, but just trying to get some information out now

Detlev: important to differentiate between keyboard notes– form etc. – and keyboard settings, option for alternative keyboards. There in here somehow but not clearly marked or separated.

Jan: I separated the last sentence

Kathy: any WCAG references for this?
... instruction because if we have the different keyboards from a usability standpoint it's important that users know what different data they can enter
... should be just refer back to C6 there – providing instructions, but that's just for touchscreen we don't have it for keyboard

Jan: good to tie this document back to WCAG 2, normative

Kathy: comments on D2 or D3?

<Detlev> distinguish between "offering default input by suggesting input entered earlier and stored by the browser" and "information available in a particular context (such as current date, time or location)"?

Andrew: not clear how making the right keyword for numbers or characters come up relates to 3.3.2

Kathy: clear instructions to let users know what type of data needs to be entered

Jan: the format of data – example date your year, month month etc.

Andrew: I totally agree, I just wonder whether this is one of those gap things

Kathy: just a side note, keyboard changing automatically different type of keyboard can be difficult for users to orient, if they are aware of the type of data, but we can address that later

Jan: I took it out

Kathy: any other last comments?
... if you have further comments please put them into the survey. Jeanne is going to be moving this over to Github.
... if there is something critical that you think should be changed before we get it to the working group let us know

<jon_avila> Thanks you, I have to jump off.

Kathy: great job, really happy with what we have. Great start to getting the techniques ready and also just getting a note out there to provide some additional guidance on mobile accessibility. Thank you for all your hard work on this..

Andrew: link any instruction or guidance to facilitate feedback, that would be great. Also what timing we are hoping for.

<Henny> Apologies, my connection dropped.

Kathy: trying to get this published by CSUN

Andrew: good to know steps backing up deadline

Jeanne: get it to WCAG tomorrow morning. One week for comment, one week for working group to fix, another week for WCAG to look at.

Kathy: finalized by the 20th
... this is also being published as a draft – that's important to note

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/01/29 17:11:21 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/get help/github/
No ScribeNick specified.  Guessing ScribeNick: Kim
Inferring Scribes: Kim
Default Present: Kim_Patch, Kathy_Wahlbin, Jeanne, Detlev, Alan_Smith, Jan, [IPcaller], +1.703.637.aaaa, jon_avila, AWK
Present: Kim_Patch Kathy_Wahlbin Jeanne Detlev Alan_Smith Jan [IPcaller] +1.703.637.aaaa jon_avila AWK
Regrets: Detlev_Fischer Marc_Johlic
Agenda: http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Jan/0018.html
Found Date: 29 Jan 2015
Guessing minutes URL: http://www.w3.org/2015/01/29-mobile-a11y-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]