<AWK> angeda+ Survey: https://www.w3.org/2002/09/wbs/35422/Misc_Oct31/results

<Detlev> scribe: Detlev

Survey: https://www.w3.org/2002/09/wbs/35422/Misc_Oct31/results

hakim, next item

<Alex__> prsent +

hakim, take up item 5

<AWK> Survey: https://www.w3.org/2002/09/wbs/35422/Oct_31_2017/results

Survey: https://www.w3.org/2002/09/wbs/35422/Oct_31_2017/result5s (#1 and #5)

Problem with Technique G131

<jamesn> get document not found with that url

JF: Was talked about at the last call

AWK: we didn't
... comment was about these of the term "required", might be ambiguous - so there was a suggestion to change it express that the label should be permanently visible
... has concern - cannot be safeguarded

mgover: Should not put to much attention on details - there is a reference to required, incl. 3. example - seems to be over-complicated

AWK: paraphrases Mike that the Technique is not about the required state

JF: trying to clarify AWKs comment / suggestion

AWK: latest change proposal was from Jake (incl. the "permanently visible" aspect)

JF: We test permanently visible all the time - all controls need that

AWK: point is that from a testing perspective - you cannot tell because you are only testing the instance when you look at it

<lisa> there are places when a visualble lable on each area will mess up the uri

mgover: There is no explicit requirement for a label

Lisa: some interfaces would be messed up if everything had a label

James: If we remove required indicator, then the technique changes - it seems to focus on the need to have the required indicator as part of the label - do we really want to change that technique now?
... so it has a more narrow focus on required state
... controls may or may not be required programmatically depending on the state of a form

AWK: what id your proposal James?

James: just wants to point out it cannot be removed from the test procedure without changing the technique

Detlev: let"s defer

<jamesn> +1 to defer it

<AWK> "Check that a visible indicator is present for a required interface component"

mgover: will try rewording technique

<Glenda> Let’s defer

AWK: getting disenchanted with suggested change

=1 for deferring

<laura> +1 to defer

RESOLUTION: Defer for a later time

Survey: https://www.w3.org/2002/09/wbs/35422/Oct_31_2017/ (#1 and #5)

AWK: opinions seem very close

<AWK> Alastair's suggestion: For user interface components with labels that include text or images of text, the name contains the text presented.

AWK: text is a defined term that is why we need alternative text for images of text
... Alastair's suggestion seems to cover the issue

Steve: fine with proposal

AWK: no concerns, accepted as amended

RESOLUTION: accept as amended

<steverep> I will take action to amend the pull request.

Survey: https://www.w3.org/2002/09/wbs/35422/Misc_Oct31/results

Started with JF proposal for response, Alastair and AWK have added to it - Lisa has concerns

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/Misc_Oct31/results#xq1

Lisa: Found it difficult to understand what it meant - priority 1 with many items deferred
... Not sure who is working with this group - it might be confusing as a response for Coga TF?
... maybe get rid of the first section

JF: In their original note they talked about 1. priority and 2. priority - they were referring to WCAG conformance levels

Lisa: Still finds it confusing - looks like we follow the same prioritisation but then it becomes clear that much has been deferred

AWK: The threading (in working on that response) has been lost

JF: it goes back to issue #211

Lisa: cannot comment because she cannot work out what us original, what has been changed

AWK: The only line is the 2. para (10 coga SCs) and..
... will put in some > characters so we can more easily distinguish what came from them and what was our response

Lisa: Coga TF may not understand the reply - we are asking for feedback
... We have been polite but not spelled out what information we need from them to address the conformance levels for each proposed SC
... We should also offer help to understand decisions if they need to

AWK: We can add a line to extend help
... We did respond to the individual issues - quite hard to read though

JF: All issues noted have received a specific response

Lisa: People felt that the response was getting too long - we should explain why we have moved SCs to level AAA - this is what is needed
... response is not clear what we actually need
... does't address conformance issue
... issues should be separate github issues and explain why we have moved to up to higher levels whereas people think it should have been A or AA

<AWK> how about at the last paragraph we say "Offering each comment in a separate GitHub issue is helpful in that not only is there only one question for the group to respond to but also provides a shorter and simpler response for the commenter."

<gowerm> +1 to JF

JF: Looking at comment to SC Provide support - with an issue #32 and comment - there was no proposal in the original issue #32 why the level AA was appropriate - are you saying that people are unable to follow a link to the issue? It would be too long, can't read a bible here

Lisa: Wants to have additional issues to clarify what is needed

AWK: providing text about offering separate Github issues to make it more manageable
... The group was nit asking, it was stating a position ("It should be on other conformance levels")
... Our response to that is reasonable - they may object to that and reply

<lisa> add sentence,:to change the priority level the more informarion we have on the user impact and technical implementions will be also very helpful

<Glenda> +1 supporting the response as written

<KimD> +1 to AWK. And I like JF's response.

AWK: We cannot anticipate all additional questions

<gowerm> +1 wait for their response

Lisa: Likes text suggested by AWK
... Add sentence lie " The mitre info we have on impact, the better we can assess conformance level change suggestions"

<marcjohlic> s/miter/more

Lisa: add "If you need further info on how to move forward, please be in touch.."

<bruce_bailey> I took myself off queue because mikeG made my point

mgover: Our process is geared toward achievable, they have a different approach (priority level) based on user impact

Lisa: "achievability" may be a good term to add

JF: Lisa, please confirm that at this time we are not going to change conformance levels

AWK: disagrees - SCs may be moved up or down depending on availability of Techniques
... it is unlikely though

<jon_avila> I think it is possible that something we indicated as level AA could move to AAA

<jon_avila> It would be based on whether the SC could meet the acceptance requirements such as implementations

JF: We should clarify that conformance levels cannot now be changed based on lobbying
... We have to emphasise that we have internally debated conformance levels depending on ability to meet acceptance requirements

<lisa> https://docs.google.com/document/d/1WcfVALVq8PS9CLXUuAfV9Op0wXvI2yJYedj5jO23GTk/edit#

Lisa: We have to show that this stuff is not lost
... Suggest that we are going to make a non-normative document

AWK: This is already the longest response ever - putting in more info might not help
... Important to point them to the latest draft to get comments that are more in tune with the current state

Lisa: We need to manage expectations, mitigate anger

AWK: What can we put in there JF to refer to conformance levels?

JF: We point them to the definitive source about determinations of conformance level choices - we just need to leave the door open for continued dialogue

Lisa: Put versions of comments in (?) - should have conversation with Judy on expectance and mitigation - there might be lots of objections, people abandoning WCAG so we need to address that

<lisa> http://easy-to-read.eu/wp-content/uploads/2014/12/EN_Information_for_all.pdf

AWK: Not sure where some of the notions like abandoning WCAG come from
... Lisa, are you OK to point to single SCs ?

Lisa: No

<gowerm> =q

<gowerm> +q

AWK: then we need to defer - any objections?
... Feedback was OK

mgover: No response yet, correct?

<Glenda> +1 let’s take a vote

<bruce_bailey> @Lisa, is there an HTML version of that document?

mgover: we should not defer a response - we should get this one out, and follow up if needed

Detlev: agree with Mike, get it out!

<bruce_bailey> +1 to sending response sooner than later

<KimD> +1 to respond

JF: Followed link to the PDF wonderful, but not standards-based - several dos and don'ts that do not fit into a standard, but are guidelines/ recommendations, not measurable, testable - agrees to get out the response

<lisa> quote: "The "Web Accessibility Initiative"is an international association.They have developed some important accessibility standardsfor information on computers.For example for people who are blindor for people who have trouble moving their hands.They have written guidelinesto make websites accessible for disabled people.You can find these guidelines here:http://www.w3.org/WAIUnfortunately,...

<lisa> ...they are not easy to read"

<Rachael> +1 to respond, even if it is a shorter response with a followup.

Lisa: recommendations used in 16 countries even though not a standard

<lisa> http://easy-to-read.eu/european-standards/

can we change scribe?

<lisa> (where it is from)

<lisa> I am not at tpac\

<bruce_bailey> @lisa, the document says things like “Standards for written information”

<KimD> Send JF's reply with tweaks

<Glenda> +1 to send out now with minimal changes

AWK: Defer or send out?

Marc: send out as is

<KimD> I'm ok with sending out JF's as is too

Marc: let them come back if they have further questions

<gowerm> +1 to send out

Jason: agrees to send it out, concerned of use of time at telco for editorial changes

+1 for sending

<bruce_bailey> @lisa, you provided the URL for a page listing the PDF

<Makoto> +1 to send out as is

AWK: there is the option to have a follow-up -Lisa can you go along with this?

<bruce_bailey> @lisa, I am looking for an HTML version of the content

<JF> +1 to send out as is

Lisa: raises objection but send it out

<Jnurthen> +1 to send it.

Next scribe?

RESOLUTION: Accept as amended https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0283.html (Lisa objection)

<laura> Scribe: Laura

Conforming alternatve versions need labels

<lisa> FYI they are part of EU standandeds, in 16 languages, http://easy-to-read.eu/european-standards/

AWK: Issue 306
... https://www.w3.org/2002/09/wbs/35422/Misc_Oct31/results#xq2
... Steve submitted this back in July.
... https://github.com/w3c/wcag21/issues/306

Steve: There is no explicit requirement, however, to label it as the accessible version for the benefit of the user.
... There is also no requirement to inform the user about either what is inaccessible about the non-conformant version or what has been enhanced in the conformant version, so the user is left simply to trial and error and thus wasted time and potential confusion.

<Zakim> bruce_bailey, you wanted to say I worry that this may be a “poison pill”.

AWK: reviews survey responses

Bruce: worrys that this is a “poison pill”
... skeptical that this is a good idea.

awk: in PDF there is the matterhorn protocol.

<Zakim> steverep, you wanted to say the intent was not a laundry list

Steve: 2 requirements that I changed.
... Understand the difficulty with number 5
... maybe we could drop that one.

<Zakim> bruce_bailey, you wanted to say I am not talking about new PDFs

Steve: really just a few things.

<Glenda> great idea Steve, but it is a new requirement…so I can’t support adding this to legacy content

Bruce: would be difficult for agencies. and legacy docs.
... now we can put a wall in front of those.

JF: recoginze it is a real problem. But strongly reject as we can’t change WCAG 2.0.

<bruce_bailey> I also agree with @steveR and @JF with supporting problem

JF: support the desire. But object.

<bruce_bailey> I also agree that it is problematic for 2.1 to have a different definition for CAV than 2.0 has

Jason: only look at implementation for 2.1. Doesn't think it would be a problem
... for 2.0.

<alastairc> I started off agreeing with the change, but I'm persuaded the other way now, it will make implementing 2.1 harder if we can't say that you can leave legacy content.

<Zakim> steverep, you wanted to ask how this could possibly break backward compatibility

Jason: would make it a case to move to silver.

Steve: Fine with dropping #5
... no hardship with #4
... don't understand how this would break backwards compatibility.

AWK: if you conform to 2.1 then you conform to 2.0. doesn’t change backwards compat.

<alastairc> I suppose the other way of looking at it is: If a page is meeting 2.0 it doesn't need to label the alt version, but a new page confirming to 2.1 would?

John: It changes the 2.0 Definition.

<Zakim> AWK, you wanted to suggest adding a note for "conforming alternate version" in the Understanding document

<bruce_bailey> +1 to what @JF is saying to consider adding change as a SC

<alastairc> Won't 2.1 have a new glossary?

hich is normative. breaks backwards compat.

<bruce_bailey> +1 to adding best practice in Understanding

awk: maybe add this to the understanding doc.
... we could put this out there today.

<Zakim> JF, you wanted to respond to Jason's comment about applicability

John: concern that 2.0 or 2.1 compliant but not something in between.
... people may be somewhere on the journey.

Mike E: if it is in the understanding would JF object?

Steve: Maybe we could address with a note.
... problem with deferring. Would stifle progress.
... changes would be in 2.1.

JF: cringe at not having an in between.

<Mike_Elledge> Also wondering if this isn't already covered by Link Purpose (2.4.4)

<gowerm> No, he's not

Steve: not true that we are changing 2.0.

AWK: we want to minimize changes.

<Glenda> I’m pretty sure we shut the door on new requirements a long time ago….this one does not get to sneak in. IMHO

<alastairc> I'm on queue to say: I don't think it is difficult as John suggests, but also not as effective as Steve would like - it is page by page.

AWK: need to be cautious in changing.

<gowerm> +q to say we should add Steve's changes to #4 to the Understanding Conformance document

<Glenda> this is out of scope for 2.1

AWK: adding is less of a problem. Need to explain in understanding.

AC: not as difficult as JF suggested.
... not a requiremnet for 2.0. It would be for 2.1.

<bruce_bailey> From 2.0 definition of CAV: Note 2: The alternate version does not need to be matched page for page with the original (e.g., the conforming alternate version may consist of multiple pages).

AC: but not as effective as steve would like.

JF: feels like we are back dooring a new requirement.

<lisa> +1 to alex, cookies etc

alex: proposal assumes page by page basis. What if it is by user profile?

<lisa> with userfirst, it is based on a cookie agfter the first time you used it

alex: potentially not work.
... Will search function not work?
... makes an assumption.

steve: different requirement. I just altered the current version.
... think it is a separate issue

<alastairc> Alex__: these are both issues with the current 2.0 text, Steve just added the labelling aspect.

alex: assumption that this is not based on user profile

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

steve: that is a separte issue becase it is already in 2.0

<bruce_bailey> @alex, just because Google returns a URL to an inaccessible version, the site owner could intercept that.

steve: proposal is just in labeling.
... italicized text

jason: existing text 2.0 addersses that the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism,
... not clear that proposal is a problem.
... don’t understand JF’s concerns.
... it adds a condition. Don’t need new SC. No backwards compat issues.

<Zakim> bruce_bailey, you wanted to ask Steve why it is a problem for an owner to use their mobile version as their CAV without saying so? and to also say that it is not blocking to have

<JF> +1 to Bruce

Bruce: don’t think it breaks our rules for differn definitions in 2.1 and 2.0. It is just confusing.
... labeling requirement is confusing.

<Zakim> gowerm, you wanted to say we should add Steve's changes to #4 to the Understanding Conformance document

Mike G: Let’s update understanding

<Zakim> steverep, you wanted to agree with Alastair

AWK: and we could update link purpose.

<Detlev> agree that SC Link purpose requirements and changes to understanding doc would be enough

<Alex__> good point

steve: sign language version would be the nonconforming version?

Bruce: yes.

JF: Yes we could put it into the Understanding
... concern with changing definitions between 2.0 and 2.1

<bruce_bailey> I agree that expecting a screen reader user to magically know that the mobile version is the CAV is a problem, but I do not agree that this is the way to solve the problem

<Detlev> Don"t we already have changes to the conformance requirements for 2.1? Then this wouldn't be the only case

JF: struggle with the proposed solution. Need a new SC.

Steve: not trying to backdoor anything.

<alastairc> Happy with adding this to the understanding doc. Where do we note new SC for WCAG 2.2 / 3.0?

AWK: Anyone object to update understanding?

<Mike_Elledge> Changes to understanding +1

RESOLUTION: Handle through changes in understanding

JF: Dinner a TPAC Monday night has the greatest response.

Candidate Rec Exit Criteria

JF: person requesting kosher prease concact john.

AWK: Kim had a comment about real world support.
... that is what the exit criteria is all about.

Kim: not sure.
... if it addresses my concern.

awk: we would need to know what else is needed.

kim: coga should map back at a higher level.

<lisa> do not understand what she is saying

<marcjohlic> lol

<KimD> *sorry for audio issues!

RESOLUTION: Leave open talk about on Thursday.

trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

FAILED: s/miter/more/
Succeeded: s/say that you have to update legacy content./say that you can leave legacy content./
Succeeded: s/ing 2.0 and/in 2.1 and/
Default Present: AWK, KimD, steverep, JF, Kathy, Makoto, MichaelC, Roy, Rachael, kirkwood, shadi, Greg, jasonjgw, Detlev, bruce_bailey, Brooks, Laura, marcjohlic, Glenda, lisa, Mike_Elledge, MikeGower, jon_avila, JakeAbma, Mike_Pluke
Present: AWK KimD steverep JF Kathy Makoto MichaelC Roy Rachael kirkwood shadi Greg jasonjgw Detlev bruce_bailey Brooks Laura marcjohlic Glenda lisa Mike_Elledge MikeGower jon_avila JakeAbma Mike_Pluke
Regrets: EA_Draffan
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: Laura
Inferring ScribeNick: laura
Scribes: Detlev, Laura
ScribeNicks: Detlev, laura

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 31 Oct 2017
People with action items: 

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


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)