<AWK> +AWK

<AWK> +Rossen

<AWK> +Joshue108

<AWK> +MichaelC

<AWK> +Ryladog

<AWK> +Jeanne

<AWK> +Greg

<AWK> Chair: Joshue

Scribing: Mike Gower

<AWK> Still need a scribe volunteer for January 24 to complete January. Anyone?

<JF> scribe: gowerm

Josh: Welcome back everyone

Requirements for SCs

<LisaSeeman> Hi Pietro

<Joshue108> Welcome Pietro

<JF> Welcome Pietro!

Pietro: Introduced himself. Italian ICT and Comp Sc instructor.

zakem, nextitem

Requirements for SCs (https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria)

<Joshue108> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria

<Wayne> persent+ pietro

Josh: Walk through the SC requirements for comments. Context is general guidelines
... Cannot diverge from 2.0
... Number 2 (testable), 3 and 4 seem uncontroversial
... Number 5 Ensure for revised..."

Josh proceeds through all 9 criterion, reading them out.

<Ryladog__> 8 out of 10

Lisa Seeman: Testability (#2). "an expert has a high degree of confidence..." Define what we mean by "human testable"

<david-macdonald> high degree of correlation?

<Ryladog__> 8 out of 10 experts would agree

Lisa: Take wording that was used in internal wiki and use that.
... [noise on line]
... #9. Wants to add clarification: readily available formats 'that are available by the time 2.1 timelines are met'

Josh: #9 doesn't necessarily even have to be in there. Relates to techniques not requirements

<david-macdonald> "All Success Criteria must also be testable. This is important since otherwise it would not be possible to determine whether a page met or failed to meet the Success Criteria. The Success Criteria can be tested by a combination of machine and human evaluation as long as it is possible to determine whether a Success Criterion has been satisfied with a high level of confidence." https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#[CUT]

Lisa: for #9 we want to move forward so 'readily-available' is future restrictive. "and assistive technologies" is restricitive. Some COGA not using ATs.

Josh: re: "human testable" wording. not need to tinker with right now since it is a .1 update

<alastairc> https://lists.w3.org/Archives/Public/w3c-wai-gl/2016OctDec/0808.html

Alastair: overlap concerns him most (link posted). If done to letter, means we can't do SC especially COGA and LVTF. If anything is an update, then it is an overlap.

<AWK> Alastair is talking about #8?

<Detlev> +1 to Alastair

<LisaSeeman> +1

<jon_avila> some of the lV and COGA criteria have overlap. If we can't change the existing SC then a new would SC and therefore we could not introduce a beneficial SC

<jon_avila> Agree with Alistair - we either need to be able to modify SC or allow overlap

Alastair: not make changes to current ones if possible at first.

<jeanne> +1 to not be rigid about making changes to current SC when appropriate.

<Zakim> MichaelC, you wanted to say risky to depend on timelines that haven´t been met yet and to say #9 very much applies to SC

MichaelC: 9 is a critical part of the requirements. not just about techniques.
... re: timing. Risky to accept SC that are not implementable yet. SHould be marked as at risk, as well as dependencies.

<LisaSeeman> agreed that we need to define clearly why something is at risk

<Zakim> AWK, you wanted to say that we don't need to add the clarification to #9 since we will have items "at risk" if implementations are not complete and to ask if a new SC that requires

Andrew: No need to add anything to #9
... clarification on waht is a modification (i.e. 400 versus 200%). If new one is beyond that, is it a modification?

<david-macdonald> A couple of paragraphs on "testable" are at the top of this document. https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

JF: aspiration versus what is currently done. Aspiration puts us at risk of scrutiny and pushback
... need to be leaders but grounded in realism.

<Zakim> Joshue, you wanted to say what about where semantics don't exist for new techniques?

Josh: overall agrees with John

Lisa: need to make some changes. "support AT" in #9. Not relevant to all users.

<jon_avila> Agree that some users aren't using AT

<AWK> A working draft is not necessarily the same as implementations. Separate issues.

Lisa: Clarifies that Personalization is germane to needs not "readily-available"
... once personalization semantics are in place, burden is lessened.

josh: that seems like a case for incubation

<david-macdonald> https://github.com/w3c/wcag21/issues/6

Lisa: personalization can be done now, but a lot of work. easier when semantics are available
... should be there by CR, not February

katie: Wants to include at risk in first draft to get feedback

<LisaSeeman> +1 to katie

JF: Some At Risk items may be silver-like projects

<JF> https://www.w3.org/TR/media-accessibility-reqs/#time-scale-modification

JF: posts url as consideration of how to handle at risk items. could be released concurrently.

<Zakim> Joshue, you wanted to say that projects like MAUR could be a good template

<Zakim> AWK, you wanted to say that if an SC can be implemented before some new spec that make it easy is finalized and implemented then there is no dependence on that spec needed.

AWK: We don't need to put anything in about specs meeting working draft or CR. If you can meet it today, great. if you can't then it won't be sc or it will be at risk

<Ryladog__> +1 to that statement, just because something is hard, that does not mean we should address it

Josh: +1 If something is hard, it doesn't mean it is impossible. Complex implementation that demonstrates potential is fine. No need to over-engineer requirements
... sense is there is no strong objection. Just comments for tweaks. That is positive.

<LisaSeeman> +1

Wayne: we have extreme needs that block people's ability to use the web, which cannot be met right now.
... we need to be aware that the current paradigm does not meet certain needs. 2 kinds of data: mutable data, that can be changed, and post-process data that can't be customized. (i.e., printer). Latter cannot be addressed by WCAG.

<Detlev> A big issue still seems to be if minor changes on exisiting SCs would be possible to reduce confusion - say, renaming 1.4.3 Contrast (Minimum) -> 1.4.3 Text Contrast (Minimum) so we can have a new one for graphics / icons that separates well

<AWK> acl l

AWK: There are things we won't be able to get to in 2.1. Where that line falls is what we're figuring out as part of process.

Lisa: uncomfortable with #9 as it is.

AWK: with WCAG being technology independent, how can we reference a technology standard?

<alastairc> AWK / Lisa: The issue is between not changing 2.0, and re-writing current SC. We do need to square that - either we can re-write current ones, or we can't and Lisa would need to re-write some to make them additive.

Lisa: cites ARIA as example of how "expose the role" could be included even though it didn't exist in HTML at the time of language drafting of 2.0

AWK: you could expose the role circa 2008. ie. checkbox

<bruce_bailey> Here is the note to SC 4.1.2: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

Josh: if something that can be demonstrated with a user agent, then it is readily available.

<alastairc> Detlev: yes, adjustments to text of current (e.g. Contrast to Text contrast) would help, but I'm happy leaving that to a later stage. Current issue is whether we can only write new SCs, and my example to the list was for https://github.com/w3c/wcag21/issues/51 which moves an AAA to AA, and modifies (slightly) the text.

Lisa: wants to understand what a 'readily-available assistive technology' is. Wants clarification to ensure there is no moving bar

<Zakim> MichaelC, you wanted to say we care about *implementations existing* not *specification maturity* though they inter-relate and to say we need *some way* to exist of meeting a

MichaelC: for accepting a SC we care about implementation existing, not specification.
... We don't care if a preferred means exists; it's whether a means exists. As long as we know it can be met.
... WCAG does not define comprehensively what is 'good enough' That was intentional

JF: re: getting ARIA in before finalized. IBM's support of Firefox is known by many. 2.1 needs to be testable and implementable today. Silver can be more aspirational.

Josh: if there are implementations for COGA available, even if tricky, they can be candidates. Is taht acceptable?

JF: IT is a tricky question. e.g., audio descriptions rarely implemented.

<jon_avila> I see a lot of videos with audio description

<alastairc> JF the exception that proves the rule? http://www.bbc.co.uk/iplayer/categories/audio-described/highlights

<jon_avila> If you relied on audio description you would see it more

Lisa: We need to keep pushing. if that results in some SC not getting traction, okay.

<Ryladog__> +1 to Wayne

Wayne: Understands Lisa's concern. COGA and LVTF have been cut out for so long, there isn't good stuff around. WE need guidelines to encourage people.

<LisaSeeman> +1 to wayne with hug

<kirkwood> +1 to Wayne

Issue 77 review: https://github.com/w3c/wcag21/issues/77

Numbering & updating SC (https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering)

<Ryladog__> yes, I recall that

AWK: Some discussion on call and on list. No perfect solution right now. Until we get clarity on #8 (overlap) we can't make decision on numbering.

<alastairc> +1 we need to decide on whether we can re-write current SC, then decide numbering

<Ryladog__> Can we do asurvey on this?

Josh: question is: are we going to rewrite existing SC?

MichaelC: we shouldn't assign numbers to SC right now. Has no preference for numbering scheme. "how to meet" Quick document went through major changes in last year. Some people involved in that are hoping that will be the primary landing point. If that happens, people will be sorting, so consistent numbering isn't so important.

<Joshue108> +1 to being open to the possibility of re-working current SCs before considering numbering etc

<bruce_bailey> +1 to what MC is saying for QuickRef ability to support 2.1 and about SC having meaningful handles and more arbitrary numbers

MichaelC: suggests using 'handles' instead of numbers.

<LisaSeeman> +1

<laura> +1

<Wayne> +1

<steverep> +1 to Michael

<JF> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_SC_Numbering#Non-Specific_Feedback

<kirkwood> +1 to JF referncing the legal folks numbering

JF: In the real world, the handles are useful. The numbering for standards people is more important (pasted link)
... favours alpha or numeric extension. Numbers are there for reasons -- reporting, etc

<laura> +1 to using 'handles’ and de-emphasising(not eliminatingnumbers.

<kirkwood> +1 to JF

MichaelC: clarifies not abandoning numbers

Katie: it's fine that numbers will be out of order. we should absolutely not change the nubmers or text of existing SC. This is not 3.0 where we can re-arrange everything.

<JF> +! to Katie's point, this is a dot-release of an existing standard

<kirkwood> +1 to Katie’s statement

Josh: would like to hear about additive examples.
... concerned about too absolutist statement about not changing numbers or text

Alastair: Worried about how confusing 2.1 will be.
... asks Lisa if it is possible to not alter current SC to incorporate COGA.

<alastairc> JF: https://lists.w3.org/Archives/Public/w3c-wai-gl/2016OctDec/0808.html

JF: 2.0 would just be text/images of text. 2.1 would add icons.

<Glenda> JF, we are not changing that SC, we are adding a new SC…for clarity. I

<alastairc> https://github.com/w3c/wcag21/issues/51

Alastair: the devil is in the details. Pastes example.

JF: make it 8a or 8.1 since more info isbeing added it is stil 1.4.8 but more stuff is being added.

Lisa: thinks an additive approach is a mess.

<Joshue108> +1 to Lisa

Lisa: says the timeout is too short. How do you change that?

<Glenda> JF, on 1.4.3, that original SC is only about text…so adding color contrast for icons, and visual focus indicators is similar not not a “child” of the original 1.4.3 (it is a proposed NEW SC).

[noise on line]

<Detlev> OK

<Zakim> bruce_bailey, you wanted to argue that renumbering is less concern than only increasing accessiblity requirements

Bruce: numbering decision should be last. It is secondary to maintaining the backwards compatibility.
... numbering is irrelevant since gov't does date-specific references
... some rewording is going to need to be done to bring some existing SC into agreement.

<bruce_bailey> some of the SC do not have exactly consistant phrasing for the same concept from one SC to the next

Lisa: the simpler we can make it for developers, the better. Simplicity should be goal.

katie: stepping back from 'don't change'. We start out by adding new things [noise]
... low-hanging fruit is adding. where it gets complicated, we need to be together to carefully rewrite.

steverep: ... future stakeholders are important to keep in mind. if 2.1 is complicated, additive version, people will be put off. We can't completely rule out changing SC.

<jeanne> +1 to steverep

Wayne: AAA items are the sticky ones. But it doesn't matter too much: they're not as well formed; few people implement.

<Zakim> AWK, you wanted to talk about issue 51

Wayne: Changing AA needs to be heavily scrutinized, AAA not so much.

<Glenda> +1 to what Wayne just said about AAA not needing as much scrutiny.

<Detlev> Sorry for not being able to dial in without noise - I strongly support putting usability and conciseness of WCAG 2.1 above concerns reg. rewording / renumbering

<Joshue108> thanks Detlev!

AWK: this will come down to looking at specific examples. Maybe we move forward without fully resolving. uses Issue 51 as example of way to tackle

<alastairc> For ones which propose change, suggest an impact assessment at the bottom of the doc that people can add to with techniques / failures.

<Wayne> +1

AWK: wants to minimize changes to extent possible.

Dav: suggests making additive for first draft. Larger point: Need to do 9 a week for next 7 weeks to make deadline.

<Zakim> Joshue, you wanted to say the pure additive model is likely a throwback to the extension model and we need to take an objective look at our process

<jeanne> +1 to Joshue. We need the flexibility to respond the needs of users of WCAG.

Josh: Parting thought: the group has to consider that SC may have to change going into 2.1.

<Mike_Elledge> Was just going to suggest that we indicate where SC have been revised or added to make it easier for ppl to identify the changes. :^)

<Detlev> is there a link to *all* new suggested SCs anywhere?

Josh: could clear the path to making our February goal

<alastairc> Detlev: https://github.com/w3c/wcag21/issues

<Mike_Elledge> bye all

<marcjohlic> trackbot, end meeting

<Detlev> ta Alatair

<AWK> then copy and paste the url in an email to the list

trackbot, end meeting

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

<trackbot> Date: 03 January 2017

<AWK> Trackbot,m list attendees

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

<AWK> Trackbot,list attendees

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

<AWK> Trackbot, list attendees

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

<AWK> trackbot, end meeting

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: gowerm
Inferring ScribeNick: gowerm

WARNING: Replacing list of attendees.
Old list: Detlev Erich Mike Elledge MoeKraft
New list: AWK Rossen Joshue108 MichaelC Ryladog Jeanne Greg bruce-bailey wayne kirkwood JF alastairc MikeGower Laura Lauriat Lisa_Seeman David-macdonald Pietro Kathy adam_Solomon jon_Avila marcjohlic moekraft Glenda Erich Katie_Haritos-Shea Mike_Elledge SteveRep Detlev

Default Present: AWK, Rossen, Joshue108, MichaelC, Ryladog, Jeanne, Greg, bruce-bailey, wayne, kirkwood, JF, alastairc, MikeGower, Laura, Lauriat, Lisa_Seeman, David-macdonald, Pietro, Kathy, adam_Solomon, jon_Avila, marcjohlic, moekraft, Glenda, Erich, Katie_Haritos-Shea, Mike_Elledge, SteveRep, Detlev

WARNING: Replacing previous Present list. (Old list: AWK, Rachael, Laura, MikeGower, Kirkwood, David-macdonald, alastairc, Bruce_Bailey, Joshue108, jeanne, Lisa, Seeman, Jf, steverep, MoeKraft, Glenda, Katie_Haritos-Shea)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK


WARNING: Replacing previous Present list. (Old list: AWK, Rossen, Joshue108, MichaelC, Ryladog, Jeanne, Greg, bruce-bailey, wayne, kirkwood, JF, alastairc, MikeGower, Laura, Lauriat, LisaSeeman, David-macdonald, Lisa, Seeman, Kathy, steverep, jeanne, marcjohlic, jon_avila, adam_solomon, Katie_Haritos-Shea, Glenda)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Detlev


WARNING: Replacing previous Present list. (Old list: Detlev, Erich, Mike, Elledge, MoeKraft)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK, Rossen, Joshue108, MichaelC, Ryladog, Jeanne, Greg, bruce-bailey, wayne, kirkwood, JF, alastairc, MikeGower, Laura, Lauriat, Lisa_Seeman, David-macdonald, Pietro, Kathy, adam_Solomon, jon_Avila, marcjohlic, moekraft, wayne, Glenda, Erich, Katie_Haritos-Shea, Mike_Elledge, Kirkwood, SteveRep, Jeanne, Detlev

Present: AWK Rossen Joshue108 MichaelC Ryladog Jeanne Greg bruce-bailey wayne kirkwood JF alastairc MikeGower Laura Lauriat Lisa_Seeman David-macdonald Pietro Kathy adam_Solomon jon_Avila marcjohlic moekraft wayne Glenda Erich Katie_Haritos-Shea Mike_Elledge Kirkwood SteveRep Jeanne Detlev
Found Date: 03 Jan 2017
Guessing minutes URL: http://www.w3.org/2017/01/03-wai-wcag-minutes.html
People with action items: 

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