<Joshue108> trackbot, start meeting

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

<trackbot> Date: 01 December 2015

<Joshue108> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

<AWK> trackbot, draft minutes

<trackbot> Sorry, AWK, I don't understand 'trackbot, draft minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<Mike_Elledge> Hi--what is the password for Webex?

<AWK> +AWK

<Mike_Elledge> I am getting an out of service recording for the bridge, as well. :^(

<Mike_Elledge> Sorry--old calendar notice.

<Srini> +Srini

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

<scribe> scribe: marcjohlic

Quickref Public Review reminder and overview on the issues.

<yatil> https://github.com/w3c/wai-wcag-quickref/wiki/Public-Review-Results

Eric: Public review is coming to an end. Steady flow of comments - mostly minor

EE: One major obstacle around data inconsistencies - but that is being worked on

<AWK> AWK: What date does the review officially end? Today?

EE: If anyone has any comments, please fee free to post them - can still submit them through EOD today and they will count toward Public Review
... Yes, Public review ends today 12/1/2015

<laura> Thanks , Eric.

Discussion on 'Checkbox and Radio button labels and 1.3.1' https://github.com/w3c/wcag/issues/122

AWK: Still some discussion and debate. Given that this was just before US Thanksgiving holiday we held off on CfC. Might be worth talking about on today's call and some hashing out on the list. Take a few mins and let everyone take a look at this issue.
... Basic content of issue is that there is a request that WCAG WG make clear that 1.3.1 SC requires that checkboxes and radio buttons have labels that are clickable via programmatic relationship between checkbox / radio button and visual label
... Not sure if this is how WG has interpreted this in the past, but it is an interesting point
... An example could be a user that has difficulty clicking on a small checkbox, but it's easier to click the associated label.
... Need to differentiate between what is "helpful" vs what is "required" for WCAG 2.0

JF: My concern is that for the past 7 years this SC has been interpreted as "as long as a form has an accessible name .. " if we redefine what this SC means then there are sites our there that conform today via aria-label, aria-labelledby, or title would no longer be conforming

<Jan> +1

<Zakim> Joshue, you wanted to talk about to what degree WCAG should define the user experience

JF: While it would be helpful, don't think we should shoehorn it in as a requirement

<Joshue108> +1

JOC: I agree. To what point should WCAG be defining user experience?
... User experience is really important, but maybe that is something for a next version of WCAG

ME: Two thoughts: we don't want to do anything to confuse matters. I'm not sure that being more explicit about relationships being programmatic determinable would cause any issues

SR: Agree w/ John and others on this. If we were to change WCAG it could cause problems - issues around folks that use custom checkboxes rather than native HTML.

<JF> Programmatically Determined Several success criteria require that content (or certain aspects of content) can be "programmatically determined." This means that the content is delivered in such a way that user agents, including assistive technologies, can extract and present this information to users in different modalities. For more information, see Understanding Programmatically Determined.

JF: WCAG has a definition for programmatic association
... Only talks about "extract and present" - not "interact"

<Joshue108> Good idea John

<yatil> +1

JF: Is this something we should maybe take to the Low Vision or Mobile TF to get something written into an extension?

<Srini> a+

+1

<Zakim> AWK, you wanted to ask what constitutes a "relationship"?

AWK: We will fwd this on to Cognitive, Low Vision, and Mobile TF's to see if they are looking at this as part of extensions

<david> not yet, but we will add it to the discussion in Mobile...

<Joshue108> Good input AWK

JF: I asked Paul if aria-labelledy met his definition of success and he said yes because the association was there because it was pointing to an IDREF.
... Example, in complex tables we can use scope or headers and id to create associations, but we can also use <tr><th><td> and that creates a simple association

<Srini> +1. Thanks John for bringing up low vision etc., groups into picture. In fact, if it's clickable and shows up symbol like link, it would become a problem

AWK: Important to call out that they are implied as well as explicit

<Zakim> Joshue, you wanted to talk about the nexus between this issue and SC 4.1.2

SR: Some problems as well around tab and focus

<JF> +1 to Josh 'seeing space'

<Wayne> wayne present+

JOC: Wonder if there is a nexus there with SC 4.1.2 and this issue - seeing a space with new interaction models and components and potentially we will need new requirements

<AWK> +Wayne

s/JF: Wonder/JOC: Wonder/

Wayne: Like aria-labelledby and aria-lable, but when you mix in different browsers, systems, and screen readers etc you don't always get reliable consistent results.
... This this issue of forms and communicating labels all we need to do is establish programmatic relations and I think our techniques do that well.

AWK: There are definite areas where there is some wiggle room built into WCAG. One case that comes up more than others is programmatic determined link text - and it ostensibly talks to what browsers and AT could support, but more often is about what is a "reasonable" area around a link that a user could find.
... Different that proper aria markup and how it responds in different env - but for users ends up being the same.

<Mike_Elledge> ROAR!

DM: Opens the conversation wider, think we could provide some wiggle room in WCAG - as technology improves, do we have wiggle room in our interpretation of WCAG?
... Pet peeve is on current interpretation of programmatically determined link text - wonder what others think?

<Mike_Elledge> +1

DM: Seems that with aria-label and labelledby we could make that more defined

JF: Have to be careful with wiggle room - we provide conformance statements to clients and we have to be careful that clients don't end up exposed to litigation. WCAG is locked down - we can't redefine it now 7 years later. I get that's a lousy position - would like to do things for the end user - but need to be careful that we don't cause legal issues.

<MichaelC> +1, that´s a critical principle for WCAG WG interpretation

JN: Agree because we have conformance statements that say this is OK now, so what happens if we pull that out from under folks now.

AWK: I brought up that term of wiggle room - but I have the same thought as John and James - was speaking more about the ambiguity and interpretation that happens - but not my intention to introduce MORE wiggle room.

DM: I agree, but I think we can mitigate some of this by updating some of our examples or adding new ones

JF: Two thoughts - agree w/ David that offering more guidance would be helpful - showing the best of available options
... The ability to click on a label to select a checkbox - is that something that is helpful to the Low Vis community - and is that should be explored in the Low Vis TF?

Wayne: I would say Yes, from a Low Vis standpoint it is helpful, saves time, and helps avoid lots of errors

JF: So do we ask that this is something specific that we ask Low Vis to address?

Wayne: Also is helpful to motor skills community as well - so not just low vis

JF: I agree, but we don't have a motor skills based TF today, but if we can find a way to get this in to the Low Vis TF to tackle this, it will benefit the larger community.

<Srini> While it's helpful, to users with low vision, still check boxes needs to be visible.

Laura: I think that's a great idea John. I think we should tackle this in the Low Vis TF

<Srini> else we need to have differentiation between text and check box label

<AWK> James, the question for the TFs is to review this issue and determine if a new SC is needed, and if so what it might be.

<JF> +1 Josh

<Srini> AWK, your work will start at LV task force:-)

JOC: While it's good that we have for example one use case for this - I agree with Wayne that this helps many other users groups (motor skills etc) and I think also the more we can back up use cases in one domain with groups in another the stronger it would make our extensions.

Srini: Maybe we can start in Low Vis and expand from there

<Zakim> jamesn, you wanted to ask what is the success criteria we are talking about?

<Joshue108> +1 to James.

<david> I think it helps all three user groups.

<Joshue108> It does

JN: I'd like to propose that Mobile is the place to start this. Sounds like it's not necessarily that we need a label associated - that's helpful - but it's really more about having an accessible target size,

<david> cognitive, mobile and low vision....

<JF> +1 to AWK's idea of shopping this to all 3 of the TFs

AWK: We could send this to all of the TF's - is this a fit? not a fit? do you have SC planned around this? This might address whether this is more mobile than low vis etc

JN: I think it might be all - and hopefully there will be info that comes out that could be used in multiple extension specs

JF: I don't think we could have it repeated 3x's though - in multiple extension specs.

<Joshue108> Correct JF, but there is a co-ordination effort that will be going on.

<AWK> We don't need to get into where a putative SC might live at this time

JF: We could say something like "this applies here - and is covered in this other extension"

AWK: At this point we don't know if we'll have 3 extensions - or one that pulls in from all groups. We can wait to see how that pans out and then see where this lives.

<AWK> https://github.com/w3c/wcag/issues/122#issuecomment-161004582

AWK: Detlev proposed a formulation for the response

<AWK> https://github.com/w3c/wcag/issues/122#issuecomment-158676010

AWK: Think I agree with Detlev's response - had some additional to add to it
... Sounds like people agree that WCAG 2.0's success criteria 1.3.1 does not require that the relationship between the label text and the checkbox or radio button be determined only using the explicit mechanisms where the label element contains the input element or where the label and the input are associated using the 'for' and 'id' attributes.

JF: Comes back to the definition of "programmatically determined" does not include 'interaction'

JN: Uncomfortable with the bit in parenthesis in Detlev's response.

AWK: What if it just said "see 3.3.2 for info about visible labels and checkboxes"

JN: Think that's better

JF: Asked Paul if an aria-labelledby would meet his def because it pointed to an ID - he said yes. But I'm not sure I agree because an aria-label works just as well. We have to be very specific that "programmatically determinable' is not A pointing to B. There are other ways to do it.

<Joshue108> ack

<jamesn> +1 to JF

JF: If we don't get that definition cleared up - there will be continued confusion as to what that means.

JOC: Maybe we need 2 categories for programmatic determined: explicit vs implicit

JF: My concern is backwards compatibility and as James mentioned the thousands and thousands of conformance statements that are already out there
... Programmatically determined is already defined for WCAG 2, so maybe we need a new term and definition

JOC: Not sure if I agree. I think going forward maybe working this out and fleshing out what these mean and how programmatic determined can evolve in WCAG

JF: Would have a problem in redefining existing definition.. risk with current conformance statements.

<Joshue108> right

<Joshue108> +1 to Wayne

<Joshue108> exactly

Wayne: I think what Josh is talkign about is concepts that would be ways to meet programmatic determinism. We can say "yes you will succeed if you do one of these things"

AWK: Think we're in general agreement. Will have to write up a new response and circulate that around for questions / comments and drive toward a CfC.

Walkthru and status update of current issues

<AWK> https://github.com/w3c/wcag/issues/

Current list of issues

AWK: 26 that are currently open now

121 failure for not identify required fields and input format before submit https://github.com/w3c/wcag/issues/121

JN: Have a few more concerns about it - need to have a carve out in it for the form not know what is required and knowing formats until it is submitted
... Info may only be available on the server - not the client
... Will add the comment in for the issue

AWK: #114 surveyed and accepted - needs a CfC
... 112 was surveyed and left open Incorrect ARIA Landmark Example (role=search) https://github.com/w3c/wcag/issues/113
... MC suggested running past PF

MC: Correct working group now would be ARIA (no longer PF)

<scribe> ACTION: MichaelC to send a quick pointer to ARIA to take a look at this https://github.com/w3c/wcag/issues/113 [recorded in http://www.w3.org/2015/12/01-wai-wcag-minutes.html#action01]

<trackbot> Created ACTION-316 - Send a quick pointer to aria to take a look at this https://github.com/w3c/wcag/issues/113 [on Michael Cooper - due 2015-12-08].

AWK: 109 https://github.com/w3c/wcag/issues/109 need to send this one back to Sailesh for update

<MichaelC> action-316: https://lists.w3.org/Archives/Public/public-aria/2015Dec/0002.html

<trackbot> Notes added to action-316 Send a quick pointer to aria to take a look at this https://github.com/w3c/wcag/issues/113.

AWK: 108 https://github.com/w3c/wcag/issues/108 Josh take a look at 109 and 108 and see what needs to be done
... 106 https://github.com/w3c/wcag/issues/106 Louis to weigh in on this one

Wayne: Could use some help on 103 https://github.com/w3c/wcag/issues/103

AWK: Anyone willing to jump in as a second reviewer before sending to Survey?

JN: Some of these may need to be removed - for example landmarks could possibly be trimmed out

Wayne: Will go back and look at this in the context of 1.1
... wouldn't be ready for a couple of weeks

AWK: 102 if auto-redirect despite WCAG but UA blocks, tell user where to go https://github.com/w3c/wcag/issues/102

ME: A call was proposed for 9/15 - but did not make that call. Believe we all felt this was a general usability issue - not necessarily an a11y problem
... If others agree - can we just close this out?

AWK: Mike - can you look through the comments and then raise via the WG list? See what discussion ensues and then do a CfC on it

ME: Sure

Action Mike_Elledge send note to list on 102 https://github.com/w3c/wcag/issues/102 for comments and see if this can just be closed

<trackbot> Error finding 'Mike_Elledge'. You can review and register nicknames at <http://www.w3.org/WAI/GL/track/users>.

AWK: I'll take 101
... 100 - relates to other H65 issue - so I'll take this one also

DM: Issue 99 https://github.com/w3c/wcag/issues/99 tackling this along w/ the other issue on PDF footnotes

<yatil> ACTION: Mike_Elledge send note to list on 102 https://github.com/w3c/wcag/issues/102 for comments and see if this can just be closed [recorded in http://www.w3.org/2015/12/01-wai-wcag-minutes.html#action02]

<trackbot> Created ACTION-317 - Send note to list on 102 https://github.com/w3c/wcag/issues/102 for comments and see if this can just be closed [on Michael Elledge - due 2015-12-08].

AWK: Issue 98 [LowVis] Can text shadowing be used to meet minimum contrast requirements? https://github.com/w3c/wcag/issues/98

Wayne: Suggest sending this off to the Low Vis TF - we can get use cases written up
... Will do this for all of these Low Vis ones

AWK: Issue 95 [Low Vis] Failure of Success Criterion 1.4.3 and 1.4.6 due to using background color that do not provide sufficient contrast with foreground text color https://github.com/w3c/wcag/issues/95
... Looks to be ready for survey

<Mike_Elledge> bye all

<laura> bye

trackbot, end meeting

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/}Srini//
Succeeded: s/?me who me?//
Succeeded: s/because the association was there./because the association was there because it was pointing to an IDREF./
Succeeded: s/For complex tables it would seem to be the same using aria-labelledby or aria-label on td tr/Example, in complex tables we can use scope or headers and id to create associations, but we can also use <tr><th><td> and that creates a simple association/
FAILED: s/JF: Wonder/JOC: Wonder/
Succeeded: s/JF:  Wonder if there is a nexus there with SC 4.1.2 and this issue - seeing a space with new interaction models and components and potentially we will need new requirements/JOC:  Wonder if there is a nexus there with SC 4.1.2 and this issue - seeing a space with new interaction models and components and potentially we will need new requirements/
Succeeded: s/msg AWK I think my work here is done :)//
Found Scribe: marcjohlic
Inferring ScribeNick: marcjohlic
Default Present: AWK, Srini, JF, Laura, EricE, Jan, Joshue108, Kenny, marcjohlic, DavidMacDonald, MichaelC, Wayne

WARNING: Replacing previous Present list. (Old list: Joshue108, MichaelC, kenny, EricE, Sarah_Swierenga, marcjohlic, Katie, Haritos-Shea)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ 

Present: JF Laura EricE Jan Joshue108 Kenny marcjohlic DavidMacDonald MichaelC
Regrets: Kathy Sarah Katie
Found Date: 01 Dec 2015
Guessing minutes URL: http://www.w3.org/2015/12/01-wai-wcag-minutes.html
People with action items: michaelc

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