<Joshue108> 1. The COGA TF would appreciate the working groups feedback on two proposals for pulling together all the information from the COGA into a readable/digestible summary for the purposes of gap analysis. [1]

<Joshue108> [1] https://www.w3.org/2002/09/wbs/35422/COGA_Proposal_review/

<AWK> +AWK

<AWK> +Joshue

<AWK> +Wayne

<MichaelC> Why is it that WebEx is extra unresponsive just when you´re running late?

wayne+

<scribe> scribenick: wayne

<scribe> Scribenick: wayne

AOB from last week

<david> just got connected...

meetings and timelines

Josh: No Meeting for the next 3 week, Next meeting Jan 5

AWK: To follow w3c publications schedule: First we publish extension requirements document draft then Techniques and understanding docs with final changes.
... Our plan is so we can have a survey out in three weeks. This is so all is back from CSUN.

<adam_solomon> the password wcag for webex doesnt work for me - is it correct?

<Joshue108> https://www.w3.org/2002/09/wbs/35422/COGA_Proposal_review/

<david> me

Josh: The COGA group asked for review of documents. The summary format is most popular.

<Mike_Elledge> budgies!

<Rakesh> rakesh

<Jan> JR: BUT I wonder if the table headings could be improved. I suggest:

<Jan> - split up "HTML" and "Content". HTML should cover programmatic practices (e.g. use of <label>) while "Content" would be more about page organization.

<Jan> - I think information for "User Agent (and UA extensions)" fall into "Operating System/Other" so maybe call that out (e.g. "User Agents, UA extensions, OS, etc.") or if you don't agree perhaps make a new column for user agent information.

<Jan> - Would a column on "Authoring Tool advice" be a useful addition? How could authoring tools help to manage and automate these new considerations?

Jan: Table had the advantage of studying a particular colum.

<david> ihear josh perfectly and very clear

<Jan> Scribe: Jan

AWK: Likes separate table...
... Helps to be able to break things up into chunks...just a personal preference
... Agree with Jan

JO: Sitting on fence...
... Big table is definitely out
... They have a huge amount of content

AWK: Does anyone have a really strong opinion...
... Or is everyone on the fence

WD: I think there needs to be a summary that could also have a table

JO: Augmented table sounds good

<Joshue108> https://github.com/w3c/wcag/issues/124

WCAG Github issues

AWK: LW proposed SVG SC for 1.4.5 (text in images)

JO: Sounds good to me

+1

JO: Any objections?

<marcjohlic> +1 to having Leonie write up the SVG technique!

<JF> +1

<Wayne> +1

<laura> +1

JO: All agree

<Joshue108> https://github.com/w3c/wcag/issues/121

JO, AWK: Quick discussion of item 122

New WCAG Failure technique (121)

JO: Sounds like a good idea

AWK: Anyone would like to take this on?

MJ: I'll take it

AWK: Assigned to Mark

WCAG Issue 114

AWK: Done

https://github.com/w3c/wcag/issues/114

WCAG Issue 113

AWK: We're waiting to hear from ARIA group?
... There is some disagreement...some people say adding search semantic overrides native sematics...otrhers say it tightens them

https://github.com/w3c/wcag/issues/113

JO: Rich has responded that there is nothing inherently wrong with applying Search to form

DM: Why is it necessary?

<Joshue108> http://www.w3.org/TR/WCAG20-TECHS/ARIA11.html#ARIA11-ex4

JR: What about what Leone suggests?

JO: OK

AWK: OK but is the other way bad?
... Should the validator throw an error?

DM: I think we have it covered?
... In ARIA 1.1
... Are they introducing a new search role?

JO: What's the issue here?
... I think we just eave this open unless we get new info?

DM: MC?
... In ARIA are they introducing a new search role?

MC: There's a role of search that goes on the form element
... I'll take a look
... What do you mean?

DM: I saw in a blog post by SSB
... By Bryan.

MC: Search role goes on the form, search-box goes on the control
... So the search is the landmark, the searchbox is just the control

JR: Isn't MC answering this...."search role goes on form element"

MC: search role goes on form element

AWK: We say it can go on form element or a parent element

MC: It can be on the parent but only if parent has nothing non-search related in it

<MichaelC> <div id=¨search¨ role=¨search¨><form action=¨search¨><input type=¨search¨/></form></div>

<MichaelC> <form action=¨search¨ id=¨search¨ role=¨search¨><input type=¨search¨/></form>

<MichaelC> both are ok

<david> yes

JO: So user need is as a navigation landmark?

<david> it shows up in the landmarks

<david> that's right

<david> that works

<david> got it

MC: AT user can bring up a list of landmarks, etc

JO: James?

AWK: Is it ok to use role=search on form

James: Yes it should be ok, but our spec should clarify that

MC: Yes, ARIA spec should clarify.

James: Right, you're overriding something that doesn't really have any semantics

MC: OK, then its an ARIA issue. WCAG has to wait for them

AWK: Maybe we should propose a response...this is allowed by the spec...unless we feel strongly that it overrides native semantics, then we let this one be...we should flag this for validator people to no longer flag this as warning

<jamesn> http://www.w3.org/TR/html-aria/

MC: So leaving this agrees with ARIA, but disagrees with HTML

James: In ARIA in HTML, it says only allows global aria attributes on form elements...so roles not allowed.

AWK: We could also say that Leonie provides a valid way of doing this...

James: Anyone have a link to the ARIA thread

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

AWK: Discussion in 113 thread

MC: I should point out that ARIA in HTML is not a spec-track doc
... And doesn't seem to rule it out

DM: It's not that you can't override...but use native semantics when possible

MC: For element doesn't have a native semantic...invisible to accessibility API

FORM element

MC: So not overriding, it's just extending
... Of course we wouldn't want to block it working as a form

<jamesn> This is from the ARIA in HTML document

<jamesn> "Documents must not use any role values with elements in the Document conformance requirements for use of ARIA attributes in HTML table, other than the corresponding role value (if any) as listed for that element in the third column, other than those indicated in the second column, which should not be used."

AWK: I think the intermediate position until we have clear advice...is to use Leonie's xample instead of current example

MC: From what I've now seen, our example seems ok
... ARIA needs a note on this

James: Steve's document has this....

<jamesn> http://www.w3.org/TR/html-aria/

MC: OK this is different....it's normative rec track

James: In a table in chapter 3...

<david> contact Steve F..

James: Does not seem to allow this role

MC: OK so, this does need to be taking up with them as the ARIA group
... I would recommend WCAG take the path of least resistance and leave example alone

WD: This is what drives developers crazy
... If they use our code and get a warning

MC: Validator is at fault, because it follows a spec that's at fault, but WCAG advice appears to be correct

<jamesn> Logged https://github.com/w3c/html-aria/issues/18

DM: Maybe tweet Steve on this

James: Better to log bug and then tweet that

MC: Best not to try to use twitter to track bugs

JO: OK, should we have Leonie's advice added

<AWK> proposed response: The best judgement of the Working Group is that the validator is at fault in this situation. Currently, the WG does not believe that this example is overriding native semantics and provides useful functionality at present, but if normative information demonstrates that this is incorrect we will modify the example.

<AWK> Scribe: Laura

AWK: Think it is technologies. Don’t think we need role on it.
... We don’t really know. So we should leave it alone.

JOC: Okay

<Wayne> +1

<Joshue108> +1 to AWK

+1

<Mike_Elledge> +1

https://github.com/w3c/wcag/issues/106

AWK: Not sure what 106 is asking.

Wayne: Is this related to CMS’s?

JOC: not sure

AWK: need to follow up with requestor.

<david> #99 I still need to add an example...

https://github.com/w3c/wcag/issues/95

Wayne: Will put in low vision use cases.

https://github.com/w3c/wcag/issues/92

David: Is working on it.

https://github.com/w3c/wcag/issues/91

AWK: We were thinking of moving to another location.

David: Perhaps remove the links and leave them as text.

AWK: Maybe move them to a best practice page.

Michael: Made a Wiki page on it.
... Found a lot of duplicates, some we should write up, some should go on a best practice doc.

Wayne: we have a soultion for 95 and could go on the survey.

AWK: take a look at it again.

https://github.com/w3c/wcag/issues/87

AWK: Ongoing need for this.
... Will get back to it. Help welcome.

https://github.com/w3c/wcag/issues/78

AWK: Turn over to low vision task force.
... 70 and 71 Josh will look at.
... We did CFC on 122.
... question on what contitutes a form label.
... can we meet 412 without on of the recomended methods.

JOC: yes.

Wayne: We should be very careful so AT can find it.

AWK: Get rid of the failure technique?

James: Not sure.

<AWK> http://www.w3.org/TR/WCAG20-TECHS/F68.html

James: potentially Place holder could be used.

<jamesn> http://www.w3.org/TR/html-aapi/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

<JF> +1 to James' point

James: map directly to: http://www.w3.org/TR/html-aapi/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

<david> placeholder does not persist after focus visually

Joc: concerned that we break other stuff.

<AWK> Placeholder could fail 3.3.2 if the field is filled in

Wayne: placeholder should be a contrast failure.
... should be called out.

James: doesn’t fail 412

Joc: don’t want to be percriptive.

AWK: AT support is the lacking in implicit methods. Devs will have to do more testing.

<AWK> We aren't going to come to a conclusion, but thanks to all for thinking about it

JOC: May have to loosen some things to allow progress.

AWK: Think about it and we will figure out what we want to do.

<Kurt> +Kurt

<Mike_Elledge> +Mike Elledge

<Wayne> +waume

<Mike_Elledge> Have a great holiday, all!

<Wayne> +sayne

JOC & AWK: Thanks to all have a great .

<Wayne> +wayne

JOC & AWK: Thanks to all have a great break.

<AWK> 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/First we publish erata then Techniques with final changes/First we publish extension requirements document draft then Techniques and understanding docs with final changes/
Succeeded: s/MC/JO/
Found ScribeNick: wayne
Found ScribeNick: wayne
Found Scribe: Jan
Inferring ScribeNick: Jan
Found Scribe: Laura
Inferring ScribeNick: laura
Scribes: Jan, Laura
ScribeNicks: wayne, Jan, laura
Default Present: AWK, Srini, JF, Laura, EricE, Jan, Joshue108, Kenny, marcjohlic, DavidMacDonald, MichaelC, Wayne, JamesNurthen, Kurt, waume, sayne
Present: AWK Srini JF Laura EricE Jan Joshue108 Kenny marcjohlic DavidMacDonald MichaelC Wayne JamesNurthen Kurt waume sayne
Found Date: 15 Dec 2015
Guessing minutes URL: http://www.w3.org/2015/12/15-wai-wcag-minutes.html
People with action items: 

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