<AWK> WCAG Techniques and Understanding comments – soliciting assistance for items https://github.com/w3c/wcag/issues

<AWK> +AWK

<KimD> +KimD

<kirkwood> +kirkwood

<Rachael> +Rachael

<Sarah_Swierenga> +Sarah_Swierenga

<AWK> Scribe: Alistair

<alastairc> AWK: Please note the attendance survey, but unfortunately our sanity is not being helped by administering the survey tool. We'd like to go back to the old way of doing it (i.e. reply to the agenda, responding to the list) if you cannot attend.

TPAC Registration reminder: https://www.w3.org/2016/09/TPAC

scribe, wayne

AWK: TPAC Reminder. Please come if you can. It helps with the group unity. Strongly encourage people...

Survey on SC requirements: https://www.w3.org/2002/09/wbs/35422/reqsWCAG21/results

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

<steverep> FYI, TPAC overlaps with the USBLN conference which is just one reason I cannot attend

AWK: It looks like 8 have anwered. The first one are how do we assess new criteria. The second is what support is needed. Best Practice guidelines.
... Success Criteria Criteria most think are good.

<Ryladog_> +1 to add this text to the page

Laura: There should be guidance on Level A, AA, AAA

AWK: The problem is the rules are hard and fast.

Laura: Should this be put in best practices.

AWK: the present ocument looks at common factors, but there is a certain subjectivity.
...: We would like, but it is elusive

<AWK> From Understanding Doc: https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head

MichaelC: We could point to the old document.

<jon_avila> Agree with David.

<MichaelC> Factors the WG considered in conformance levels before

<jon_avila> Look at what happened with WCAG to non-web ICT where we ended up with provisions that don't apply to software that is screen based such as titles for screens

David: We do not want to be technology. Don't want to forbid outright that technology.

<Greg> Every SC should clearly specifies whether the described behavior is required to be (a) Always On, (b) On In The Default Configuration, (c) Available In The Default Configuration, or (d) Available (possibly using third-party tools).
..: IN WCAG we talk about markup languages. I just may be something about particular groups of languages that would be called out.

Greg: Every SC should be always, vs available or available as appropriate. Authors always, only available or by default.

<Zakim> JF, you wanted to say that mark-up is not technology

JF: I don't think a markup language is a technology, a screen reading software. We need a clear definition of technology.

<Ryladog_> Defintion of Technology in WCAG 2 = technology (Web content) mechanism for encoding instructions to be rendered, played or executed by user agents Note 1: As used in these guidelines "Web Technology" and the word "technology" (when used alone) both refer to Web Content Technologies. Note 2: Web content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user exper[CUT]

Jon: Scope success criteria: Page titles only apply ot app title. Where screen based content we .... Some software is mainlined so we cannot have titles.

AWK: What would that mean relative to Davids comment.

Jon: We need scoping.

<Ryladog_> Note 2: Web content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static Web pages to synchronized media presentations to dynamic Web applications. Example: Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript. text

David: That is what I meant.
... We would only want to do that was essential.

<jon_avila> like png
..: Why would we

JF: All we can do is define requirements.

AWK: I am concerned about not having a clear line that technology specifics. if we had had items that some technologies could not do, If we found technology specific SCs it would not lay out the linear path for all SCs.

<Greg> I would change the language to read “Apply across technologies to the extent possible. (Technology-specific issues should usually be in Techniques.)”

<Ryladog_> +1 Greg

<JF> +1 to Greg's point. Keep technology items in the techniques section

Greg: This to Davids point. Apply across technologies where appropriate.

<davidmacdonald> +1

-1

<laura_> +1

<Rachael> +1

+1 for guidance to ourselves

MikeE: It sounds like technology should be in techniques and if it is an SC it should be broad enough to apply across technology

AWK: Agrees. Maybe there is some wiggle room to look and justify.
... I think 4.1.1 that is redundant to other criteria.

MikeE: I can point to it and say validate code.

<Zakim> Ryladog_, you wanted to say unique IDs needed to be called out, I think. Sure there may be another/broader way to say that

Katie: The confusion about 4.1.1. I understand that it is best to go with what was ssuggested.
..: Like unique ids, and it is valid today.

<davidmacdonald> Historically 4.1.1 was a compromise between those who were lobbying for full validation... it was a huge war...

<Greg> (Re Michael’s statement that technology-specific things should be in Techniques.) One problem in my mind is that every technique should flow a fairly obvious result of the SC.

Greg: Scoped SCs should be in Techniques: The SCs have weight but techniques don't. Its not obvious that it would be followed. Techniques are non-normative.

<Ryladog> +1 to MC

<Greg> As Michael says this document is for our guidance rather than a public, hard-and-fast requirement, so it would be useful to state that at the top of the document, just so everyone is clear on the document’s application.

MichaelC: I agree with the principle, but it should be rare

<Greg> (Re Wayne’s concern about inaccessible technologies) Web sites that rely on a technology that cannot meet WCAG cannot be considered compliant. A web page can, however, offer both a version or mode that uses the inaccessible technology as long as it also provides the same functionality through a version or mode that is compliant.

AWK: We want to have SCs that are not technology specific. Related to technology there will always be gaps. But we want look forward as much as possible.

<davidmacdonald> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conforming-alt-versions-head

<jon_avila> This goes back to the WCAG conformance requirements -- if you rely on technology it must be conformant unless there is an alternative

JF: If a user is not an ARIA aware tool.

<AWK> Wayne: you might use a technology that has no accessibility support and that is a problem for users

<AWK> JF: Is that a problem that this WG can solve?

<davidmacdonald> Why permit alternate versions? "Sometimes, pages use technologies that are not yet accessibility supported. " https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conforming-alt-versions-head

<AWK> Wayne: The problem is if content doesn't work in ANY user agent

<Zakim> steverep, you wanted to ask if filling out survey after the meeting is okay and to

David: We have why permit alternative versions. If some want to use technology that is not accessiblity supoorted there must be an alternative version.

<alastairc> +1 to david, WCAG2 has got that covered, we can move on.

<davidmacdonald> +1

AWK: It is possible to meet SCs with no UA to support it, but you would have to have some AT that supports the content.

<Greg> I think our seeming disagreement is caused by differing interpretations of "technology". By "a web site relying on a technology" I didn't mean the user's choice of screen reader or browser, but rather things like pages conveying text only through Flash.

<Zakim> JF, you wanted to note that "pages" is now becoming something of an antiquated term

JF: So, David quoted the text that used, " a page that ..." We might want to move beyond "page".

AWK: Suggest editorial changes to criterion 3.
..: I'm not clear about as broad as possible but not too broad. This bullet is challenging. SCs don't include redundant. We should not introduce any more.

<davidmacdonald> http://davidmacd.com/blog/what-are-WCAG-success-criteria.html

JF: Keyboard vs touch. That is how I interpreted it.

<davidmacdonald> See table from Gregg

AWK: That is the art vs the science.

David: To apply to all problems you want to address without restricting things that shouldn't
...: be addressed.

<Greg> Gregg's table is wonderful, except that once again it uses the ambiguous term "technologies".

<Greg> Some technologies are inaccessible, and we don't want to reword our SC make them pass.

SCs should apply to all problems you want to address without applying to problems it is not trying to address. No unintended consequences

<davidmacdonald> IF the Proposed Wording ... THEN

<davidmacdonald> Can be mis-read or misunderstood Use different wording

<davidmacdonald> Does not apply to a part of the problem that it should apply to Wording is too narrow or specific in its language and it needs different wording.

<davidmacdonald> Forbids something that is OK Wording is too restrictive or too general and it needs to have qualifications or exceptions, or be worded differently.

<davidmacdonald> Is impossible to meet in some technologies It is too general and needs to have qualifications or exceptions or be worded differently.

<davidmacdonald> Is not specific enough that you can tell when you have done it. It is not testable, and it needs rework.

<davidmacdonald> Introduces problems for some other group besides the one you are trying to help (e.g. works great for some - but not good - makes it worse - for others). It needs to be reworked so that it addresses the problem you are trying to solve without making other problems.

<Greg> Andrew, as you say, since it's only for our guidance and not normative even for us, it's fine as a goal to keep in mind.

AWK: The item is find the balance. But it is there.

<AWK> Suggest adding: Avoid establishing redundant criteria for content which are addressed in other Success Criteria

<AWK> Suggest adding: Avoid establishing redundant criteria for content which are addressed in other Success Criteria

<Greg> +1

+1

<Greg> Avoid making SC mutually exclusive, as well.

AWK: You need to provide alternative criteria and in another criteria on linked images having a name. Something we need to minimize.

<AWK> Suggest adding: Avoid establishing criteria for content which are addressed in other Success Criteria

<steverep> Change "Success criteria describe the specific condition required to meet the criteria, not the method to reach the condition" to "Describe a specific condition required of the content, as opposed to a technique or method to reach the desired condition"

Two Problems: We have many TFs and it is hard to fit new SCs into olf criteria.

<Greg> I agree we should try to avoid redundancy and list it as a goal. However, one reason that it's not always be possible is the organization into section for Perceivable, Operable, etc. It is inevitable that some design aspects will fall into more than one category.

+1

<KimD> +1

<Greg> "Try to avoid ..."

Avoid redundancy where possible....

Rachaell: Is this a best practice instead of requirement?

AWK: I think they are different. It feels more specific than be as specific as possible, but best practice is more about writing instead of content.

<Greg> Agreed with Rachael: since the first section starts with "SC SHALL", it seems that anything that is a "SHOULD" belongs elsewhere.

Greg: The only things that should be like normative vs. non-normative.
... I wasn't clear on the difference between criteria and best practice.

<Greg> On the other hand, since the entire document is non-normative, only general guidance to ourselves, maybe it's not worth worrying too much about moving things around.
...: Since the whole document is non-normative we don't have to worry about that detail.

AWK: We leave this one in here. If we think this is good we send it out for consensus

Steve: Describe the condition to meet the criteria rather than a method, the criteria is circular. You could simplify.

<Greg> Success Criteria Shall: Clearly specify whether the described behavior is required to be (a) always on, (b) on in the default configuration, (c) available in the default configuration, or (d) available (possibly using third-party tools).

<Greg> Everything that can be checked independently or referred to has to have some way of referring to it, thus numbered lists are always better than bulleted lists when they can stand alone.

AWK: The could be best practice.

<Greg> For example if “Lists are used”, which reads like any page would fail to comply if it fails to include at least one list--or two, depending on the reader’s interpretation. What you really mean is “Information is conveyed using lists when they are appropriate”.

JF: Why the video should auto start, or choice or at least in a profile.

Rachael: We have this conversation with color scheme. This could be a criteria. Would this apply to existing SCs.
... We are allowing change to existing criteria.

<alastairc> NB: I used the SC requirements to draw up this page: https://www.w3.org/WAI/GL/wiki/Animation_caused_by_user_interaction and it was a very useful process. (Not that it is fully-baked yet, but it helped!)

<Rachael> Slight correction: I think this is valuable but if we add it as a requirement for critera, would we commit to adding it to existing SCs?

AWK: We will run into timeline issues. We want to be carefully. This starts to get us to UA requirements. This may be something that is hit hard in Silver instead of 2.1. We may talk about this on the list.

<Sarah_Swierenga> bye everyone

trackbot, end meeting

<Laura> bye!

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/illusive/elusive/
No ScribeNick specified.  Guessing ScribeNick: Wayne
Found Scribe: Alistair
Default Present: AWK, JF, Joshue108, Rachael, Makoto, Lauriat, Kathy, Laura, Greg_Lowney, lisa, adam_solomon, marcjohlic, KimD, Katie_Haritos-Shea, MichaelC, jeanne, moekraft, Mike_Elledge, Lisa_seeman, alastairc, jon_avila, shadi, steverep, Davidmacdonald, Wayne, Judy, Elledge, kirkwood, Sarah_Swierenga
Present: AWK JF Joshue108 Rachael Makoto Lauriat Kathy Laura Greg_Lowney lisa adam_solomon marcjohlic KimD Katie_Haritos-Shea MichaelC jeanne moekraft Mike_Elledge Lisa_seeman alastairc jon_avila shadi steverep Davidmacdonald Wayne Judy Elledge kirkwood Sarah_Swierenga Mike DavidMacDonald
Regrets: sarah_horton Joshue Marc_Johlic James_Nurthen
Found Date: 02 Aug 2016
Guessing minutes URL: http://www.w3.org/2016/08/02-wai-wcag-minutes.html
People with action items: 

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