See also: IRC log
<trackbot> Date: 14 October 2014
<Joshue> https://www.w3.org/2002/09/wbs/35422/14thOct2014/
<AWK> meeting: WCAG Working Group Teleconference
<Joshue> https://www.w3.org/2002/09/wbs/35422/14thOct2014/
<MichaelC> agenda order 1,7,2
<scribe> scribe: Bruce
<MichaelC> scribeNick: bbailey
Couple things from last week before next survey
<Joshue> Mobile TF proposed changes to G78
<Joshue> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G78
<Joshue> https://www.w3.org/2002/09/wbs/35422/20141007Misc/results#xg202edit
Discussed last week, did not close
6. Mobile TF proposed changes to G202
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G202
See new text step in wiki
thanks to jon availl
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G78
Earlier text script was a little wordy
Jon made pithy and added example
KHR asks question about players that don't look like player, but response resolves this
RESOLUTION: Accept G78 as amended
AWK / MC : wiki may be having problems
Bruce sharded problem with WBS home page
MC reports problems only sporatic,
we continue
<Joshue> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G202
<Joshue> Mobile TF proposed changes to G202
https://www.w3.org/2002/09/wbs/35422/20141007Misc/results#xg202edit
Reviewing survey responses
Discuss that some tone in proposed response may be harsh
MC has proposed change to remove combative phrase
AWK suggest linking to definition of keyboard interface
RESOLUTION: Accept G202 as amended
Wiki login issues continues, so Micheal Cooper having to do the labor...
Discussion of keyboard functionality versus keyboard control
Discussion if test script as written is explicit enough wrt keyboard
MC concerned that example is too leading for test proceedure
There are many examples for keyboard interface, not specific to mobile, so no compelling reason to scope to mobile
Emphasizing one example in test procedure may give it too much emphasis
Discuss removing example from test procedure, information is in body of technique
Reviewing text and MC suggested edit
Accept edit to test procedure, removing example
Return to discussion of Note
David concerned with “does not necessarily mean that each of the individual controls can be used from the keyboard”
Note is already in place, was not suggested for change
Loretta recalls that keyboard shortcut might be available for control that is not directly keyboard operable
Requirement is for keyboard functionality, not that each control be keyboard accessible per se
Example of keyboard shortcut for bold, rather than tabbing to a bold button
AWK gives example of mouse-only click for video play, but may be other keyboard means for triggering video
David concurs that being able to do functionality from keyboard is different than each control from keyboard.
David volunteers to bring this back for more discussion, add clarity
<scribe> ACTION: David to file issue on G202 regarding language distinguishing functionality from control and clarify necessity of keyboard accessibilty [recorded in http://www.w3.org/2014/10/14-wai-wcag-minutes.html#action01]
<trackbot> Created ACTION-284 - File issue on g202 regarding language distinguishing functionality from control and clarify necessity of keyboard accessibilty [on David MacDonald - due 2014-10-21].
<Joshue> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G9
Joshue: recaps from last week, don't want to work this too much this week
KHS speaks to keeping phrasing
Discussion is around Exampl 2
Proposed is: Example 2: A user watches an online seminar on their mobile device, including captioning provided through the use of Communication Access Real-time Translation (CART). The captions provided also benefit in-person participants who need captioning and can view the information on their own device.
<Joshue> Example 2: A user watches an online seminar on their mobile device, including captioning provided through the use of Communication Access Real-time Translation (CART). The captions provided also benefit in-person participants who need captioning and can view the information on their own device.
RESOLUTION: Accept Example 2 on G9
Eric talks about WAI-ACT tutorials
Eric has lead for editorial work, really appreciates the feedback so far
<yatil> https://github.com/w3c/wai-tutorials/labels/%E2%9C%97
Two open issues, pretty quick
<yatil> https://github.com/w3c/wai-tutorials/issues/124
Topic is Change color contrast for placeholders?
Is this a browser or should we address in tutorials?
<AWK> Contrast: https://github.com/w3c/wai-tutorials/pull/145/files?diff=split
Other issue (carousel) is probably more straightforward
<yatil> Particular line: https://github.com/w3c/wai-tutorials/pull/145/files?diff=split#diff-c9c21451eb33fff0fb847235af4bebe8L228
KHR: definitely an issue
Joshue: Placeholder text came up on calls before
We don't have current technique specific to placeholder
David thinks instructions below form are pretty well addressed
ARIA-described-by provides sufficient pointer
Issue is more with prompts like mm/dd/yyyy
<Joshue> https://github.com/w3c/wai-tutorials/issues/124
<yatil> http://w3c.github.io/wai-tutorials/forms/instructions/#placeholder-text
David points out problem is more like prompts like mm/dd/yyyy
Joshue asks if Eric might take lead with tutorials
Eric points out that browsers do not honor contrast setting for place holder text
Can or should we make this a browser issue?
<Joshue> https://www.w3.org/WAI/GL/wiki/Using_@placeholder_on_input
One approach is for page authors to specify foreground and background color on placeholder text
Joshue points out that more attention seems to be given from authors on placeholder attributes
AKW comments that he likes proposed text
Example we provide should have good contrast, so do we provide CSS code that does this?
Or do we say this is UA / browser issue?
Joshue thinks we have a fine line to walk on this.
AWK reminds that recent response was that it would be nice if browsers handled this, but for now author has to supply as matter of practice
KHR likes that we provide example, link back to related techniques
Authors are having difficulty with the issue, and end-user with low vision having problems reading placeholder text
Katie thinks this is an important issue, we want browsers to change, but have to provide work-around in meantime
Would be a mistake to pass on the opportunity.
David gives hypothetical example that this might already come down to accessibility supported
If one browser provide sufficient contrast, but that's not the end-users preferred browser, is this still a wcag contrast requirement or not?
Joshue also thinks this ties back to UAAG
When using a UAAG conforming browser, issue may be addressed.
AWK points out that accessibility support is theoretical future problem as all browsers do poorly with placeholder text
<Ryladog> q
<Ryladog> +
Response for now has to be providing examples of good contrast for place holder text
AWK points out for tutorial we should be providing
<David> UAAG #4 Optional Settings: Throughout UAAG 2.0, all required behaviors may be provided as optional preference settings unless a success criterion explicitly says otherwise. For example, if a success criterion requires high contrast between foreground text and its background, the user agent may also provide choices with low contrast. While it is preferred to have a required behavior as a...
KHR need good user agent notes
<David> ...default option, it does not need to be, unless the success criterion explicitly says otherwise.
Joshue thanks Eric for flagging, need to address in techniques. Katie volunteer to help or review
<yatil> https://github.com/w3c/wai-tutorials/issues/163
<AWK> https://github.com/w3c/wai-tutorials/issues/163
<scribe> ACTION: yatil to work with Katie on providing example with CSS providing sufficient contrast for placeholder text [recorded in http://www.w3.org/2014/10/14-wai-wcag-minutes.html#action02]
<trackbot> Error finding 'yatil'. You can review and register nicknames at <http://www.w3.org/WAI/GL/track/users>.
<scribe> ACTION: Ryladog to work with Eric on providing example with CSS providing sufficient contrast for placeholder text [recorded in http://www.w3.org/2014/10/14-wai-wcag-minutes.html#action03]
<trackbot> Error finding 'Ryladog'. You can review and register nicknames at <http://www.w3.org/WAI/GL/track/users>.
<scribe> ACTION: Katieto work with Eric on providing example with CSS providing sufficient contrast for placeholder text [recorded in http://www.w3.org/2014/10/14-wai-wcag-minutes.html#action04]
<trackbot> Error finding 'Katieto'. You can review and register nicknames at <http://www.w3.org/WAI/GL/track/users>.
<scribe> ACTION: Katie to work with Eric on providing example with CSS providing sufficient contrast for placeholder text [recorded in http://www.w3.org/2014/10/14-wai-wcag-minutes.html#action05]
<trackbot> Created ACTION-285 - Work with eric on providing example with css providing sufficient contrast for placeholder text [on Katie Haritos-Shea - due 2014-10-21].
Eric describes problem with using ARIA live regions
Eric asks if technique is okay as is, or do we need to expect additional work-around?
David discusses that behavior is not too unusual for experienced screen reader user, but instruction or prompt really is needed before encountering.
Joshue points out that any way to escape, get around, or ignore carousel for keyboard users should be okay.
Joshue asks if anyone has issue with what Eric has so far.
No objections. David suggest providing some addition links,.
Joshue points out that screen reader behavior can vary quite a lot from platform to platform
David comments that we don't want to imply that way we address carousel makes them a solved problem
Will need to emphasize that this is one solution, not only solution
All thank Eric
<Joshue> https://www.w3.org/WAI/PF/Group/track/issues/542
Joshue and AKW note that we are not resolving this now
<AWK> e.g. <div style="content: url(icon.png), attr(data-fallback);" data-fallback="Bar">Foo</div>
<scribe> ACTION: David to work on technique for issue 542 [recorded in http://www.w3.org/2014/10/14-wai-wcag-minutes.html#action06]
<trackbot> Created ACTION-286 - Work on technique for issue 542 [on David MacDonald - due 2014-10-21].
<Joshue> ISSUE-542: David Mac D to work on it
<trackbot> Notes added to ISSUE-542 .
<Joshue> ACTION-274
<trackbot> ACTION-274 -- Katie Haritos-Shea to Review description for g4 to ensure that keyboard interface support is included. -- due 2014-09-30 -- PENDINGREVIEW
<trackbot> http://www.w3.org/WAI/GL/track/actions/274
<Joshue> https://www.w3.org/WAI/GL/wiki/Using_the_aside_element_to_indicate_tangentially_related_content
Recall status?
A
AWK recalls that David and Jon Avilla working on
Technique was post-pone from recent pub
<scribe> ACTION: David to follow-up on aside technique [recorded in http://www.w3.org/2014/10/14-wai-wcag-minutes.html#action07]
<trackbot> Created ACTION-287 - Follow-up on aside technique [on David MacDonald - due 2014-10-21].
<Joshue> ACTION-287: David MacD to review https://www.w3.org/WAI/GL/wiki/Using_the_aside_element_to_indicate_tangentially_related_content
<trackbot> Notes added to ACTION-287 Follow-up on aside technique.
<Joshue> ACTION-274
<trackbot> ACTION-274 -- Katie Haritos-Shea to Review description for g4 to ensure that keyboard interface support is included. -- due 2014-09-30 -- PENDINGREVIEW
<trackbot> http://www.w3.org/WAI/GL/track/actions/274
<AWK> "We also discussed the proposed changes to G4. The taskforce feels that no change is required and doing so would “muddy the waters”. If the WCAG working group feels that the change is necessary, we would like this revisited to align with the keyboard language coming from the taskforce so that we have consistency and keep the techniques in synch."
<AWK> http://www.w3.org/WAI/GL/track/actions/274
AWK review changes
<Joshue> http://www.w3.org/TR/WCAG20-TECHS/G4.html
Review description for g4 to ensure that keyboard interface support is included.
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G4
We asked mobile task force for feed back
KHR reported that she discussed with Kathy, ties back to earlier issue discussed on this call with regard to keyboard support
Mobile group pushed back from what KHR and Kathy though was okay.
AWK summaries status, we need to decide if we are changing G4
Do we like having additional text?
It is good to remind people that keyboard access is required -- but keyboard access is not specifically a related technique for G4
AKW summarize issue is balance of being verbose versus being complete
AKW points out that other SC are also required even when not specially mentioned
<AWK> Another option: reduce description to "The objective of this technique is to provide a way to pause movement or scrolling of content. If the user needs to pause the movement, to reduce distraction or to have time to read it, they can do so, and then restart it as needed."
Loretta points out that the issue of keyboard access come up a lot, but this technique is not especially particular to the issue
If each technique linked to everything, the techniques would get lost
<Joshue> +1 to Loretta also
Lots and lots of techniques could related to keyboard accessible
AWK observes that loading up each technique with valuable accurate and helpful information makes them hard to read
Might want to focus on main topic, rely on examples that include keyboard access
Joshue concise techniques more valuable than muddying them up with related issues
Discussion seems to be that shorter is better
David opens discussion for how to link to other things to look out for
<AWK> AWK to offer possible changes to G4 per discussion on ACTION-274
If a person comes to a particular technique, how do they get back to big picture that includes keyboard accessilbity?
<AWK> ACTION-274: AWK to offer possible changes to G4 per discussion
<trackbot> Notes added to ACTION-274 Review description for g4 to ensure that keyboard interface support is included..
<AWK> ACTION-274: on AWK
<trackbot> Notes added to ACTION-274 Review description for g4 to ensure that keyboard interface support is included..
<Joshue> zaki, agenda?
<Joshue> https://www.w3.org/2002/09/wbs/35422/14thOct2014/
trackbot, end meeting
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/scribe Bruce_// Succeeded: s/zakim orretta is Loretta// Succeeded: s/ammended/amended/ Succeeded: s/defintion/definition/ Succeeded: s/tutoirals/tutorials/ Succeeded: s/Daivd/David/ Succeeded: s/ee@w3.org// Found Scribe: Bruce Found ScribeNick: bbailey Default Present: +1.617.766.aaaa, AWK, Michael_Cooper, Bruce_Bailey, EricE, David_MacDonald, Katie_Haritos-Shea, Kenny, Joshue, Marc_Johlic, Loretta Present: +1.617.766.aaaa AWK Michael_Cooper Bruce_Bailey EricE David_MacDonald Katie_Haritos-Shea Kenny Joshue Marc_Johlic Loretta WARNING: Replacing previous Regrets list. (Old list: Jon, Avila) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Mike_E, Jon_A, James_N, Kathy_W Regrets: Mike_E Jon_A James_N Kathy_W Agenda: http://lists.w3.org/Archives/Public/w3c-wai-gl/2014OctDec/0050.html Found Date: 14 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/14-wai-wcag-minutes.html People with action items: david katie katieto ryladog yatil WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]