<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