<trackbot> Date: 12 May 2015

<Joshue> trackbot, start meeting

<trackbot> Meeting: Web Content Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 12 May 2015

<AWK> Chair: AWK

<AWK> Meeting WebEx link: https://mit.webex.com/mit/j.php?MTID=m064eab3e5485b640231a7fe56dc4785c

<AWK> Just a reminder that we are not joining with the regular number but are using WebEx

<David> just finishing an IAAP call

<Joshue> https://www.w3.org/WAI/GL/wiki/Scribe_List

<scribe> scribe: jon_avila

<David> eeek.... forgot.... we're on webcast.... let me scramble

<marcjohlic> (https://mit.webex.com/mit/j.php?MTID=m064eab3e5485b640231a7fe56dc4785c)

<Joshue> <https://mit.webex.com/mit/j.php?MTID=m064eab3e5485b640231a7fe56dc4785c>

<marcjohlic> Meeting number: 642 418 206

awk: will use IRC for chat and sharing links

<David> i'm talking can anybody heaqr me?

<MoeKraft> can't hear you

<MoeKraft> Try WebEx #Join by phone +1-617-324-0000 US Toll Number Access code: 642 418 206

<David> urrrgh... i hear everyone perfect but can't be heard

kw: is it possible to share IRC client?

<David> I can hear you

<David> ok

+1 to the annoying flashing Cisco WebEx taskbar item

*Likely flashing in the not allowed threshold

Survey: https://www.w3.org/2002/09/wbs/35422/20150512Misc/

<Joshue> Chair: AWK

awk: Issue 86 -- UA support seems to be non-existent

Issue 86: UA support for this technique seems to be non-existent

Makoto: People mis understand that each section should have a heading to meet -- it may not be required that each section have a heading. Just pointing this out.

awk: Your right -- it is not necessary, but if you do, you are doing as this technique suggests and as a result you meet SC 2.4.1
... technique says if you have a comprehensive heading structure you will meet the SC as an outcome
... any other thoughts?

adam: experience says that screen reader users like headings. Good technique to have even if it may not meet the success criteria.

awk: proposed response is to keep H69 and updating the user agent support notes.
... Lauara had made comment to add user information about impact on screen reader user in understanding document. May not need that info in this document.

<David> I added a sentence in case you wanted to

awk: not sure I want to use the precendence of this technique as a reason to keep it

<AWK__> Suggest changing 2nd sentence to: As a result, and in consideration that screen reader users use heading navigation as a core strategy, we are electing to keep technique H69, and will update the user agent notes per your suggestion.

<Joshue> JA: My question is, how do we know someone has access?

<Joshue> JA: We are making assumptions about plugins etc. You can only make this argument in a give environment. Correct?

<Joshue> LGR: Sure - a11y support is an issue for every tech.

<Joshue> JS: For other techs they don't require plugins.

<Joshue> LGR: Its no worse that specifying browser/UA combinations.

<Joshue> <existential discussion on where SCs breakdown due to non specified paramenters or constraints for sufficient support>

<AWK__> ADam: I understood that contrast needed to be on the developer side

<David> adam you are breaking up

<David> who's typing?

<Loretta> ?

<MoeKraft> test

<jon_avil> lgr: concerned about response to commenter as a keyboard issue as the response focuses on screen reader users

<cstrobbe> In 2011, I found that only Opera supported heading navigation, and the GreaseMonkey script did not work at that time: http://lists.w3.org/Archives/Public/w3c-wai-ig/2011JulSep/0177.html

<jon_avil> dm: not a keyboard blocker -- issue is not just about keyboard access

<Joshue> https://github.com/w3c/wcag/issues/86#issuecomment-99463886

<jon_avil> lgr: is there a place I can see complete current response?

<jon_avil> lgr: preference is to remove the screen reader suport

<jon_avil> dm: ok to remove that screen reader part

<Joshue> JA: I don't agree as its not sufficient for keyboard only users/

<Joshue> s/users//users

<Joshue> AWK: What is?

<Joshue> JA: Skip link

<Joshue> JOC: Should this be an advisory technique then?

<Joshue> AWK: What about mobile devices?

<laura> Why can’t http://paypal.github.io/skipto/ be used on a moblie device?

<Joshue> <discussion on mobile devices, success criterion etc>

<Joshue> AWK: The issue is still about a11y support.

<jon_avil> awk: Still have accessibility support issue. Similar but different argument if we also talk about mobile devices

<Joshue> JA: I'm not oppossed to removing the tech - or keeping it satisfy the SC - as long as we are clear about some of the dependencies.

<jon_avil> awk: perhaps the solution is updating the user notes

<jon_avil> lc: can you use skip to on mobile

<jon_avil> jn: you can skip to on mobile as bookmarklet

<jon_avil> lc: if they are going to skp nav then why not implement skip to as it is better.

<Joshue> JA: People with low vision may have problems locating pointer etc.

<jon_avil> dm: seen many people use mouse keys in environment

<jon_avil> jn: skip to link can be confusing

<jon_avil> dm: just never seen in real life people who can see that are using the keyboard

<jon_avil> dm: tons of people who use the keyboard but they also use mouse keys in addition

<jon_avil> jn: why are they using mouse keys -- because things aren't accessible or because there is some benefit

<jon_avil> kw: has team member who often uses mouse keys because things aren't keyboard accessible and they have gotten use to that.

<laura> http://simplyaccessible.com/ has an implication that is similar to skipto

<jon_avil> awk: Should the skipTo plugin be part of this response?

<jon_avil> jn: user can add skipto as a bookmarklet and add to any page. -- so it's not on author. Instructions are provided on how to use it as a bookmarklet

<Joshue> -q

<jon_avil> jn: some browsers require many keystrokes to access bookmarklet. This plugin doesn't work well in dynamic pages. Also does not work in iFrames.

<jon_avil> jn: Preparing to update the plugin so it would work in dynamic situations and work with iFrames

<jon_avil> jn: issues will always surround iFrames that are in different security contexts.

<MoeKraft> And don't forget about carpal tunnel syndrome sufferers

<AWK__> proposed response: Thank you for the comment. The Working Group finds that while it is accurate that current versions of Opera no longer support keyboard navigation by heading elements, we have found that the SkipTo plugin (http://paypal.github.io/skipto/) implemented as a bookmarklet and Greasemonkey user script for heading navigation provided by Gez Lemon (http://juicystudio.com/article/heading-navigation-greasemonkey-user-script.php) both provide the abili[CUT]

<AWK__> avigate by headings. As a result, we are electing to keep technique H69, and will update the user agent notes per your suggestion.

<Joshue> +1

<jon_avil> awk: any objections to accepting response as amended?

<MoeKraft> +1

<MoeKraft> keep H69

<MoeKraft> correct

<jon_avil> ACCEPTED as amended: H86

<AWK__> ACTION: David to work with Jon on user agent notes related to Issue 86 [recorded in http://www.w3.org/2015/05/12-wai-wcag-minutes.html#action01]

<trackbot> Created ACTION-309 - Work with jon on user agent notes related to issue 86 [on David MacDonald - due 2015-05-19].

<jon_avil> ACCEPTED as amended: H69 - Issue 86

<Joshue> RESOLUTION: ACCEPTED as amended: H69: Issue 86

<jon_avil> awk: Issue 69 - issue from Makoto about Japanese translation

<AWK__> https://github.com/w3c/wcag/issues/69#issuecomment-87877885

<jon_avil> awk: gregg should review proposal

<jon_avil> mc: Gregg will either accept it or provide feedback on why certain words were chosen and then we can forward that to Makoto

<jon_avil> awk: can we have a conditional accepting as proposed conditional on gregg reviewing and liking it?

<jon_avil> awk: no objections heard. We will send this to Gregg. We will like Makoto know.

<jon_avil> RESOLUTION ACCEPTED as proposed conditional on Gregg reviewing and approving.

WCAG Call for Consensus Proposal

<Joshue> RESOLUTION: ACCEPTED as proposed conditional on Gregg reviewing and approving.

<jon_avil> awk: skip third party content and go to WCAG call for consensus proposal

<David> is there a link

<jon_avil> jo: why is TF mentioned in here?

<jon_avil> awk: Should be modified as that came from copied text.

<jon_avil> jo: WCAG decision page might not always be on wiki -- so I would change that part referring to the wiki

<jon_avil> MC: Not sure if they are major blockings but they are key subtles. Not sure you want to say where discussion should take place. May want to provide guideance without going to strict to rule to foster informal discussion but have guidance on making sure discussion has hit the radar.

<jon_avil> mc: also aware that we don't want people to hold group hostage by saying they didn't read their email that week.

<jon_avil> mc: Want to say the teleconference is encourage to make a resolutions but that is not a resolution under the consensus policy.

<David> +1 on checks and balances for editorial

<jon_avil> mc: Need some level of fail safe if a chair says that something is editorial and others feel that it isn't that it can down a process to vet it

<AWK__> https://www.w3.org/WAI/GL/wiki/Consensus

<jon_avil> awk: in last sentence about chairs following sound judgement -- add escalation path for things such as items people disagree are editorial.

<jon_avil> dm: what about just calling for a vote? Can we just resolve this in the group?

<jon_avil> jo: Categorizing things as editorial things just reduce the overhead.

<jon_avil> mc: Policy and fail safe is important at certain times -- but you don't want to lean on those when a friendly chat would resolve it.

<jon_avil> mc: Policy needs to provide the protection when friendly chats are not working -- but should not require use of the protections when a friendly chat will work.

<jon_avil> awk: policy would say bring to chairs, and then to Michael, and then to Judy or who the accessibility domain lead.

<jon_avil> mc: if in a teleconference if you bring it up it will go to chairs and hopefully it would escalate using the policy. Shouldn't be required to bring it privately but you certainly can.

<jon_avil> awk: Say someone points out something editorial and chair makes change. Then someone in group sees that in github and then raises the issue on email or github. So any language should allow for asynchronous communications.

<David> Issues that are regarded as editorial by the Chairs do not require a Working Group decision in order for the Chairs to address, and thus do not require a Call for Consensus. If there is disagreement, by particpants on whether something is editorial, this can be brought to the attention of the chairs either orivately or in the context of the wider group.

<jon_avil> dm: how could the group see what is changing in the editorial space? is there a place for that?

<jon_avil> awk: changes are part of the github record. There may be a notification in github that may be able to be sent to the list. Would like to avoid having to document removing a comma

<Joshue> Joshue don't like oritatively -'[...] brought to the attention of the chairs either privately or in the context of the wider group'

<jon_avil> mc: options include following the repository. We could create a proxy user that would represent the mailing list and then issues would be sent to the list.

<jon_avil> mc: make a good comment on the commit in git

<AWK__> https://www.w3.org/WAI/GL/wiki/Consensus

<jon_avil> awk: still some mechanics that we need to figure out about changes. We need to figure out the right protections but flexibility in the future.

<jon_avil> awk: Are we good with this now and fix minor things later?

<jon_avil> awk: any objections to accepting the consensus document as edited and putting it into action?

<Mike_Elledge> +1

<MoeKraft> +1

<Joshue> +1

<jon_avil> jn: are you going to send around to the mailing list as a call for consensus?

<jon_avil> mc: While we are not obligated under the policy now we should take extra care on this.

<jon_avil> awk: Any objections to accepting contingent on consensus on the consensus proposal?

<jon_avil> mc: Use participant everywhere as members are W3C members where participants may be representatives

<jon_avil> awk: Put this out to the list

<Mike_Elledge> bye all!

<jon_avil> awk: thanks for joining and assuming it's approved we will send things out via email for approval.

<laura> Bye. Thanks.

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)

WARNING: Bad s/// command: s/users//users
Found Scribe: jon_avila
Inferring ScribeNick: jon_avila
Default Present: David_MacDonald
Present: David_MacDonald Joshue AWK Michael_Cooper Dan_Frank Marc_Johlic Laura_Carlson Mike_Elledge James_Nurthen
Found Date: 12 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/12-wai-wcag-minutes.html
People with action items: david

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.