See also: IRC log
<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
<jon_avila> I can scribe
<David> jjjjj
<jon_avila> scribe: jon_avila
yes
<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
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
<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?
<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
+1
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.
bang
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?
+1
MichaelC: let's not rule it out.
<AWK> I don't think that we should rule out AAA either
<laura> bye
<Joshue108> bye all
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]