See also: IRC log
<trackbot> Date: 05 February 2015
<Kathy> meeting: Mobile A11Y TF
<Detlev> I can#t get into the call - using Code: 6283 I get a msg this passcode is not valid
<Kathy> that is the right code
<Kathy> 6283 (tel:+1.617.761.6200
<Detlev> yes that 's what I've been dialing and putting in... will try again
<Detlev> it worked now
<scribe> scribe: marcjohlic
<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/
Kathy: Sent an email to the list w/ WCAG WG Comments
KW: Overall feedback was good - looking to publish
<jeanne> https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Feb/0003.html
KW: A few comments around future
releases, but some we should talk about - about how we can
clarify
... Comments on 2.2 Zoom / Magnification - should we call out
that 1.4.4 is about resizing text w/in the browser vs a browser
feature
JA: Didn't really have a discussion on these - just read through the comments - that was just one person's comments
Jan: I think we are primarily focused on text - and that we did do a good job on calling it out. Willing to add a note if that will help.
KW: From the beginning we're talking about text size - everywhere we've talked about text size - so I think we could go back and make a note that says throughout the doc we have "text size" called out - unless someone has another way to make it clearer
AWK: The review was whether this was ready enough to get additional comments - should not read too much into the lack of comments for this initial round/review
Jan: I think we're good
JA: Person was saying they wanted
us to be more clear that the requirement is to have it zoom
everything
... Second comment was around phrasing - we can change that -
provide examples. There are certain words we try to stay away
from such as "ensure"
... If the language that's in there is not clear, open to
changing it
Jan: Also believe that some
people may not have been aware that meta viewport settings
could prevent zooming
... It's possible to block/prevent zooming on mobile - more of
an awareness issue so that folks are aware of it.
KW: I think we're pretty detailed about that - but do you think there is anything we can add to clarify?
Jan: Comment is asking for things you shouldn't do (Failures) but we're providing things you should do - techniques vs failures
KW: Yes, and that's what we've
done throughout the note
... Is the agreement from the group that we'll leave this as it
is - and wait for comments to come back when we publish to see
if we need further clarifification
Group agrees
DF: I think it's fine the way it is
Second comment: I'm not really sure what we are saying here 'Accessibility features geared toward specific populations of people with disabilities fall under the definition of assistive technology adopted by WCAG and thus cannot be relied upon to meet the success criteria. For example, a platform-level zoom feature that magnifies all platform content and has features to specifically support...
scribe: people with low vision is likely considered an assistive technology.'
This phrase makes me wonder how academic the distinction between old school AT and current 'native' AT a la screen reader/magnification etc is..Does this mean that 'real' text for example, or relative values for font sizes must be used for, the text to be resizable? If that is the case then maybe call it out?
KW: I don't think any changes need to be made
JA: We're being consistent to the definition in WCAG - and we say that.
KW: If any change needed to be
made, it would have to be at the WCAG level because we're
takign that definitiion
... Any disagreement?
No disagreement
Third comment: "Where the specific WCAG SCs are being mentioned, should they be highlighted with a nice background colour, border? Some graphic flourish?"
Group tends to agree
JS: Would be grateful if someone could put together some CSS around that - that could then be dropped in
<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/
<jeanne> ACTION: jeanne to copy CSS from Appendix A WCAG Techniques for highlighting the WCAG SC in the main note. [recorded in http://www.w3.org/2015/02/05-mobile-a11y-minutes.html#action01]
<trackbot> Created ACTION-19 - Copy css from appendix a wcag techniques for highlighting the wcag sc in the main note. [on Jeanne F Spellman - due 2015-02-12].
Comment 4: In 4.5 Provide clear indication that elements are actionable - in the line:
"The WCAG 2.0 success criteria do not directly address issue of affordance but are related to:" should we define affordance? Or link to a glossary?
KW: Does anyone know if we have a
definition of "affordance" anywhere?
... Jeanne / Andrew - any way to add it?
AWK: Not to WCAG because the glossary is normative
Jan: Maybe we can just define it as a paragraph in that section
AWK: Would have to be a note - and then for future versions we could look at pulling that in
KW: Jan do you have a definition of "affordance"
<jeanne> Afford, Affordance [HFES] 2001-04-13 Human Factors & HCI, Al Gilman
<jeanne> An affordance is an effective service delivery; one that makes it into user space where the user can actually use it. Or the effect of the service delivery as observed within user space.
<jeanne> http://www.w3.org/WAI/GL/Glossary/printable.html
JS: Found a definition in a WAI
document from 2003
... It's an overall glossary that we could reference
... Is this a definition we would want to use?
<jeanne> http://www.w3.org/WAI/GL/Glossary/printable.html#def-afford
Affordance: An affordance is an effective service delivery; one that makes it into user space where the user can actually use it. Or the effect of the service delivery as observed within user space.
Jan: I agree this isn't a good definition, but it is a useful concept to introduce folks to if they are not familiar with it
<Kathy> http://www.usabilityfirst.com/glossary/affordance/
KW: This definition is more what I think about when I think "affordance"
<jeanne> +1 for a simpler term
Jan: Kind of agree that we should change it to something visual - if we're talking about visual let's just say it
MJ: As i was reading through it, the term "affordance" threw me off.. first time coming across it.
JA: Can we just change affordance to function
DF: I think actionable might be a better term
<Kathy> Providing a clear indication that elements are actionable is relevant for web and native mobile applications that have actionable elements like buttons or links, especially in interaction modes where actionable elements is commonly detected visually (touch and mouse use).
<jeanne> Propose: especially in interaction modes where actionable elements are commonly detected visually (touch and mouse use).
JA: Seems to match the definition of "functionality" in WCAG - so we could change "affordance" to "function"
DF: Function might be ambiguous vs using affordance
<Kathy> The WCAG 2.0 success criteria do not directly address issue of clear indication that elements are actionable but are related to:
<Kathy> The WCAG 2.0 success criteria do not directly address issue of clear visual indication that elements are actionable but are related to:
KW: Any objections or other suggestions?
Jan: Like the text, but the last part "are related to:" is a bit awkward to read
JS: "related to the following Success Criteria"
<jeanne> The WCAG 2.0 success criteria do not directly address issue of clear visual indication that elements are actionable but are related to the following success criteria
Group agrees
Comment 5: In 4.4 the WCAG SC listed is not bold - just need to add that formatting to be consistent
JS: Updated
Comment 6: I would like to see the introduction paragraphs referencing WCAG2ICT and Mobile Web Application Best Practices expanded. More about why theye're mentioned there, relevance to this doc.
<jeanne> While the World Wide Web Consortium (W3C)'s W3C Web Accessibility Initiative (WAI) is primarily concerned with web technologies, guidance for web-based technologies is also often relevant to non-web technologies. The W3C-WAI has published the Note Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT) to provide authoritative guidance on how to
<jeanne> apply WCAG to non-web technologies such as mobile native applications. The current document is a mobile-specific extension of this effort.
Jan: It seems clear enough
AWK: I didn't get the impression that MC viewed it as a deal-breaker. Could be something we add it later if needed (or more comments)
KW: OK leave it for now unless someone has something to add
<jeanne> W3C Mobile Web Initiative Recommendations and Notes pertaining to mobile technologies also include the Mobile Web Best Practices and the Mobile Web Application Best Practices. These offer general guidance to developers on how to create content and applications that work well on mobile devices. The current document is focused on the accessibility of mobile web and applications to people
<jeanne> with disabilities and is not intended to supplant any other W3C work.
Comment 7: I would change "1.1 WCAG 2.0 and Mobile Content/Applications" to "1.1 Mobile Content/Applications" and include just the stuff introducing the mobile space. Then change "1.2 Other W3C-WAI Guidelines Related to Mobile" to "1.2 W3C-WAI Guidelines Related to Mobile", add a sub-heading about WCAG, and move content from the previous section here. Then continue with the ones about ATAG...
scribe: and UAAG. Keep the focus of this document mobile, not on a specific set of guidelines.
Jan: The problem there is that
one of the goals of this document is to state that WCAG is
highly relevant to the development of Mobile content. My goal
was to push the sentence around this as high in the doc as
possible
... So talking more about how special mobile is - or what W3C
says - might go against that goal
JA: Tend to agree w/ Jan because people want to see how this pertains to WCAG. This isn't just mobile best practices - this is how mobile relates to WCAG
KW: Any problem that we are more
focused on WCAG vs UAAG?
... Thoughts on changing the title to remove UAAG
JA: Makes sense - right now title seems to convey more than we're describing
<Jan> Mobile Accessibility: How WCAG 2.0 and Other W3C-WAI Guidelines Apply to Mobile Devices
KW: We do call out the UAAG / ATAG and we call out WCAG2ICT
JS: I don't think there would be a problem w/ Jan's suggested title change
<Jan> Mobile Accessibility: How WCAG 2.0 and Other W3C-WAI Guidelines Apply to Mobile
AWK: Mobile devices vs mobile content vs ?
Jan: Agree - let's drop "devices" and go wtih Moble
Group agrees
<jeanne> +1 to Mobile Accessibility: How WCAG 2.0 and Other W3C-WAI Guidelines Apply to Mobile
KW: We still have a reference - in page link that was not linked - "Touchscreen Gesture INstructions"
JS: Yep updating now
KW: Interested in getting this
published and getting further comments.
... We still have UAAG WG reviewing this. They are meeting
today. We can review their comments on next week's call
... Jeanne when will changes be in? Will you send note to WCAG
WG?
JS: Yes - I think we can send them a link - just working on the CSS change. All other changes should be up in a min.
KW: Great - will send a note to the WCAG WG
<jeanne> https://www.w3.org/2002/09/wbs/36791/20150203/results
JS: We have 2 comments that have
come in from UAAG
... Looks like we've already just fixed the comments (same as
from WCAG)
KW: We can wrap up then
trackbot, end meeting
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/Prepose/Propose/ Found Scribe: marcjohlic Inferring ScribeNick: marcjohlic WARNING: No "Topic:" lines found. Default Present: Kathy_Wahlbin, AWK, Henny, Marc_Johlic, Jan, Jeanne, Detlev, jon_avila Present: Kathy_Wahlbin AWK Henny Marc_Johlic Jan Jeanne Detlev jon_avila Found Date: 05 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/05-mobile-a11y-minutes.html People with action items: jeanne WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]