<Joshue108> https://www.w3.org/2002/09/wbs/35422/20160412_misc/

<Joshue108> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

<Joshue108> Scribenick: Alistair

<patrick_h_lauke> scribe: alastairc

Publishing new WCAG edited recommendation, with Makotos edit to 1.4.6

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

Joshue108: Had the call to publish, with edits from Makotos, generally favourably received.

Sidenote: Introduction from Rachael, new member of the working group on the call. Welcome!

Mike_Elledge thought that the use of the term 'section' could cause confusion in naming of 2.4.10, suggested to add some text to differentiate.

<Joshue108> https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-headings.html

<SarahHorton> Since the term "section" is defined I think we're okay

Joshue108: That could involve changes to the success criteria, which isn't really an editorial change.

<patrick_h_lauke> due to the tech agnostic nature of wcag, isn't it implied that this is not referring to <section> ?

Joshue108: Could you submit a pull request? Via github... could label it as a WCAG.next item.

<MichaelC> https://www.w3.org/WAI/WCAG20/comments/

Joshue108: Agree it's tech agnostic, still a terminology issue, but not a blocker.
... Any objection?

RESOLUTION: no objection to publishing new WCAG edited recommendation with Makotos edit

CFC to follow

One remaining item on survey

173

<Joshue108> https://github.com/w3c/wcag/issues/173

<Joshue108> AC: There was a long discussion on list.

<Joshue108> AC: I agree with the principle of the tech - but am struggling with how we describe failures.

<Joshue108> AC: They are absolutist.

<Joshue108> AC: Its then hard to apply this as a failure.

<Joshue108> AC: So I've changed my thinking, and liked the warning idea.

<Joshue108> AC: You could have bad practice etc, so a four point scale.

<Joshue108> JOC: So you've changed your thinking a little?

<Joshue108> AC: Yes, that I agree with the failure per see but its application as an absolute failure I dont like.

<patrick_h_lauke> https://github.com/w3c/wcag/issues/173#issuecomment-206625763

patrick_h_lauke: Circling around the problem of what failures are, this one opens the pandoras box. Can we turn it inside out and label it a good method for passing / best practice.

Due to the other issues hashed out on the mailing list, we have issues of what past failures are, changing previous results. Prefer the approach of showing good practices.

Joshue108: So you think this is an ok thing, but have reservations about the import of failures?

patrick: yes, so important that it is better to turn them into successes in the other way around.

Joshue108: seem to be a couple of camps, some people do use failures, some don't pay much attention to them, but see that they are quite absolutist.
... Even using the contrived examples we have to be careful.

davidmacdonald: There seem to be 2 conversations, failures in general, and this one. Twist them together, it's confusing to deal with.
... This is the first failure introduce for quite a while, so speaking to this one first. For pages that might be different, I think the failture text has addressed that.
... Gregg made a good point, it needs to have always been a failure, we should be just pointing to it. The language of 1.3.1 does indicate that in the SC. What we didn't have landmarks or HTML5 sectioning.
... What about the sites back then? I'd say it always was a failure, and without an easy solution we tended to ignore it.
... There could be a perception it is new, but don't think it actually is.
... I think I addressed the concerns, you'd have to be creative to get a false failure, that the language of the failure would be a problem compared to the WCAG text.
... We didn't enforce it before, but now it is easy to do.

<Joshue108> @Mike_elledge check out https://github.com/w3c/wcag/issues/173 as it also related to 2.4.10

davidmacdonald: The more general failure point, we have to understand that they are 'common failures', we don't document them all. If you don't do those things then it makes the testing easier.

<patrick_h_lauke> but to come right down to an example: look at https://github.com/w3c/wcag/issues/173#issuecomment-206625763 and the simple examples i provide - are we saying these ARE now failures from this point onwards? i.e. a simple visually distinct header that just contains an image, or a footer that just has some basic copyright notice, are now a hard fail of 1.3.1 because there's no landmarks?

Joshue108: Only concern I have is that it appears we have to mandate landmarks.

<patrick_h_lauke> or lack of headings, or any other programmatic or textual indication

<davidmacdonald> Ø "Failure of 1.3.1 due to visually distinct regions of a page (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text."

davidmacdonald: Don't think it does that, there is the 'by text' aspect.

<Zakim> MichaelC, you wanted to say I support the concept of calling techniques sufficient, advisory / best practices, warnings, failures and to say WCAG is success oriented but evaluators

davidmacdonald: We have positive techniques already.

<JF> +1 to Michael's point

MichaelC: Support the proposal of a warning level. Not convinced this is a candidate or not, but good idea. Note that WCAG is success oritented, you meet it by succeeding.
... However, tests tend to be failure oriented, so looking from that point of view can skew it.
... From a conformance point of view, conformance is dated, updated techniques do not invadlidate an old claim. You can say that conformed at the time, so that is ok.
... In this example: I agree it was always a failure, e.g. with headings/text. Now landmarks are a possible technique.
... We are not saying that the old conformance is invalid, but the testing may have been.

<Joshue108> -q

Ryladog_: We have multiple success criteria sufficient techniques, they change as technology changes. Why do we not also update and create failures? Not saying we need many new ones, but we do need those that are relevent to the technologies have come along.

<patrick_h_lauke> new technologies come along, but we can't have new failures for, effectively, NOT using new technologies

Ryladog_: Suggest we do use this failure, and include sufficient techniques. Need to continue to look at this as we add new technologies. Anything that is a specific common failure.

Joshue108: (mentions Patrick's comment)

Ryladog_: Agree with that, it is just the way we complete tasks has changed, and we can provide the success to.

JF: Micheal Cooper mentioned that the old conformance is invalid but the testing may have been. Pushing back, if the testing is invalid then the process was.
... Talking about a new tehnique, it is concerning that a common point made is "this is an easy fix". Agree that we want to improve content, but saying that something that would have passed 2 years ago, doesn't now is problematic.

<patrick_h_lauke> i believe it was mentioned on the list today, but: a failure would need to clearly show it fails ALL other possible ways to PASS the SC

MichealC: Distinction between a site that was conforming at the time but wasn't tested properly, and a site that did fail at the time.

<Joshue108> +1 to technology specific failures.

jnurthen: In the general sense, it would be easier to write new failures if they were tech specific. It can be so hard to write them across tech stacks, it has to fail for all. Would be easier if we weren't writing an anti-success critera.

<jon_avila_> we have 3 or 4 failures that do mention HTML in the name and are limited in scope to HTML

<jon_avila_> Many failures are written very similar to the success criteria

Wayne: Thinking about 1.3.1, been a blind-centric set of techniques. Also need to deal with the TFs that deal with groups missed before. Landmarks don't help non-screen reader audiences. Can't assume use of a screen reader.

<Zakim> MichaelC, you wanted to +1 technology-specific failures

<patrick_h_lauke> but 1.3.1 deals with conveying relationships THAT ARE ALREADY VISUALLY APPARENT programmatically or in text

<patrick_h_lauke> so sighted, non AT audience would already see those relationships?

MichaelC: Support idea of technology specific failures, we have that meta data in the source of the techniques, but it would be good to use it. We would quickly discover many new failures if we used it.

davidmacdonald: Failures are technology specific, e.g. F31, is HTML based. Table headers etc. tons of HTML specific failures.

MichealC: They are, but not presented that way.

Joshue108: Even if you were looking for tech-specific failures you couldn't find them.

Wayne: When we think about tech-specific, we don't realise the underlying thing is a document. E.g. apart from NAV, most docs have a header & footer, so these things are implemented by technology of fundamental communications objects, not sure we need tech specific stuff.

jnurthen: I'm talking about applications, not presented as writing.

JF: Not always a document there, e.g. google homepage. No header/footer, perhaps nav. Doesn't follow doc structure. Uver app on phone is another example, but an HTML/CSS/JS version wouldn't use a document format either.
... Not everything is a page.
... One concern here is, are we looking to make these failure techniques have the weight of a normative requirement? It feels that way.

Joshue108: They have a quasi-normative status.

MichealC: They are not normative, but we treat them as normative as we ahve to be careful.

JF: So we know that, how do we tell others?

Joshue108: That's why we have to be 100% sure it is a real failure.

<Joshue108> AC: I got the impression that failures are same accross all technologies? How to we square that accross multiple technologies?

<Joshue108> AC: If you have a HTML tech that passes, and an ARIA tech does that mean you cannot have a failure tech for that SC?

<Joshue108> MC: Yes, you can.

<Joshue108> <discussion>

<patrick_h_lauke> if WE (within the WG) can't quite agree/understand what a failure is (normative, non-normative, across all techs, absolutist or not, etc) then what hope do we have for joe developer on the street to understand this?

<JF> I think part of the problem is that we have specfic techniques, but we want to capture "common" failures - the difference between specificity and common is also part of the problem

<patrick_h_lauke> i still tend towards showing positives and successes, rather than failures

<SarahHorton> +1

davidmacdonald: Summarising - we're doing a 2.1 / WCAG.next. Failures are in WCAG 2, and their role is clear there. In re-thinking that, it sounds like a WCAG 3 issue, not a 2.1 issue. I would argue we aren't documenting enough failures.

<JF> +1

davidmacdonald: Want to make sure people with disabilities need representing, and we really need to think about what WCAG 2 was for when created. Agree with need due caution, but I think this failure can stand the criteria for failures.

<Zakim> MichaelC, you wanted to say we can address perception by messaging, rather than simply decline to do things; and we need to take full advantage of the opportunity to divide things

<patrick_h_lauke> +1 active vs passive failures distinction

MichealC: we have active failures, e.g. flashing on the screen. Passive failures are you didn't do something that was needed. That's harder to make absolute by tech, e.g. you could fail ARIA but pass HTML
... regarding perception, we do need to tackle how we talk about this to the world, but that shouldn't stop us acting, adding things.

<Ryladog_> +1 strongly to what MC is saying

MichealC: We have work going on with future guidelines, so we should separate out what is needed for WCAG 2 support materials, but also how can we structure things in future? Things we can address better.

<Zakim> Joshue, you wanted to say that is AT support and issue here? ARIA is very SR specific, do failures have to hit more bases?

Joshue108: Regarding the screen-reader specific nature of some areas, failures should help multiple user groups.
... A little on fence, would rather see positive patterns, but if the group would like more failures then we can go that way.
... In future, some good ideas. Grouping by technology, having a warning category.
... Cautious about getting this particular failure out the gate, what do people think?

Wayne: In WCAG 2.0, when getting it done, was hard because some things are difficult to fix and that made it harder to fail them.
... Maybe change approach?

jnurthen: Would have to look at conformance model, would be hard in current model.

Wayne: The 200% enlargment for example, that limit was due to difficulty, but today we can. Now 700% is not too hard. things that were too difficult are not anymore.

JF: Appreciate David's work making it agnostic. Still appears to promot landmark regions, difficult to shake that perception. Are all those ARIA roles being used?
... If a page lacked header/footer would it fail?

<jon_avila_> I agree with John

JF: Have a concern about the slicing & dicing. Happy with best practice approach, but turning it around to a failure is where we get into problems.
... Could take every success technique and turn those around to failures.
... Now we have a good technique that delivers on the SC, that's great. But to turn around and say you fail without it, seems to change intent.

patrick_h_lauke: In the wording, it started with landmarks/HTML5 elements, but includes identified by text. I'm not completely swayed, because there are many situations where a visually distinct area wouldn't fail from not having a identifier (text or landmark).

<jon_avila_> I agree -- that's because the text in the footer itself indicates it's a footer -- it's clear according to gregg

<Joshue108> +1 to Patrick

<JF> +1 to Patrick

patrick_h_lauke: The context can tell people about things like footers as well. I wouldn't necessarily fail some things that appear to fail in the wording.
... Certain aspect of leeway, which has already been in 1.3.1 where auditor has to use best judgement that is the case. Adding something for that would help get my support.

Joshue108: There can be visually distinct areas that are not functionally useful, so difficult to justify that is a failure.

<jon_avila_> I also have concerns of nav -- what makes a group of link a navigation group? What if color isn't used -- the fact that link are next to each other simply indicates they are related and that same info is availble to users with screen reader

mike: I started with David's recommendation, but I've been swayed that it would cause some retrofitting, so suggest it is moved to wcag.next.

davidmacdonald: regarding 'false positives', trivial information in visually distinct areas, I could take an action to re-word some area.

Joshue108: I struggle a bit with 'visually distinct', and how we connect user-need with the semantics we have. On one level it is fine, but implications are fairly far-reaching.

jnurthen: When writing, have to be careful not to make people use them when not needed, can be overwhelming, so need to be very careful.

<davidmacdonald> +1

Joshue108: Can we keep this open, tweak it a bit?

RESOLUTION: Leave open

davidmacdonald: Can we use some language to put in safety mechanisms to prevent problems.

<Wayne> +1

<Joshue108> ACTION: David to work on fine tuning 173 [recorded in http://www.w3.org/2016/05/03-wai-wcag-minutes.html#action01]

<trackbot> 'David' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dmacdona, dsloan).

<Joshue108> ACTION: davidmacdonald to work on fine tuning 173 [recorded in http://www.w3.org/2016/05/03-wai-wcag-minutes.html#action02]

<trackbot> Error finding 'davidmacdonald'. You can review and register nicknames at <http://www.w3.org/WAI/GL/track/users>.

Touch feedback.

Kathy: Mobile accessibility task force - been working on touch & pointers.
... at a point where we would like to get some feedback on requirements for touch & pointer, so we don't go down the wrong path.

<Kathy> https://w3c.github.io/Mobile-A11y-Extension/touch.html

Kathy: Got new guidelines, with 4 SCs.

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Main_Page

<Kathy> • Summary of Research on Touch/Pointer Target Size

Kathy: Put together wiki page on discussions, backgrond info.

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Summary_of_Research_on_Touch/Pointer_Target_Size

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/HISTORY:_Touch_and_Pointer

Kathy: Looking for feedback from the working group, difficult as we aren't sure where it is going to fit (extention vs WCAG 2.1), but there are two discussions, and the first is whether the gudelines and SCs are good.
... later discussion is where/how it would fit.

Joshue108: We will discuss on separate call soon.

AWK: Can create a survey to focus people. Can make it public, with separate questions per SC.

Kathy: can also comment on github.

<SarahHorton> Thanks, all, bye!

<laura> bye

trackbot, end meeting

<Mike_Elledge> Bye all!

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/Rochel/Rachael/
Succeeded: s/waht/what/
Found ScribeNick: Alistair
Found Scribe: alastairc
Inferring ScribeNick: alastairc
WARNING: No scribe lines found matching previous ScribeNick pattern: <Alistair> ...
ScribeNicks: Alistair, alastairc
Default Present: AWK, EricE, Kathy, Laura, jeanne, KimD, alastairc, JF, Joshue108, John_Kirkpwood, SarahH, Makoto, David_MacDonald, Mike_Elledge, John_Kirkwood, Greg_Lowney, kirkwood, MichaelC, Katie, Haritos-Shea, patrick_h_lauke, Elledge, MacDonald, Katie_Haritos-Shea, wayne, jon_avila
Present: AWK EricE Kathy Laura jeanne KimD alastairc JF Joshue108 SarahH Makoto David_MacDonald Mike_Elledge Greg_Lowney kirkwood MichaelC Katie Haritos-Shea Mike Elledge David MacDonald Katie_Haritos-Shea wayne jon_avila
Regrets: EricE
Found Date: 03 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/03-wai-wcag-minutes.html
People with action items: david davidmacdonald

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