See also: IRC log
<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
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?
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
Detlev: wording "before the page
scroll" confusing.
... minor quibble, can move on
Alan: typo in C1
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
Detlev: hint text in voiceover – is there a gesture
Kathy: no content now, we can remove and come back later – any objections
Moving to discussion page
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
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]