Will there be any failure techniques for WCAG 2.1?

[DavidMacDonald]

Only 3 common failures have been added since 2008, and nearly 100 techniques have been added. There have been plenty of proposals.

If we decide against common failures that's one thing, but if failure techniques are desirable then perhaps we need a new process for getting them approved that doesn't rely on the same process which is not allowing them.

[mbgower]

Failure techniques are very desirable. They are really the only thing that constitute a de facto way to demonstrate someone is not meeting WCAG. All the language around Sufficient techniques just being examples of one way to achieve something allows the STs to have a lower threshold. In my experience, being able to point to a failure is sometimes the only way to get stubborn teams to admit they have an issue. So I'm on board with a better process to allow them.

[goodwitch]

+1 I support failure techniques as necessary. I actual prefer that each new SC have a failure technique. If we can't all agree on at least one failure technique for each new SC, we aren't moving accessibility forward as much as we should.

Glenda

glenda sims | team a11y lead | deque.com | 512.963.3773 web for everyone. web on everything. - w3 goals

[image: IAAP International Association of Accessibility Professionals: Certified Professional in Accessibility Core Competencies (CPACC)] http://www.accessibilityassociation.org/certification

On Thu, Sep 21, 2017 at 12:45 PM, Mike Gower notifications@github.com wrote:

Failure techniques are very desirable. They are really the only thing that constitute a de facto way to demonstrate someone is not meeting WCAG. All the language around Sufficient techniques just being examples of one way to achieve something allows the SCs to have a lower threshold. In my experience, being able to point to a failure is sometimes the only way to get stubborn teams to admit they have an issue. So I'm on board with a better process to allow them.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331230493, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0uWhw6pGBmfZZEVuJOkHsFufZ0KsCxks5skqCcgaJpZM4PfqPS .

[eadraffan]

+1 to supporting failure techniques as necessary as well for all the reasons given

Best wishes

E.A.

Nigel & E.A. Draffan

The Old Rectory, Rackham,

Pulborough, West Sussex

RH20 2EU

07976 289103

From: Glenda Sims [mailto:notifications@github.com] Sent: 21 September 2017 20:40 To: w3c/wcag21 wcag21@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [w3c/wcag21] Will there be any failure techniques for WCAG 2.1? (#392)

+1 I support failure techniques as necessary. I actual prefer that each new SC have a failure technique. If we can't all agree on at least one failure technique for each new SC, we aren't moving accessibility forward as much as we should.

Glenda

glenda sims | team a11y lead | deque.com | 512.963.3773 web for everyone. web on everything. - w3 goals

[image: IAAP International Association of Accessibility Professionals: Certified Professional in Accessibility Core Competencies (CPACC)] http://www.accessibilityassociation.org/certification

On Thu, Sep 21, 2017 at 12:45 PM, Mike Gower <notifications@github.com mailto:notifications@github.com > wrote:

Failure techniques are very desirable. They are really the only thing that constitute a de facto way to demonstrate someone is not meeting WCAG. All the language around Sufficient techniques just being examples of one way to achieve something allows the SCs to have a lower threshold. In my experience, being able to point to a failure is sometimes the only way to get stubborn teams to admit they have an issue. So I'm on board with a better process to allow them.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331230493, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0uWhw6pGBmfZZEVuJOkHsFufZ0KsCxks5skqCcgaJpZM4PfqPS .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331260019 , or mute the thread https://github.com/notifications/unsubscribe-auth/AAtX3Ik03b7GDkiSrOYWjhegSnfrAB2pks5skrtygaJpZM4PfqPS . https://github.com/notifications/beacon/AAtX3BBDuwSc1YdkbnSEjxN5tcabv8kYks5skrtygaJpZM4PfqPS.gif

[patrickhlauke]

failure techniques are fine in principle, but there needs to be agreement that the failure is indeed always a failure, under all situations/scenarios, of course.

[goodwitch]

Patrick,

Yes. I'm not encouraging a ton of failure techniques. And yes, a failure technique must always fail.

My point is...if we've written a new SC that we cannot write in reverse (and turn into at least one failure situation)...then why does the SC exist in the first place?

So, I'd like a goal of at least one failure technique for each new SC in WCAG 2.1.

glenda sims | team a11y lead | deque.com | 512.963.3773 web for everyone. web on everything. - w3 goals

[image: IAAP International Association of Accessibility Professionals: Certified Professional in Accessibility Core Competencies (CPACC)] http://www.accessibilityassociation.org/certification

On Thu, Sep 21, 2017 at 2:56 PM, Patrick H. Lauke notifications@github.com wrote:

failure techniques are fine in principle, but there needs to be agreement that the failure is indeed always a failure, under all situations/scenarios, of course.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331264188, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0uWkq4Y6QBsmZNx4v0_-j1Ob4S0BY8ks5skr98gaJpZM4PfqPS .

[eadraffan]

Patrick, I agree and that is the hard bit, but they really do help when sharing knowledge about WCAG with those new to the system.

Best wishes

E.A.

From: Patrick H. Lauke [mailto:notifications@github.com] Sent: 21 September 2017 20:57 To: w3c/wcag21 wcag21@noreply.github.com Cc: eadraffan ea@emptech.info; Comment comment@noreply.github.com Subject: Re: [w3c/wcag21] Will there be any failure techniques for WCAG 2.1? (#392)

failure techniques are fine in principle, but there needs to be agreement that the failure is indeed always a failure, under all situations/scenarios, of course.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331264188 , or mute the thread https://github.com/notifications/unsubscribe-auth/AAtX3FxK8B3YtX7HkArcTr6oLh1db3akks5skr95gaJpZM4PfqPS . https://github.com/notifications/beacon/AAtX3A67P5agQDwyq8cm76Rqj_4uDKEpks5skr95gaJpZM4PfqPS.gif

[patrickhlauke]

they really do help when sharing knowledge about WCAG with those new to the system

I'm not disputing that. But I'm making sure that we don't rush into making failure techniques that aren't bulletproof just because we strive to have at least one for each SC. If we can, great, and I'd fully approve indisputable failures to be documented.

[mbgower]

My point is...if we've written a new SC that we cannot write in reverse (and turn into at least one failure situation)...then why does the SC exist in the first place?

It's important to remember that a Sufficient Technique (ST) is one way of meeting a Success Criterion (SC). It does not follow that failing to use that ST means one has failed to meet the SC. And since failing to meet the SC is what must take place to have a failure technique, at the very least we are usually talking about a 1:M relationship.

As a basic example. I can use lots of techniques to label something programmatically, but failing to do any one of those does not necessarily constitute a failure of 1.3.1. Instead, the failures talk about specific wrong ways of doing Info and relationships for various technologies, such as F90: Failure of Success Criterion 1.3.1 for incorrectly associating table headers and content via the headers and id attributes. BTW, I would suggest the wording of this failure should really say "HTML table" to make it technology-specific. There would be very few failures that wouldn't need some kind of technology parametres defined.

[DavidMacDonald]

@patrickhlauke Yes common failure techniques should be common errors made by average authors. They should also always apply to the condition they are failing. I don't attribute those two factors as substantially affecting our current situation. After all, during WCAG 2 we were able to get 90 failures into WCAG 2 which have withstood the test of time. These have been fundamental for tool makers.

[patrickhlauke]

so what do you attribute the current impasse to? if failure techniques aren't forthcoming, then efforts need to be made to define some. if potential failure techniques are not being accepted on valid grounds - because people don't feel that they always indicate a clear failure, or don't do it unequivocally enough - then it would seem the failure techniques need to be refined. unless you're implying people are simply shooting down failure techniques to be contrary?

[Ryladog]

Clearly Failure Techniques are needed for 2.1 SC. And clearly I doubt we can achieve one per SC, but I like Glenda's goal.

If we keep in mind that all 3 kinds of Techniques do not need to be completed before launch, we will be in a better place to achieve some bulletproof ones.

Katie Haritos-Shea 703-371-5545

On Sep 21, 2017 9:08 PM, "David MacDonald" notifications@github.com wrote:

unless you're implying people are simply shooting down failure techniques to be contrary?

There is a stated public position by some (not you) that failure techniques should not be added in principle. I think we need to address this together and decide whether this is a viable position for the group or not. If the group decides that failure techniques are a valid way to manage some aspects of non-conformance, there should be a mechanism which enables the group to move through 1 or 2 sharp objections that have responses that make sense to others on the group.

Apart from that, each failure technique should stand on its own and should have a rigorous high bar. It should be something you and I and others continually put into our accessibility audit reports and we would like to see formalized.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331322746, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqyj5OD7f0avBdqmShpWQgFi2MzmJnks5skwifgaJpZM4PfqPS .

[johnfoliot]

Katie Haritos-Shea wrote:

Clearly Failure Techniques are needed for 2.1 SC.

"Clearly Failure Techniques are needed desired for 2.1 SC"

The lack of a Failure Technique for any given new SC should in no way impede a SC from advancing to Rec Status in WCAG 2.1

And clearly I doubt we

can achieve one per SC, but I like Glenda's goal.

+1, +1

If we keep in mind that all 3 kinds of Techniques do not need to be

completed before launch, we will be in a better place to achieve some bulletproof ones.

+1

In terms of prioritization, I think we should be currently focused on the Understanding documentation first (which thanks to the excellent work of the Task Forces is in very good draft status already), followed second by ensuring we have examples of Success Techniques (to serve to illustrate what we want, with examples of how), followed finally by Advisory / Failure Techniques as warranted.

That said, all 3 activities can occur concurrently and/or asynchronously, but given limited resources and tight timelines, I'm curious whether my prioritization proposal for the Working Group meets consensus?

JF

Katie Haritos-Shea 703-371-5545

On Sep 21, 2017 9:08 PM, "David MacDonald" <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

unless you're implying people are simply shooting down failure techniques to be contrary?

There is a stated public position by some (not you) that failure techniques should not be added in principle. I think we need to address this together and decide whether this is a viable position for the group or not. If the group decides that failure techniques are a valid way to manage some aspects of non-conformance, there should be a mechanism which enables the group to move through 1 or 2 sharp objections that have responses that make sense to others on the group.

Apart from that, each failure technique should stand on its own and should have a rigorous high bar. It should be something you and I and others continually put into our accessibility audit reports and we would like to see formalized.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331322746, or mute the thread https://github.com/notifications/unsubscribe-auth/ AFfqyj5OD7f0avBdqmShpWQgFi2MzmJnks5skwifgaJpZM4PfqPS .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331336689, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c-fHXaqM-Sntlp8mpyXJbLvNd6Biks5skyFegaJpZM4PfqPS .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[jake-abma]

+1 to @patrickhlauke

failure techniques are fine in principle, but there needs to be agreement that the failure is indeed always a failure, under all situations/scenarios, of course.

What I don’t get is why this issue is topical. I wasn’t around when 2.0 saw the light but it seems to me that failures speak for themselves and always need to be true before objective judgment. No questions there.

+1 to @goodwitch

If we can't all agree on at least one failure technique for each new SC, we aren't moving accessibility forward as much as we should.

It seems a bit strange if we can’t agree on at least one failure per SC. So why is there doubt on this?

@Ryladog

And clearly I doubt we can achieve one per SC, but I like Glenda's goal.

I do get questions when a SC has no failure present and also not having any answers for a case makes the SC (and WCAG) doubtful.

Maybe we need to explain the conditions for the failure but telling people we have a success criteria and not having a clear case for failing isn't that a fail on its own...

[jake-abma]

Failures are also very powerful for completing the understanding of the SC. Only telling people the intent and what they need to do to comply leaves plenty of room for self-interpretation of failures.

I would like to see even more effort in 2.1 for failures, if possible, just for making WCAG so much stronger to convince the stubborn of this World.

[patrickhlauke]

@jake-abma

What I don’t get is why this issue is topical. I wasn’t around when 2.0 saw the light but it seems to me that failures speak for themselves and always need to be true before objective judgment. No questions there.

this is in reference to the separate long discussions about making the lack of structural landmarks/roles (<header>, <main>, <nav>,<footer>, role="main", etc.) a failure technique for 1.3.1 in WCAG 2.1

[jake-abma]

@patrickhlauke thx, I did get that one... :-) but when we discuss a failure, just as we do with SC, they do or do not make it (just as JF gave proper feedback on that one) but this is just part of the process isn't it?!

The sentences...

Right now it appears we have a brick wall against new common failure techniques, in that our process requires consensus and there are vocal opponents to failure techniques in general.

...suggest there's another issue here in the group and that's new (at least for me)

[detlevhfischer]

Let me add my one centime. Even with existing hard-won failures there are grey areas when it comes to applying them. The nature of web content means it is impossible to enumerate all combinations of how markup is used or not used on content and that opens the door on different judgements. I pick nearly at random two examples from existing failures of 1.3.1 Info and Relationships, F2 and F43.

F2 kicks in when a heading is not marked up as heading, having a simple example of a heading marked up as <p> with CSS styling. Now picture a small section with an inline heading. This could well be marked up with a <hn> and set to display:inline. It may also just be marked up with <strong>, or even <b> for presentational effect. Would that be a failure? Where do you draw the line? Whatever you think, other evaluators will decide differently.

Second example, F43, which kicks in in the inverse case of structural mark-up used for stylistic reasons. Here, you also have grey areas. One example is Failure example 3 in that Failure technique, the use of <blockquote> used to indent some content. Hmm. It turns out that the paragraph in the example might indeed qualify as some sort of quotation (the capturing of a common problem). It may not be a good use but it is far, far from being a showstopper for the blind user, so it would be utterly petty and disproportionate to fail that page on that alone. But the thing is: it is documented in a failure. Even when the impact is close to nil, you can still feel entitled to fail the page.

So for me (who once believed in Failure techniques as just the thing we needed to nail it), I have changed my opinion. I find it a lot more important to assess the impact of violations when rating content, and I usually cannot get that from the failure technique. I need to consider the context. So I am not so sorry that we may not have so many new Failures for the new SCs. It is far, far more important to educate people by documenting good practices (sufficient techniques).

[johnfoliot]

+1 Detlev, especially:

It maybe not a good use but it is far, far from being a showstopper for the blind user, so it would be utterly petty and disproportionate to fail that page on that alone. But the thing is: it is documented in a failure. Even when the impact is close to nil, you can still feel entitled to fail the page.

(JF: Not only entitled, but per the ​ current​ Failure Techniques documentation it IS a Failure, entitlement aside, which is one of the underscoring concerns I have about Failure Techniques overall) J ​F​

On Fri, Sep 22, 2017 at 4:28 PM, Detlev Fischer notifications@github.com wrote:

Let me add my one centime. Even with existing hard-won failures there are grey areas when it comes to applying them. The nature of web content means it is impossible to enumerate all combinations of how markup is used or not used on content and that opens the door on different judgements. I pick nearly at random two examples from existing failures of 1.3.1 Info and Relationships, F2 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F2 and F43 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F43.

F2 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F2 kicks in when a heading is not marked up as heading, having a simple example of a heading marked up as p with CSS styling. Now picture a small section with an inline heading. This could well be marked up with a hn and set to display:inline. It may also just be marked up with strong, or even b for presentational effect. Would that be a failure? Where do you draw the line? Whatever you think, other evaluators will decide differently.

Second example, F43 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F43, which kicks in in the inverse case of structural mark-up used for stylistic reasons. Here, you also have grey areas. One example is Failure example 3 in that Failure technique, the use of block quote used to indent some content. Hmm. It turns out that the paragraph in the example might indeed qualify as some sort of quotation (the capturing of a common problem). It maybe not a good use but it is far, far from being a showstopper for the blind user, so it would be utterly petty and disproportionate to fail that page on that alone. But the thing is: it is documented in a failure. Even when the impact is close to nil, you can still feel entitled to fail the page.

So for me (who once believed in Failure techniques as just the thing we needed to nail it), I have changed my opinion. I find it a lot more important to assess the impact of violations when rating content, and I usually cannot get that from the failure technique. I need to consider the context. So I am not so sorry that we may not have so many new Failures for the new SCs. It is far, far more important to educate people by documenting good practices (sufficient techniques).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331552511, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c2yeo1qA5dfKfqKF3N2grngI79yUks5slBhkgaJpZM4PfqPS .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[Ryladog]

If others are going to repost their positions from other threads I will as well. I am not advocating for only Failure Techniques. We need both Sufficient and Failure techniques. But specifically I am advocating for this failure because it is good...

Does WCAG 2.0 require Headings be used for 1.3.1 for all pages? No. But if you have things that look like Headings, then they should be marked up as such programmatically. There is no SC that says use headings in WCAG 2.0 (nor should there be).

1.3.1 was meant to allow for new paradigms of interaction in new technologies.

Would this Failure require Regions be used for 1.3.1 for all pages? No. But if you have things that look like Regions, then they should be marked up as such programmatically. Under 1.3.1 in WCAG 2.1. There is no reason to have an SC that says you must use Regions in 2.1.

Should there also be a Sufficient Technique? Sure. That does not negate the usefulness of this proposed Failure. And I don't see where it invalidates anyone's 2.0 conformance claim...

This is simple and useful, and provides additional navigation schemes for AT.

Katie Haritos-Shea 703-371-5545

On Sep 22, 2017 4:28 PM, "Detlev Fischer" notifications@github.com wrote:

Let me add my one centime. Even with existing hard-won failures there are grey areas when it comes to applying them. The nature of web content means it is impossible to enumerate all combinations of how markup is used or not used on content and that opens the door on different judgements. I pick nearly at random two examples from existing failures of 1.3.1 Info and Relationships, F2 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F2 and F43 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F43.

F2 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F2 kicks in when a heading is not marked up as heading, having a simple example of a heading marked up as p with CSS styling. Now picture a small section with an inline heading. This could well be marked up with a hn and set to display:inline. It may also just be marked up with strong, or even b for presentational effect. Would that be a failure? Where do you draw the line? Whatever you think, other evaluators will decide differently.

Second example, F43 https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F43, which kicks in in the inverse case of structural mark-up used for stylistic reasons. Here, you also have grey areas. One example is Failure example 3 in that Failure technique, the use of block quote used to indent some content. Hmm. It turns out that the paragraph in the example might indeed qualify as some sort of quotation (the capturing of a common problem). It maybe not a good use but it is far, far from being a showstopper for the blind user, so it would be utterly petty and disproportionate to fail that page on that alone. But the thing is: it is documented in a failure. Even when the impact is close to nil, you can still feel entitled to fail the page.

So for me (who once believed in Failure techniques as just the thing we needed to nail it), I have changed my opinion. I find it a lot more important to assess the impact of violations when rating content, and I usually cannot get that from the failure technique. I need to consider the context. So I am not so sorry that we may not have so many new Failures for the new SCs. It is far, far more important to educate people by documenting good practices (sufficient techniques).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331552511, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqypyuFGEPAHs_cG5_Wqerj_IccUQNks5slBhmgaJpZM4PfqPS .

[detlevhfischer]

My main point is that content under test rarely matches examples exactly. There are many grey-area cases where the evaluator's judgement could go either way especially when you try to take into account impact / avoid to be petty. And even Failure Techniques are informative (I think the WG has stated - which upset me at the time - that there can be cases where Common Failures aren't failures, recognising that they weren't watertight after all or that new techniques might have come along that met SCs in spite of the described failure condition - too lazy to find the place where this is documented.)

[DavidMacDonald]

Are you saying WCAG is not testable?

I would say it is... However, it requires an accessibility professional.

I have a background in accounting... it is not much different. What about expenses that are written off against a business activity... is it used to generate income or not... sometimes there is judgement involved. One of the important things about being human and not a machine, is that judgement is core to proper functioning of society.

[Ryladog]

Sometimes it is a judgment call to fail a page for headings under 1.3.1 in WCAG 2.0. In such cases, where I work, I will have others look at the page to get their feedback to validate or invalidate my judgment call. It happens. That is OK.

Katie Haritos-Shea 703-371-5545

On Sep 23, 2017 6:54 AM, "David MacDonald" notifications@github.com wrote:

Are you saying WCAG in not testable?

I would say it is... However, it requires an accessibility professional.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/392#issuecomment-331626427, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqyjgj9zEkSH-Vxcc6nq5UY-7n7HVkks5slONqgaJpZM4PfqPS .

[awkawk]

Closing this as it doesn't impact the normative text of WCAG 2.1. If any failure techniques are suggested, the WG will consider them.