Web Content Accessibility Guidelines Working Group Teleconference

10 Nov 2015

See also: IRC log


EricE, Laura, Kenny, Joshue, marcjohlic, Kathy, David, Joshue108, jon_avila, Sarah_Swierenga
David MacDonald, jon_avila


<trackbot> Date: 10 November 2015

<Kenny> clear agenda

<Kenny> Holiday Schedule and Survey https://www.w3.org/2002/09/wbs/35422/WhenWCAG/

<Joshue108> trackbot, start meeting

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

<trackbot> Date: 10 November 2015

<AWK> Chair: Joshue

<David> sorry still trying to get my mike working

<David> can hear you fine

<David> scribe: David MacDonald

<David> scribe: David MacDonald

QuickRef update from Eric

<jon_avila> I can scribe

<David> jjjjj

<jon_avila> scribe: jon_avila


<David> testing

jo: QuickRef update was sent to the group. Important reboot of guides.

<AWK> QuickRef survey results: https://www.w3.org/2002/09/wbs/1/2015-10-quickref/results

eric: thank you to everyone who has filled out the survey. Got a few new comments. 1 objections from David. Have addressed that. Please go back in look David.

<David> withdraw my objection

eric: most approvals for public reviews. Few more hours left on survey. Some smaller things coming up about the scrolling behavior that we want to address before going into public review
... thank you for your valuable feedback. Lot of good stuff in there.

jo: Looks like we will be able to go into public review?

eric: Yes, appears so.

jo: any questions for Eric while he is here?

<Wayne> wayne+

jo: hearing none, thank you Eric. Looking forward to the review interaction. Any objections for this going out to public?

david: may want to change status section of the document.

Eric: Yes, we will change that and provide a link for survey from the public to get feedback.

jo: any objections?
... hearing none

<MichaelC_> +MichaelC

awk: need to send something out to the working group as a whole before we have a resolution.

Michael: we don't need to trip over wording on all resolutions despite consensus policy.

RESOLUTION: QuickRef prototype to go for public review

Holiday Schedule and Survey https://www.w3.org/2002/09/wbs/35422/WhenWCAG/

jo: looks like 17 nov and 24 of nov are good and so forth. 22nd and 29th of December are not looking good. So we will not have calls then but we will be back in the saddle on the 5th of January 2016.

<David> +1

jo: anyone have anything to add?

<Wayne> +1

<laura> +1

Extension Requirements

Face To Face meeting and survey https://www.w3.org/2002/09/wbs/35422/WCAGF2F/

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

jo: the first question in the survey was on co-locating
... 8 at CSUN 5 at TPAC in Lisbon
... Also the w4a event in Montreal

<laura> http://www2016.wwwconference.org/

MiichaelC: W4A always happens at same place www conference

<David> +1 on Montreal or Lisbon

jo: should we have our own distinct even or co-locate?
... Most people have no preference on that question.
... next preference is to have it with another event. North America east coast is first preference and then west coast North America and then Europe.
... having a F2F in either TPAC or CSUN or both is likely option.

<David> I can't do CSUN this year...

awk: would be good to send the survey out the tasks forces also.
... if we had a two day long F2F we could have time for TF participants work together and join in with working group as a whole.

<Kathy> +1

awk: by the time we are doing this we will have some things to work out as whole. If people think this is a good idea we should send this out to the chairs.

kathy: sounds like great idea. F2F would be focusing on extension model and having the TFs together and look at work as a group would be great.

jo: awk to send out the LV TF.

kathy: is this open to all or restricted?

awk: should be open to 2018

kathy: will send out to mobile TF

<Zakim> MichaelC, you wanted to +1 TF and mention coga

Michael: requires you be a member of the WCAG working group to fill it out. Not all TF members are working group members.

awk: just checked the box to allow others to be able to fill out the survey.

<Zakim> MichaelC_, you wanted to recommend TPAC

MichaelC: COGA has been talking about the F2F. TPAC is a good idea because we have not done it recently. We should really consider it.

jo: agree it would increase task force participation

awk: to ping Lisa on COGA TF and survey

jo: any other comments/questions?

Extension Requirements

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

jo: we've had some pretty active threads on the frameworks for extensions. Andrew has some rolled some questions to the extensions document.

<Joshue108> https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_Extensions_Framework&diff=5872&oldid=5867

jo: diff version provided so we can see what changes were made.
... first item, an existing SC may change by going from AAA to AA or AA to A from a lower priority to a higher

michaelC: need careful thought on how much we would take advantage of this requirement

jo: agree we need to think about it.

kathy: maybe we need note about that anything that is moved up can be achieved across all technologies.

jo: another indicator is testability. We need to maintain that all A and AA are testable.

michaelC: Some things may have become more testable over the years.
... some sort of note saying that extensions need to be cognizant of the impact.

kathy: It may not be clear to all people in TF why something was at AAA and what it needs to go for to be moved.

jo: maybe want to add a section to the framework or some supporting document

michaelC: would add a sentence to hook in the requirements document.
... we already say they meet the pre-existing requirements. Maybe something like pay attention to the existing requirements.

wayne: what about places where SC is missing or need to be updated?

awk: Example might be to change 200% of SC 1.4.4. to 400%

jo: don't intend to weaken any SC

michaelC: extensions are backwards compatible

jo: next change was to say strive to make all extensions compatible with each other.

<MichaelC> Extensions that modify existing success criteria do so with full consideration of the impact on the rest of the guidelines in context of the full set of requirements that apply to the guidelines and extensions. For examples, extensions that lower the conformance level of a success criterion ensure that the success criterion meets the bar of wide implementatbility and testability expected at that level.

jo: original document say "must not conflict". Now it says they should be able to co-exist and allow authors to implement multiple extensions

<AWK> I made a change to the "ensure that web pages which conform..." heading section. Adding a sentence.

awk: this change was done as result of conversation last week as we had very strong language that we said must not conflict and there was concern about that.
... I changed that to indicate that conflicts would ideally not exist but that we recognize that they may happen. The focus was around minimization and striving to make the compatible but not a firm statement to say NO there cannot be any conflicts.

jo: extensions would ideally be harmony allowing authors to meet multiple extensions. We understand there are diverse needs and we want to ensure the extensions can meet those.

wayne: how will developers code to this?

<AWK> Suggestion: Extensions will ideally not conflict with each other, allowing authors to implement multiple extensions.

jo: we are working on framework first

awk: a little concerned about the word harmony you proposed. Feel like something that is short and clear is desirable.

jo: first we have a change. Ok with the change. Don't like the circular "if extensions exist for their own purpose" language.

<laura> +q

laura: how about using the word should? They should not conflict unless there are valid reason and they are understood and weighed

jo: that works as it does not use the word "must".

awk: Agree that is simpler. Made a change extensions should not conflict with either other allowing authors to implement multiple extensions allow author to meet different user needs (see page for actual wording)

jo: moving on to bit about those working on extensions and communications with the working group

awk: about release part - Michael had request that we specifically call out and ask for review of this block of text so people can focus on this

jo: please pipe up if anyone has any comments on questions.
... sticking with model that extensions mirror model in WCAG so people will have to able to have matching claims

awk: If you are meeting extension AA then you will be meeting everything in WCAG AA

wayne: was thinking it might be possible to say WCAG AA but only extension A

awk: that is true. you could have a WCAG AA conformant site but then meet an extension to level A because we have not meet the all of the level AA in the extension.

wayne: that matches how WCAG 2 was intended.

michaelC: I see the reason but I think it will be confusing to have them at different levels. Extensions shoudl have levels but you shoudl use same level.

jo: Can only make extension claims if you are already WCAG compliant.

michaelC: less concerned with that point as if you haven't got to WCAG why would bother with extension. I could see meeting WCAG A and extension A.

<Joshue108> JA: I understand michaels point. It makes sense but in practice matching a level and extension exactly is impractical.

<Joshue108> JA: Extensions are optional.

<Joshue108> JA: A lot of people out there way they support WCAG but they dont claim conformance

<David> http://davidmacd.com/blog/WCAG-extension-proposed-integration-into-WCAG.html

michaelC: Mechanics of claims is something the W3C cares about but is important to have a model. But agree we do need to understand the practical real world expression of the WCAG criteria.

david: would really like to have one extension that we could mix the SC together and have one thing that we say to the world with our updated extension model.

<Zakim> AWK, you wanted to ask Kathy about Mobile extension plans to have A/AA/AAA criteria

<laura> +1 to David's 1 extension.

awk: Wanted to confirm that Kathy had said that the mobile group already had started to separate criteria into different levels

kathy: mapping to same structure and levels. Right now we have A and AA in the mobile TF and we are using both levels.

jo: should we restrict extension levels to AA?

kathy: I don't think so because we may want to capture things that full into AAA
... technology changes and at least we have captured items as AAA

We have people who pick and choose from AAA


kathy: better to have SC available under AAA. Don't think we should limit it to A or AA. No reason not to.

wayne: Find sites that meet WCAG level such as AA but the assistive technology doesn't work. Recommend report bugs to AT.

<Joshue108> Extensions that modify existing success criteria do so with full consideration of the impact on the rest of the guidelines in context of the full set of requirements that apply to the guidelines and extensions. For examples, extensions that lower the conformance level of a success criterion ensure that the success criterion meets the bar of wide implementatbility and testability expected at that level.

<Sarah_Swierenga_> So sorry, but I have a meeting with my manager and must sign off for this week. Regrets, too, for next week due to an all-day on-site meeting with the federal program officer from one of my grants. Thanks for your patience as I get up to speed - and thanks to Mike Elledge for keeping me in the loop during my long absence from this important working group. Have a good day.

MichaelC: AA is higher conformance level than A
... Conformance levels are like climbing a mountain

<Joshue108> Success criteria that are to be moved from AAA to AA or lower must be testable or have global AT support.


michaelC: Trying to explain the consequences of changing a success criteria including the level of a success criteria. If you do does it change the meaning of the SC for WCAG 2
... WCAG does not list the criteria used to set level -- they are in a wiki. We relaxed a little on AAA criteria. Still had to be testable but we didn't need to be as confident.

<Joshue108> +1 to Kathys text

Gregg says the criteria are testable, applicable, and reasonable.

kathy: provided a simplification of what Michael said.

<AWK> It is important to note that changes to the level for existing success criteria need to be made with awareness of the implementability and testability requirements for the new level. For example, a Success Criteria may currently be at Level AAA as a result of very limited testability, and moving that Success Criteria to Level AA would require greater testability.

michaelC: really are speaking to level changes -- so perhaps it might be better to talk about that rather than us trying to be more general.

awk: also wrote an alternative. Will read Kathy's now.

kathy: fine with either one.

awk: May make more sense to put it under the section with conformance structure model as well.

jo: we could have stricter requirements for extension requirements.

michaelC: don't try to solve issues of WCAG in the extensions model.

jo: don't want to port issues over.

michael: doubt extensions will bother with AAA

<David> +1 on no AAA for extensions

michaelC: don't think AAA is top priority.

<AWK> I doubt it as well

michaelC: people want A or AA stuff
... no need to rule out AAA

<AWK> from the definition of audio description: "Note 2: In standard audio description, narration is added during existing pauses in dialogue."

<Zakim> MichaelC, you wanted to say why rule one thing out like AAA in extensions, when we didnĀ“t want to rule out other things like extensions conflicting?


MichaelC: let's not rule it out.

<AWK> I don't think that we should rule out AAA either

<laura> bye

<Joshue108> bye all

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/11/10 17:31:53 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/COAG/COGA/
Succeeded: s/jo: should restrict extension levels to AA/jo: should we restrict extension levels to AA?/
Found Scribe: David MacDonald
Found Scribe: David MacDonald
Found Scribe: jon_avila
Inferring ScribeNick: jon_avila
Scribes: David MacDonald, jon_avila
Default Present: EricE, Laura, Kenny, Joshue, marcjohlic, Kathy, David, Joshue108, jon_avila, Sarah_Swierenga, MichaelC
Present: EricE Laura Kenny Joshue marcjohlic Kathy David Joshue108 jon_avila Sarah_Swierenga
Found Date: 10 Nov 2015
Guessing minutes URL: http://www.w3.org/2015/11/10-wai-wcag-minutes.html
People with action items: 

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

[End of scribe.perl diagnostic output]