Failure Technique around page regions (Header, Footer, Nav, Main etc.)

[DavidMacDonald]

This is an issue originally filed as Issue #173 for WCAG 2. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members. It is intended for WCAG 2.1, not 2.0.

Text of the Failure Proposal

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text."

Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

• Content that is not distinct visually is not a failure
• Content that is not distinct in substance is not a failure
• Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

If the design visually indicates any of the following:

• header/banner
• footer/contentinfo
• navigation section
• complementary/aside
• search region
• main region which is visually different from other parts of the page

Then the absence of programmatic indications of those sections or a text description for those who cannot see would trigger the failure.

Failure Procedure

Examine the page to confirm there are regions that are visually distinct which identify any of the following and contain distinct content: header/banner, footer/contentinfo, navigation section, complementary/aside, search region, main region, then check each region to confirm:

1. It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR
2. The sections are identified by text, ("Header, Footer, Navigation etc.")

If #2 and #3 are false then this failure condition applies.

Related Techniques

• Using Landmarks
• Using HTML5 section elements
• Using headings to identify regions of a page
• Using text to identify regions of a page.

This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

[johnfoliot]

Hi David,

I'm sorry, but this is and will remain the same problem as when you first proposed it - we cannot retroactively introduce conditions that invalidates content that previously met the SC conformance in WCAG 2.0, which is what is happening here.

Additionally, the current draft text has dependencies on two other draft SC, making this a fragile house of cards way before its time. Question: how do you "measure" the following:

• Content that is not distinct in substance is not a failure

Where is the definition of "distinct in substance" (and distinct according to whom?)

This is, and continues to appear to be, an attempt to redefine the normative text of WCAG 2.0 by introducing additional constraints or conditions (or else it fails). I can support a Success Technique that promotes the use of landmark roles or landmark elements (which we already have), but there is a difference between that and saying that if you don't use either (or are prepared to argue that none of the page content is "distinct in substance" - whatever that means), you are "failing" what is an already broad and complex SC.

This also does not speak to technology agnostic issues: how does this factor with PDFs for example? SVG?

While you suggest this has "good momentum" (support), I will counter with the fact that it has received significant and strong pushback in the past as well. I will continue to strongly oppose this as related to SC 1.3.1, as I am sure others will as well.

JF

On Fri, Jul 21, 2017 at 11:58 AM, David MacDonald notifications@github.com wrote:

This is an issue originally filed as Issue #173 for WCAG 2 https://github.com/w3c/wcag/issues/173. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members.

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text." Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

• Content that is not distinct visually is not a failure
• Content that is not distinct in substance is not a failure
• Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

Failure Procedure

Examine the page to confirm there are regions that are visually distinct and contain distinct content. Check each region to confirm:

1.

• It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR 2.
• The sections are identified by text, ("Header, Footer, Navigation etc.")

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies. Related Techniques

• Using Landmarks
• Using HTML5 section elements
• Using headings to identify regions of a page
• Using text to identify regions of a page.

This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

— 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/310, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ .

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

Advancing the mission of digital accessibility and inclusion

[Ryladog]

David,

I would love to see this Failure Technique added, as I did when it was first shot down.

JF this doesn't rely on any new proposed SC as far as I can tell, and in no way does it invalidate anything.

This is about Techniques, which have nothing to do with conformance, and everything to do with providing ways to meet or fail SCs as new technologies come online.

Katie Haritos-Shea 703-371-5545

On Jul 21, 2017 2:16 PM, "John Foliot" notifications@github.com wrote:

Hi David,

I'm sorry, but this is and will remain the same problem as when you first proposed it - we cannot retroactively introduce conditions that invalidates content that previously met the SC conformance in WCAG 2.0, which is what is happening here.

Additionally, the current draft text has dependencies on two other draft SC, making this a fragile house of cards way before its time. Question: how do you "measure" the following:

• Content that is not distinct in substance is not a failure

Where is the definition of "distinct in substance" (and distinct according to whom?)

This is, and continues to appear to be, an attempt to redefine the normative text of WCAG 2.0 by introducing additional constraints or conditions (or else it fails). I can support a Success Technique that promotes the use of landmark roles or landmark elements (which we already have), but there is a difference between that and saying that if you don't use either (or are prepared to argue that none of the page content is "distinct in substance" - whatever that means), you are "failing" what is an already broad and complex SC.

This also does not speak to technology agnostic issues: how does this factor with PDFs for example? SVG?

While you suggest this has "good momentum" (support), I will counter with the fact that it has received significant and strong pushback in the past as well. I will continue to strongly oppose this as related to SC 1.3.1, as I am sure others will as well.

JF

On Fri, Jul 21, 2017 at 11:58 AM, David MacDonald < notifications@github.com> wrote:

This is an issue originally filed as Issue #173 for WCAG 2 https://github.com/w3c/wcag/issues/173. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members.

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text." Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

• Content that is not distinct visually is not a failure
• Content that is not distinct in substance is not a failure
• Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

Failure Procedure

Examine the page to confirm there are regions that are visually distinct and contain distinct content. Check each region to confirm:

1.

• It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR 2.
• The sections are identified by text, ("Header, Footer, Navigation etc.")

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies. Related Techniques

• Using Landmarks
• Using HTML5 section elements
• Using headings to identify regions of a page
• Using text to identify regions of a page.

This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

— 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/310, or mute the thread https://github.com/notifications/unsubscribe- auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ .

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

Advancing the mission of digital accessibility and inclusion

— 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/310#issuecomment-317074778, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ .

[Ryladog]

Additionally JF, to your question "This also does not speak to technology agnostic issues: how does this factor with PDFs for example? SVG?"

Techniques are designed to be technology specific. SCs are designed to be technology agnostic.

Katie Haritos-Shea 703-371-5545

On Jul 21, 2017 3:39 PM, "Katie Haritos-Shea" ryladog@gmail.com wrote:

David,

I would love to see this Failure Technique added, as I did when it was first shot down.

JF this doesn't rely on any new proposed SC as far as I can tell, and in no way does it invalidate anything.

This is about Techniques, which have nothing to do with conformance, and everything to do with providing ways to meet or fail SCs as new technologies come online.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Jul 21, 2017 2:16 PM, "John Foliot" notifications@github.com wrote:

Hi David,

I'm sorry, but this is and will remain the same problem as when you first proposed it - we cannot retroactively introduce conditions that invalidates content that previously met the SC conformance in WCAG 2.0, which is what is happening here.

Additionally, the current draft text has dependencies on two other draft SC, making this a fragile house of cards way before its time. Question: how do you "measure" the following:

• Content that is not distinct in substance is not a failure

Where is the definition of "distinct in substance" (and distinct according to whom?)

This is, and continues to appear to be, an attempt to redefine the normative text of WCAG 2.0 by introducing additional constraints or conditions (or else it fails). I can support a Success Technique that promotes the use of landmark roles or landmark elements (which we already have), but there is a difference between that and saying that if you don't use either (or are prepared to argue that none of the page content is "distinct in substance" - whatever that means), you are "failing" what is an already broad and complex SC.

This also does not speak to technology agnostic issues: how does this factor with PDFs for example? SVG?

While you suggest this has "good momentum" (support), I will counter with the fact that it has received significant and strong pushback in the past as well. I will continue to strongly oppose this as related to SC 1.3.1, as I am sure others will as well.

JF

On Fri, Jul 21, 2017 at 11:58 AM, David MacDonald < notifications@github.com> wrote:

This is an issue originally filed as Issue #173 for WCAG 2 https://github.com/w3c/wcag/issues/173. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members.

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text." Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

• Content that is not distinct visually is not a failure
• Content that is not distinct in substance is not a failure
• Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

Failure Procedure

Examine the page to confirm there are regions that are visually distinct and contain distinct content. Check each region to confirm:

1.

• It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR 2.
• The sections are identified by text, ("Header, Footer, Navigation etc.")

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies. Related Techniques

• Using Landmarks
• Using HTML5 section elements
• Using headings to identify regions of a page
• Using text to identify regions of a page.

This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

— 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/310, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK- czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ .

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

Advancing the mission of digital accessibility and inclusion

— 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/310#issuecomment-317074778, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ .

[KerstinProbiesch]

Thanks for bringing this up again. I would like to see such a failure technique for 1.3.1 WCAG 2.0.

I think "distinct visually" would need some work to adress the case where the visually distinction is by colour alone. And I think also "region" needs some work.

For example:

A page contains a footer (with the correct landmark or the HTML5-element or hidden heading or whatever) with two sub-sections. In each sub-section (sub region?) a contact-information is given. One sub-section has a dark blue background, the other sub-section has a grey, or red oder whatever background. The first one gives contact-information about the overall organization (a college, a medical center or...) and the second one gives contact-information about the specific sub-"organization" (a department, a institute). For the overall organization a specific colour is used (here the dark blue) for every sub-"organization" also a specific colour is used and no headings are given for the sub sections.

I believe that one would pass 1.3.1 (because the region itself is made clear) but would be a failure for 1.4.1 because the visually distinction of the sub-section (sub-region?) relies on colour alone.

If there is no text information for the two different contact-information-types which is visible for all users just a hidden text information (hidden heading for example) or an aria-label this would not pass 1.4.1. Or?

Probably two failures are needed: one which addresses the region itself for 1.3.1. And another one which addresses the case where a region has sub-regions and the visually distinction is by colour alone (1.4.1).

[johnfoliot]

Hi Katie,

Respectfully, if you read David's new proposal it directly references two new "issues" (proposed new SC):

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies.

2 = New SC Proposal: Programmatic notification is provided for each change

in content that indicates an action was taken or that conveys information

3 = New SC proposal: After initial page load, programmatic notification is

provided for each visual indicator that content is loading or the page is busy.

This proposal (or, rather, an earlier variant of the proposal) did not achieve consensus the first time around, and while David is welcome to bring it forward again, his proposal still does not address the reasons why this Failure Technique was ultimately rejected the last time.

JF

On Fri, Jul 21, 2017 at 2:39 PM, Katie Haritos-Shea < notifications@github.com> wrote:

David,

I would love to see this Failure Technique added, as I did when it was first shot down.

JF this doesn't rely on any new proposed SC as far as I can tell, and in no way does it invalidate anything.

This is about Techniques, which have nothing to do with conformance, and everything to do with providing ways to meet or fail SCs as new technologies come online.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Jul 21, 2017 2:16 PM, "John Foliot" notifications@github.com wrote:

Hi David,

I'm sorry, but this is and will remain the same problem as when you first proposed it - we cannot retroactively introduce conditions that invalidates content that previously met the SC conformance in WCAG 2.0, which is what is happening here.

Additionally, the current draft text has dependencies on two other draft SC, making this a fragile house of cards way before its time. Question: how do you "measure" the following:

• Content that is not distinct in substance is not a failure

Where is the definition of "distinct in substance" (and distinct according to whom?)

This is, and continues to appear to be, an attempt to redefine the normative text of WCAG 2.0 by introducing additional constraints or conditions (or else it fails). I can support a Success Technique that promotes the use of landmark roles or landmark elements (which we already have), but there is a difference between that and saying that if you don't use either (or are prepared to argue that none of the page content is "distinct in substance" - whatever that means), you are "failing" what is an already broad and complex SC.

This also does not speak to technology agnostic issues: how does this factor with PDFs for example? SVG?

While you suggest this has "good momentum" (support), I will counter with the fact that it has received significant and strong pushback in the past as well. I will continue to strongly oppose this as related to SC 1.3.1, as I am sure others will as well.

JF

On Fri, Jul 21, 2017 at 11:58 AM, David MacDonald < notifications@github.com> wrote:

This is an issue originally filed as Issue #173 for WCAG 2 https://github.com/w3c/wcag/issues/173. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members.

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text." Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

• Content that is not distinct visually is not a failure
• Content that is not distinct in substance is not a failure
• Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

Failure Procedure

Examine the page to confirm there are regions that are visually distinct and contain distinct content. Check each region to confirm:

1.

• It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR 2.
• The sections are identified by text, ("Header, Footer, Navigation etc.")

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies. Related Techniques

• Using Landmarks
• Using HTML5 section elements
• Using headings to identify regions of a page
• Using text to identify regions of a page.

This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

— 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/310, or mute the thread https://github.com/notifications/unsubscribe- auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ .

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

Advancing the mission of digital accessibility and inclusion

— 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/310#issuecomment-317074778, or mute the thread https://github.com/notifications/unsubscribe-auth/ AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ .

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

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

Advancing the mission of digital accessibility and inclusion

[Ryladog]

JF,

This was originally designed to be a Failure Technique of 1.3.1, I think (or maybe also 2.4.1).

Why exactly is it that "his proposal still does not address the reasons why this Failure Technique was ultimately rejected the last time".?

Hopefully not the irrelevant "technology-agnostic" argument...

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Jul 22, 2017 10:18 AM, "John Foliot" notifications@github.com wrote:

Hi Katie,

Respectfully, if you read David's new proposal it directly references two new "issues" (proposed new SC):

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies.

2 = New SC Proposal: Programmatic notification is provided for each change

in content that indicates an action was taken or that conveys information

3 = New SC proposal: After initial page load, programmatic notification is

provided for each visual indicator that content is loading or the page is busy.

This proposal (or, rather, an earlier variant of the proposal) did not achieve consensus the first time around, and while David is welcome to bring it forward again, his proposal still does not address the reasons why this Failure Technique was ultimately rejected the last time.

JF

On Fri, Jul 21, 2017 at 2:39 PM, Katie Haritos-Shea < notifications@github.com> wrote:

David,

I would love to see this Failure Technique added, as I did when it was first shot down.

JF this doesn't rely on any new proposed SC as far as I can tell, and in no way does it invalidate anything.

This is about Techniques, which have nothing to do with conformance, and everything to do with providing ways to meet or fail SCs as new technologies come online.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545>

On Jul 21, 2017 2:16 PM, "John Foliot" notifications@github.com wrote:

Hi David,

I'm sorry, but this is and will remain the same problem as when you first proposed it - we cannot retroactively introduce conditions that invalidates content that previously met the SC conformance in WCAG 2.0, which is what is happening here.

Additionally, the current draft text has dependencies on two other draft SC, making this a fragile house of cards way before its time. Question: how do you "measure" the following:

• Content that is not distinct in substance is not a failure

Where is the definition of "distinct in substance" (and distinct according to whom?)

This is, and continues to appear to be, an attempt to redefine the normative text of WCAG 2.0 by introducing additional constraints or conditions (or else it fails). I can support a Success Technique that promotes the use of landmark roles or landmark elements (which we already have), but there is a difference between that and saying that if you don't use either (or are prepared to argue that none of the page content is "distinct in substance" - whatever that means), you are "failing" what is an already broad and complex SC.

This also does not speak to technology agnostic issues: how does this factor with PDFs for example? SVG?

While you suggest this has "good momentum" (support), I will counter with the fact that it has received significant and strong pushback in the past as well. I will continue to strongly oppose this as related to SC 1.3.1, as I am sure others will as well.

JF

On Fri, Jul 21, 2017 at 11:58 AM, David MacDonald < notifications@github.com> wrote:

This is an issue originally filed as Issue #173 for WCAG 2 https://github.com/w3c/wcag/issues/173. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members.

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text." Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

• Content that is not distinct visually is not a failure
• Content that is not distinct in substance is not a failure
• Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

Failure Procedure

Examine the page to confirm there are regions that are visually distinct and contain distinct content. Check each region to confirm:

1.

• It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR 2.
• The sections are identified by text, ("Header, Footer, Navigation etc.")

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies. Related Techniques

• Using Landmarks
• Using HTML5 section elements
• Using headings to identify regions of a page
• Using text to identify regions of a page.

This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

— 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/310, or mute the thread https://github.com/notifications/unsubscribe- auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ .

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

Advancing the mission of digital accessibility and inclusion

— 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/310#issuecomment-317074778, or mute the thread https://github.com/notifications/unsubscribe-auth/ AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ .

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

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

Advancing the mission of digital accessibility and inclusion

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

[patrickhlauke]

From memory, I don't believe we reached consensus that the failure is categorically always a failure.

-- Patrick H. Lauke

On 22 Jul 2017, at 19:40, Katie Haritos-Shea notifications@github.com wrote:

JF,

This was originally designed to be a Failure Technique of 1.3.1, I think (or maybe also 2.4.1).

Why exactly is it that "his proposal still does not address the reasons why this Failure Technique was ultimately rejected the last time".?

Hopefully not the irrelevant "technology-agnostic" argument...

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Jul 22, 2017 10:18 AM, "John Foliot" notifications@github.com wrote:

Hi Katie,

Respectfully, if you read David's new proposal it directly references two new "issues" (proposed new SC):

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies.

2 = New SC Proposal: Programmatic notification is provided for each change

in content that indicates an action was taken or that conveys information

3 = New SC proposal: After initial page load, programmatic notification is

provided for each visual indicator that content is loading or the page is busy.

This proposal (or, rather, an earlier variant of the proposal) did not achieve consensus the first time around, and while David is welcome to bring it forward again, his proposal still does not address the reasons why this Failure Technique was ultimately rejected the last time.

JF

On Fri, Jul 21, 2017 at 2:39 PM, Katie Haritos-Shea < notifications@github.com> wrote:

David,

I would love to see this Failure Technique added, as I did when it was first shot down.

JF this doesn't rely on any new proposed SC as far as I can tell, and in no way does it invalidate anything.

This is about Techniques, which have nothing to do with conformance, and everything to do with providing ways to meet or fail SCs as new technologies come online.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545>

On Jul 21, 2017 2:16 PM, "John Foliot" notifications@github.com wrote:

Hi David,

I'm sorry, but this is and will remain the same problem as when you first proposed it - we cannot retroactively introduce conditions that invalidates content that previously met the SC conformance in WCAG 2.0, which is what is happening here.

Additionally, the current draft text has dependencies on two other draft SC, making this a fragile house of cards way before its time. Question: how do you "measure" the following:

• Content that is not distinct in substance is not a failure

Where is the definition of "distinct in substance" (and distinct according to whom?)

This is, and continues to appear to be, an attempt to redefine the normative text of WCAG 2.0 by introducing additional constraints or conditions (or else it fails). I can support a Success Technique that promotes the use of landmark roles or landmark elements (which we already have), but there is a difference between that and saying that if you don't use either (or are prepared to argue that none of the page content is "distinct in substance" - whatever that means), you are "failing" what is an already broad and complex SC.

This also does not speak to technology agnostic issues: how does this factor with PDFs for example? SVG?

While you suggest this has "good momentum" (support), I will counter with the fact that it has received significant and strong pushback in the past as well. I will continue to strongly oppose this as related to SC 1.3.1, as I am sure others will as well.

JF

On Fri, Jul 21, 2017 at 11:58 AM, David MacDonald < notifications@github.com> wrote:

This is an issue originally filed as Issue #173 for WCAG 2 https://github.com/w3c/wcag/issues/173. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members.

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text." Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

• Content that is not distinct visually is not a failure
• Content that is not distinct in substance is not a failure
• Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

Failure Procedure

Examine the page to confirm there are regions that are visually distinct and contain distinct content. Check each region to confirm:

1.

• It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR 2.
• The sections are identified by text, ("Header, Footer, Navigation etc.")

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies. Related Techniques

• Using Landmarks
• Using HTML5 section elements
• Using headings to identify regions of a page
• Using text to identify regions of a page.

This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

— 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/310, or mute the thread https://github.com/notifications/unsubscribe- auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ .

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

Advancing the mission of digital accessibility and inclusion

— 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/310#issuecomment-317074778, or mute the thread https://github.com/notifications/unsubscribe-auth/ AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ .

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

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

Advancing the mission of digital accessibility and inclusion

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Ryladog]

There are issues with this proposed failure as is, such as needing to add more generic language for documents, etc. But it has a solid basis for a failure.

I too suggest we table this until after 2.1. We will have more time then - and by then - more people on the WG will have experience with crafting solid standards language and may be willing to put the diligent thought and well-intentioned work into proper crafting - rather than merely shooting down great ideas!

Katie Haritos-Shea 703-371-5545

On Jul 23, 2017 3:49 AM, "Patrick H. Lauke" notifications@github.com wrote:

From memory, I don't believe we reached consensus that the failure is categorically always a failure.

-- Patrick H. Lauke

On 22 Jul 2017, at 19:40, Katie Haritos-Shea notifications@github.com wrote:

JF,

This was originally designed to be a Failure Technique of 1.3.1, I think (or maybe also 2.4.1).

Why exactly is it that "his proposal still does not address the reasons why this Failure Technique was ultimately rejected the last time".?

Hopefully not the irrelevant "technology-agnostic" argument...

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545>

On Jul 22, 2017 10:18 AM, "John Foliot" notifications@github.com wrote:

Hi Katie,

Respectfully, if you read David's new proposal it directly references two new "issues" (proposed new SC):

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies.

2 = New SC Proposal: Programmatic notification is provided for each

change in content that indicates an action was taken or that conveys information

3 = New SC proposal: After initial page load, programmatic

notification is provided for each visual indicator that content is loading or the page is busy.

This proposal (or, rather, an earlier variant of the proposal) did not achieve consensus the first time around, and while David is welcome to bring it forward again, his proposal still does not address the reasons why this Failure Technique was ultimately rejected the last time.

JF

On Fri, Jul 21, 2017 at 2:39 PM, Katie Haritos-Shea < notifications@github.com> wrote:

David,

I would love to see this Failure Technique added, as I did when it was first shot down.

JF this doesn't rely on any new proposed SC as far as I can tell, and in no way does it invalidate anything.

This is about Techniques, which have nothing to do with conformance, and everything to do with providing ways to meet or fail SCs as new technologies come online.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

On Jul 21, 2017 2:16 PM, "John Foliot" notifications@github.com wrote:

Hi David,

I'm sorry, but this is and will remain the same problem as when you first proposed it - we cannot retroactively introduce conditions that invalidates content that previously met the SC conformance in WCAG 2.0, which is what is happening here.

Additionally, the current draft text has dependencies on two other draft SC, making this a fragile house of cards way before its time. Question: how do you "measure" the following:

• Content that is not distinct in substance is not a failure

Where is the definition of "distinct in substance" (and distinct according to whom?)

This is, and continues to appear to be, an attempt to redefine the normative text of WCAG 2.0 by introducing additional constraints or conditions (or else it fails). I can support a Success Technique that promotes the use of landmark roles or landmark elements (which we already have), but there is a difference between that and saying that if you don't use either (or are prepared to argue that none of the page content is "distinct in substance" - whatever that means), you are "failing" what is an already broad and complex SC.

This also does not speak to technology agnostic issues: how does this factor with PDFs for example? SVG?

While you suggest this has "good momentum" (support), I will counter with the fact that it has received significant and strong pushback in the past as well. I will continue to strongly oppose this as related to SC 1.3.1, as I am sure others will as well.

JF

On Fri, Jul 21, 2017 at 11:58 AM, David MacDonald < notifications@github.com> wrote:

This is an issue originally filed as Issue #173 for WCAG 2 https://github.com/w3c/wcag/issues/173. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members.

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text." Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

• Content that is not distinct visually is not a failure
• Content that is not distinct in substance is not a failure
• Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content.

Failure Procedure

Examine the page to confirm there are regions that are visually distinct and contain distinct content. Check each region to confirm:

1.

• It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR 2.
• The sections are identified by text, ("Header, Footer, Navigation etc.")

If #2 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies. Related Techniques

• Using Landmarks
• Using HTML5 section elements
• Using headings to identify regions of a page
• Using text to identify regions of a page.

This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

— 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/310, or mute the thread https://github.com/notifications/unsubscribe- auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ .

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

Advancing the mission of digital accessibility and inclusion

— 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/310#issuecomment-317074778, or mute the thread https://github.com/notifications/unsubscribe-auth/ AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ .

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

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

Advancing the mission of digital accessibility and inclusion

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

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

[patrickhlauke]

On 25/07/2017 12:59, Katie Haritos-Shea wrote:

[...] more people on the WG will have experience with crafting solid standards language and may be willing to put the diligent thought and well-intentioned work into proper crafting - rather than merely shooting down great ideas!

Oh well, if that's all I'm doing here...feel free to add this and see how the market responds to a new failure being introduced that retrospectively makes conformant pages non-conformant.

[Ryladog]

Patrick,

I do not believe that is all you are doing here. You are a powerful contributor to our work.

I do think that the same diligence and thought we provide for our proposed SCs also needs to be the same kind of methods we use to craft new Failure Techniques.

Katie Haritos-Shea 703-371-5545

On Jul 25, 2017 10:10 AM, "Patrick H. Lauke" notifications@github.com wrote:

On 25/07/2017 12:59, Katie Haritos-Shea wrote:

[...] more people on the WG will have experience with crafting solid standards language and may be willing to put the diligent thought and well-intentioned work into proper crafting - rather than merely shooting down great ideas!

Oh well, if that's all I'm doing here...feel free to add this and see how the market responds to a new failure being introduced that retrospectively makes conformant pages non-conformant.

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

[patrickhlauke]

It's been said before, but: turning this from a failure technique into a suggested technique would remove many of the concerns people have around whether or not this tries to retrospectively mandate something that would turn old passes into fails.

[johnfoliot]

+1 Patrick - this was the concern last time, and remains the concern today.

JF

On Tue, Jul 25, 2017 at 9:41 AM, Patrick H. Lauke notifications@github.com wrote:

It's been said before, but: turning this from a failure technique into a suggested technique would remove many of the concerns people have around whether or not this tries to retrospectively mandate something that would turn old passes into fails.

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

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

Advancing the mission of digital accessibility and inclusion

[Ryladog]

Again, this can be worked on and improved upon once more people on the WG have the experience with crafting solid standards language and are willing to put the diligent thought and well-intentioned work into properly crafting it…..

​​​​​ katie

Katie Haritos-Shea Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

Cell: 703-371-5545 | mailto:ryladog@gmail.com ryladog@gmail.com | Oakton, VA | http://www.linkedin.com/in/katieharitosshea/ LinkedIn Profile | Office: 703-371-5545 | https://twitter.com/Ryladog @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.

From: John Foliot [mailto:notifications@github.com] Sent: Tuesday, July 25, 2017 11:54 AM To: w3c/wcag21 wcag21@noreply.github.com Cc: Katie Haritos-Shea ryladog@gmail.com; Comment comment@noreply.github.com Subject: Re: [w3c/wcag21] Failure Technique around page regions (Header, Footer, Nav, Main etc.) (#310)

+1 Patrick - this was the concern last time, and remains the concern today.

JF

On Tue, Jul 25, 2017 at 9:41 AM, Patrick H. Lauke <notifications@github.com mailto:notifications@github.com > wrote:

It's been said before, but: turning this from a failure technique into a suggested technique would remove many of the concerns people have around whether or not this tries to retrospectively mandate something that would turn old passes into fails.

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

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

Advancing the mission of digital accessibility and inclusion

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

[patrickhlauke]

and are willing to put the diligent thought and well-intentioned work into properly crafting it

and once again, can we stop the implication here that comments here have so far not been neither diligently thought out nor well-intentioned, simply because they point out flaws/shortcomings? it may not be meant that way, but boy does it come across that way.

[detlevhfischer]

I agree with other people who have commented here that this failure technique is problematic. One reason is that in the practical impact of missing landmarks / native equivalents strongly depends on other factors such as the availability of content headings that can be used to navigate the page. Also, there may be good reasons not no mark up a some sections (think of a breadcrumb navigation) with landmarks that some evaluators will deem important and when lacking, reason enough to fail a page.
Content is just too diverse to nail this down as a failure technique.

Sent from phone

Am 21.07.2017 um 18:58 schrieb David MacDonald notifications@github.com:

This is an issue originally filed as Issue #173 for WCAG 2. I've moved it here, which is the active list. It has good momentum and agreement from many AGWG members.

Ø "Failure of 1.3.1 due to regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text."

Description

This failure addresses the problem that occurs when regions of a page are visually distinct from other parts of the page, and contain different content (such as groups of links, advertisements, etc.) that are distinct from the main content of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely on screen reading software that identifies regions of the page. There are a number of ways to identify regions, but if these regions contain distinct content from each other, they must be identifiable in a way the screen reader can relay to the user: either programmatically or by identifying them in text that can be read by the screen reader. A few clarifications of exceptions are:

Content that is not distinct visually is not a failure Content that is not distinct in substance is not a failure Content that only has one or two items is not a failure because it is not a region (group of cohesive content). For instance, a footer with only a copyright notice, or a header with only a logo are not examples of regions because neither of these would be a group of content. Failure Procedure

Examine the page to confirm there are regions that are visually distinct and contain distinct content. Check each region to confirm:

It has been identified in a programmatically determinable way (Landmarks, HTML 5 regions, etc.) OR The sections are identified by text, ("Header, Footer, Navigation etc.") If #2 and #3 are false then this failure condition applies.

Related Techniques

Using Landmarks Using HTML5 section elements Using headings to identify regions of a page Using text to identify regions of a page. This failure was created April 5, 2016

Note: adjustment to the wording "available in text". What we really mean is these sections are identified by text. (i.e. header, navigation, footer etc...) rather than the Footer is available in text.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[lauracarlson]

Hi @johnfoliot and all,

John wrote:

we cannot retroactively introduce conditions that invalidates content that previously met the SC conformance in WCAG 2.0, which is what is happening here.

I thought we could make requirements harder in 2.1 but not easier.

John, would you categorically oppose any new WCAG failure techniques going forward?

Thanks, Laura

[patrickhlauke]

I can't answer for @johnfoliot but for my part: new failure techniques are fine if the WG reaches consensus that they're ok as failure techniques rather than necessitating a new, more bullet-proofed SC which allows for far greater nuance, exceptions, etc.

[johnfoliot]

Hi Laura,

John, would you categorically oppose any new WCAG failure techniques going forward?

No.

What I do categorically oppose is introducing new Failure Techniques that have the practical effect of redefining an existing WCAG 2.0 SC, which I and others maintain is the net effect of this re-proposed Failure Technique.

Additionally, I think our time today is better spent defining new Success Techniques for emergent 2.1 Sc, and stop trying to redefine SC 1.3.1.

JF

On Thu, Jul 27, 2017 at 11:35 AM, Patrick H. Lauke <notifications@github.com

wrote:

I can't answer for @johnfoliot https://github.com/johnfoliot but for my part: new failure techniques are fine if the WG reaches consensus that they're ok as failure techniques rather than necessitating a new, more bullet-proofed SC which allows for far greater nuance, exceptions, etc.

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

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

Advancing the mission of digital accessibility and inclusion

[lauracarlson]

Hi @patrickhlauke and @johnfoliot ,

Thanks. It is good to know that you are both open to new failure techniques. The LVTF had been thinking perhaps a failure around improperly marked up icon fonts may be useful for Issue #297 along with techniques on how to mark them up properly.

Laura

[patrickhlauke]

as long as "improperly" doesn't mean "doesn't follow the exact markup pattern that we cooked up", sure...

[DavidMacDonald]

The reason we were given for not including this failure in WCAG 2.0 was that it would make legacy content fail (2008 and before). So that's why it is here, it is intended to apply to WCAG 2.1 to new sites that want to meet the new standard.

If there are other good reasons for not adding this failure besides legacy content, then I'm all ears. If it is because Failure techniques are negative and not nice, then I'd say we have a fundamental difference of opinion. I think the world is going accessible because it is required, not because corporate America suddenly found its heart.

We have the authority to introduce new failures in our charter for 2.1 and we can also make new requirements. Basic landmarks seems like an easy win for the blind community in 2017.

[jake-abma]

The lack of a failure technique for “not having landmarks” (ARIA / HTML) is a missed opportunity while being a very strong and useful technique with great support nowadays.

As an addition to 2.0 it’s clear we won’t reach consensus, especially because of legacy, ending up here with the option @patrickhlauke mentioned:

turning this from a failure technique into a suggested technique

…but, adding it as a new failure to 2.1 seems a valid approach and thus I agree with @DavidMacDonald

So that's why it is here, it is intended to apply to WCAG 2.1 to new sites that want to meet the new standard.

If 2.1 opens the door for new failures and with some more word crafting on top of the good basis already here for this technique we should elaborate this one further.

[Ryladog]

+1 to Jake

katie

Katie Haritos-Shea

Senior Accessibility SME (WCAG/Section 508/ADA)

703-371-5545

ryladog@gmail.com

People may forget exactly what it was that you said or did, but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to dictate where we are going.

On Sun, Sep 17, 2017 at 5:32 AM, Jake Abma notifications@github.com wrote:

The lack of a failure technique for “not having landmarks” (ARIA / HTML) is a missed opportunity while being a very strong and useful technique with great support nowadays.

As an addition to 2.0 it’s clear we won’t reach consensus, especially because of legacy, ending up here with the option @patrickhlauke https://github.com/patrickhlauke mentioned:

turning this from a failure technique into a suggested technique

…but, adding it as a new failure to 2.1 seems a valid approach and thus I agree with @DavidMacDonald https://github.com/davidmacdonald

So that's why it is here, it is intended to apply to WCAG 2.1 to new sites that want to meet the new standard.

If 2.1 opens the door for new failures and with some more word crafting on top of the good basis already here for this technique we should elaborate this one further.

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

[detlevhfischer]

There are several ways to meet 2.4.1 Bypass blocks where this seems to belong (or, more broadly, 1.3.1 Info and relationships) of which using landmarks or the equivalent structural markup nav, main, etc. is but one. I do not see the viability of a Failure technique here. For example, if there are but 2 or 3 sections on the page which have visible and properly marked-up content headings (i.e. not hidden headings saying Header, Navigation etc) this would probably be fine (at least not a showstopper) for non-visual use? Also, some pages (e.g. within processes) may not need that type of mark-up. IIt will be difficult if not impossible to conclusively draw the line as to when a page would fall under such a Failure and when it might or should be exempt.

[johnfoliot]

Hi Jake,

Techniques are non-normative, and any attempt to try and re-write (or otherwise expand or modify) a Normative Spec by introducing a non-normative "technique" is something that I would protest quite vigorously. I suspect that others might as well based upon previous debate over this "technique".

Introducing this as a Failure Technique in WCAG 2.1 (and mis-interpreting, or even hinting at misinterpretation, of what that means) could conceivably block large sites and other legacy web-applications from ever fully meeting WCAG 2.1 (unless they completely re-jigged their content to include landmarks somehow, so that they no longer "failed").

​

Failures are things that cause accessibility barriers and fail specific success criteria. The documented failures​ ​are useful for:

• Authors to know what to avoid,
• Evaluators to use for checking if content does not meet WCAG success criteria.

Content that has a failure does not meet WCAG success criteria, unless an alternate version is provided without the failure ​( https://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20161007/understanding- techniques.html#ut-understanding-techniques-failures-head ​)​ ​

(I'll also pause here and ask, what accessibility barrier is being put in place by not using Landmarks? Landmarks make inter-page navigation easier, but failing to provide landmarks does not block inter-page navigation, correct? At last count, there are currently 5 Sufficient Techniques that could be applied to specifically address David's concern of "...regions of a page which are visually distinct​ ​AND which ​contain distinct groups of content (headers, footers, navigation bars, main content, asides) not being programmatically determinable or identified by text." - including G115: Using semantic elements to mark up structure http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G115 which does not NEGATE the use of landmark elements, we've simply not added them as an example.)

When we first went around this topic, an advocate for this was quoted as saying (and I paraphrase) "...this is easy to accomplish, just open up your editor and add landmarks to your templates...". It's not that simple, despite those assertions, and there is a real impact and cost associated to this, and the backward compatability of it on legacy content.

Quite simply, you cannot "fail" a web page simply because it doesn't use landmarks, not unless or until you have an explicit Success Criteria that states "thou MUST use landmarks", which, given the fact that WCAG needs to be mark-up language agnostic we'll likely not see emerge.

While I recognize that some organizations attempt to define (or at least 'measure') WCAG compliance via the WCAG "Failure Techniques", it is important to remember (and reinforce) that this is not how WCAG techniques was written, nor intended to be used, and attempting to bolster that misconception further does us a disservice IMHO.

Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard—not the techniques.(https://www.w3.org/TR/2016/ NOTE-UNDERSTANDING-WCAG20-20161007/understanding-techniques.html - emphasis mine)

If the Canadian Bank of Purple Poker Chips, or the US Department of Silly Hats want to use Failure Techniques internally as their measurement metric, they are welcome to do so, but they are using Failure Techniques incorrectly, as that list of Failure Techniques is, and always will be, incomplete.

We already have a Success Technique for SC 1.3.1 (ARIA11: Using ARIA landmarks to identify regions of a page http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/ARIA11), although it appears we lack a specific Success Technique example that uses HTML5 landmark elements, and so I agree with Patrick Lauke (@patrickhlauke https://github.com/patrickhlauke) that we could write a new Success Technique that specifically advocates for the use of HTML5 Landmark elements (OR, we could add additional example(s) to the existing G115: Using semantic elements to mark up structure http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G115), and then we could promote the heck out of it as the "Best" Technique though our advocacy efforts (including, but also above and beyond, the Education and Outreach WG).

That I could support as being proactive, without adding additional obligations through inference (which is what is being attempted here).

As I've long said, "Be the Fireman, Not the Cop".

JF

On Sun, Sep 17, 2017 at 10:09 AM, Katie Haritos-Shea < notifications@github.com> wrote:

+1 to Jake

katie

Katie Haritos-Shea

Senior Accessibility SME (WCAG/Section 508/ADA)

703-371-5545 <(703)%20371-5545>

ryladog@gmail.com

People may forget exactly what it was that you said or did, but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to dictate where we are going.

On Sun, Sep 17, 2017 at 5:32 AM, Jake Abma notifications@github.com wrote:

The lack of a failure technique for “not having landmarks” (ARIA / HTML) is a missed opportunity while being a very strong and useful technique with great support nowadays.

As an addition to 2.0 it’s clear we won’t reach consensus, especially because of legacy, ending up here with the option @patrickhlauke https://github.com/patrickhlauke mentioned:

turning this from a failure technique into a suggested technique

…but, adding it as a new failure to 2.1 seems a valid approach and thus I agree with @DavidMacDonald https://github.com/davidmacdonald

So that's why it is here, it is intended to apply to WCAG 2.1 to new sites that want to meet the new standard.

If 2.1 opens the door for new failures and with some more word crafting on top of the good basis already here for this technique we should elaborate this one further.

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

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

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

Advancing the mission of digital accessibility and inclusion

[jake-abma]

@detlevhfischer I do see your point here for 2.4.1, but if we take a step back and look at it from another perspective there may as well be a solid case.

Not to comply to 2.4.1 but looking at 1.3.1, just as we expect a visual heading to be a H1, H2 etc. we also could expect a main content area to be a <main>, a header to be <header> and a footer to be a <footer> etc.

The other ways to comply to 2.4.1 (skiplinks, headings, textual alternatives) which may also be used for a kind of navigation are not totally in the same line as proper landmarks, a landmark list, landmark keyboard short cut and the clearness of what it, where it goes and what the meaning is supposed to be of the content in that area.

Faking the meaning of landmarks for instance with headings will demand the same text strings like “complementary” and, in contrast to real landmarks, will / may be part of a document outline which makes it way harder to use for the same purpose.

[detlevhfischer]

Hi Jake, I was not arguing that not using landmarks / native markup would be as good as using them - just that not using them might not be enough to fail certain types of pages.

[jake-abma]

Clearly well defined @johnfoliot, that makes it difficult to get a word in edgewise… :-)

I see the bump here and can’t do anything else than agree but still it feels like the way visual appearance, “markup language” and 1.3.1 should work together (e.g. just as for headings and the heading code H1 etc.) it’s a bit of a shame we do (may) have a visual distinction in a page “I can see” but we don’t demand this to be programmatically determinable for users who can’t but just as well need (and may use to navigate)

The lack of standard visual appearance for landmark elements, the late appearance in time (HTML5) are probably the cause they then not belong to 1.3.1. if not used… :-(

[johnfoliot]

Hi Jake,

To be clear, I would LOVE to see all new web-content that is being created use landmark constructs (whether ARIA landmark roles or HTML5 landmark elements), I just don't think we can mandate them, and sadly by introducing that as a non-normative Failure Technique that none-the-less states "Content that has a failure does not meet WCAG success criteria" is where the problem lies (i.e. the non-normative techniques document is actually making something of a normative declaration here - which I do not think was intended, but still, can be interpreted that way, so any Failure we publish must indeed be a failure always).

I continue to leave open the possibility that we can add an additional example to G115, or even write a whole new Sufficient Technique to reinforce the use of those constructs, but failing to use them (as Detlev also notes, there may in fact be instances where the use of landmarks isn't really necessary) and thus not be in conformance is a position that I cannot support.

JF

On Sun, Sep 17, 2017 at 11:39 AM, Jake Abma notifications@github.com wrote:

Clearly well defined @johnfoliot https://github.com/johnfoliot, that makes it difficult to get a word in edgewise… :-)

I see the bump here and can’t do anything else than agree but still it feels like the way visual appearance, “markup language” and 1.3.1 should work together (e.g. just as for headings and the heading code H1 etc.) it’s a bit of a shame we do (may) have a visual distinction in a page “I can see” but we don’t demand this to be programmatically determinable for users who can’t but just as well need (and may use to navigate)

The lack of standard visual appearance for landmark elements, the late appearance in time (HTML5) are probably the cause they than not belong to 1.3.1. if not used… :-(

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

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

Advancing the mission of digital accessibility and inclusion

[DavidMacDonald]

There are 2 things that landmarks provide

1. Programmatic identification of parts of the page that are identified visually (header, footer, navigation, etc.)
2. Quick navigation to those sections from anywhere on the page

SKIP NAVS have limitations

• Skip links do not identify the section when a user enters and leaves a section. They are only navigation aids.
• Skip navs are limited to helping the user get to the section of the page from only one location
• Skip navs often are implemented poorly, (focus not moved, id's not working etc.)

Headings provide a separate semantic and do not replace landmarks.

They help the user navigate within regions and sections and there are sometimes quite a few of them. Landmarks are quick identification of major parts of the page.

If there is no layout that visually indicates a landmark, there is no failure for omitting a programmatic indicator

• If a page doesn't have a visual footer then there is no failure in omitting a role=contentinfo or footer tag
• If a page has no visual header then it is not a failure to have a header tag or role=banner

The failure is simply if the design visually indicates any of the following:

• header/banner
• footer/contentinfo
• navigation section
• Complementary/aside
• search region
• main region which is visually different from other parts of the page

Then the absence of programmatic indications of those sections for those who cannot see would trigger the failure.

This is not unlike the heading failure. As someone who was involved in writing many of the existing Failure Techniques for WCAG 2.0 before this shift, I can say that this technique is consistent with the existing failures. If there are specific objections, they can be scoped into the failure.

I've made amendments to the failure technique at the top of this issue, to address comments in this thread.

[jake-abma]

Hi @DavidMacDonald

I totally feel you, totally agree on the value and within my company I do require landmarks, but…

In the end, isn’t it just a very important Best Practices (because of the benefit it delivers, but not because it eliminates any specific barrier) so…

without, it will be all about very poor user-experiences instead of a specific accessibility fail?

[Ryladog]

In the instance where when a page loads and the focus is drawn to the login form, not the top, having navigation schemes for AT users that provide close-to-equal-access (as non AT users) to the rest of the page - seems clearly in our wheelhouse IMHO

Katie Haritos-Shea 703-371-5545

On Sep 22, 2017 9:10 AM, "Jake Abma" notifications@github.com wrote:

Hi @DavidMacDonald https://github.com/davidmacdonald

I totally feel you, totally agree on the value and within my company I do require landmarks, but…

In the end, isn’t it just a very important Best Practices (because of the benefit it delivers, but not because it eliminates any specific barrier) so…

without, it will be all about very poor user-experiences instead of a specific accessibility fail?

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

[johnfoliot]

Hi all,

Katie is, of course, correct: in that particular user-pattern example, providing "navigation-constructs" such as page landmarks will indeed make the user-experience and accessibility significantly better for screen-reader users.

It doesn't however address any potential needs of sighted, keyboard-only users (and in fact, I could argue that the pattern she suggested would be a potential fail, due to SC 1.3.2 Meaningful Sequence, and the fact that whole-page tab-navigation would be thrown out of Sequence).

However, the perrenial debate around David's proposed Failure Technique fails to address the very real fact that:

a) Some pages will not need landmarks

b) Some pages that are already compliant to WCAG 2.0 that lack landmark

elements or roles today, would suddenly become non-compliant with the introduction of the Failure Technique.

Why? Because of what the Failure Techniques documentation states, specifically "Content that has a failure does not meet WCAG success criteria" (i.e. the non-normative techniques document is actually making something of a normative declaration here - which I do not think was intended, but still, can be interpreted that way, so any Failure we publish must indeed be a failure always).

REMEMBER, SC 1.3.1 successfully progressed to Rec Status in WCAG 2.0 at a time when we had neither landmark elements nor a standardized landmark roles specification, and so clearly in 2008 it was deemed that those constructs were not obligatory to author a WCAG compliant document then.

If we want to introduce specific examples of Landmark Failures, then bring them on. Here's a few patterns that I can think of off the top of my head that would be examples of Failures:

Improper nesting of Landmark elements or roles:

Duplicate use of landmark elements and roles:

Inappropriate use of Landmark Roles:

...

However, a blanket Failure Technique that effectively demands Landmark elements or roles on all HTML documents is an example of severe over-reach, which is why voices such as myself and James Nurthen (Oracle) have previously objected to the inclusion of David's proposal.

(NOTE: these are but 3 examples of "failure" that I could think of in real-time, and I'm sure with some focused thought we could come up with numerous other examples - the point being that there are tons of ways to "fail", and attempting to document all of those ways does very little IMHO towards actually addressing and providing anything resembling "successful"; that instead providing techniques and patterns that can be studied and applied to improve accessibility of real web-pages serves a much more useful resource for mainstream developers. Nobody goes to Stack Overflow to find out how to fail...)

JF

On Fri, Sep 22, 2017 at 9:17 AM, Katie Haritos-Shea < notifications@github.com> wrote:

In the instance where when a page loads and the focus is drawn to the login form, not the top, having navigation schemes for AT users that provide close-to-equal-access (as non AT users) to the rest of the page - seems clearly in our wheelhouse IMHO

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Sep 22, 2017 9:10 AM, "Jake Abma" notifications@github.com wrote:

Hi @DavidMacDonald https://github.com/davidmacdonald

I totally feel you, totally agree on the value and within my company I do require landmarks, but…

In the end, isn’t it just a very important Best Practices (because of the benefit it delivers, but not because it eliminates any specific barrier) so…

without, it will be all about very poor user-experiences instead of a specific accessibility fail?

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

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

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

Advancing the mission of digital accessibility and inclusion

[Ryladog]

Can this proposed failure technique be improved in language to cover simple pages, and outlier situations? I think so.

Providing failure techniques in no way prohibits sufficient techniques, and never has.

But killing it outright, because one opposes failure techniques in principle, without giving it a true shot, diminishes the value of our work IMHO.

Katie Haritos-Shea 703-371-5545

On Sep 22, 2017 9:55 AM, "John Foliot" notifications@github.com wrote:

Hi all,

Katie is, of course, correct: in that particular user-pattern example, providing "navigation-constructs" such as page landmarks will indeed make the user-experience and accessibility significantly better for screen-reader users.

It doesn't however address any potential needs of sighted, keyboard-only users (and in fact, I could argue that the pattern she suggested would be a potential fail, due to SC 1.3.2 Meaningful Sequence, and the fact that whole-page tab-navigation would be thrown out of Sequence).

However, the perrenial debate around David's proposed Failure Technique fails to address the very real fact that:

a) Some pages will not need landmarks

b) Some pages that are already compliant to WCAG 2.0 that lack landmark elements or roles today, would suddenly become non-compliant with the introduction of the Failure Technique.

Why? Because of what the Failure Techniques documentation states, specifically "Content that has a failure does not meet WCAG success criteria" (i.e. the non-normative techniques document is actually making something of a normative declaration here - which I do not think was intended, but still, can be interpreted that way, so any Failure we publish must indeed be a failure always).

REMEMBER, SC 1.3.1 successfully progressed to Rec Status in WCAG 2.0 at a time when we had neither landmark elements nor a standardized landmark roles specification, and so clearly in 2008 it was deemed that those constructs were not obligatory to author a WCAG compliant document then.

If we want to introduce specific examples of Landmark Failures, then bring them on. Here's a few patterns that I can think of off the top of my head that would be examples of Failures:

Improper nesting of Landmark elements or roles:

Duplicate use of landmark elements and roles:

Inappropriate use of Landmark Roles:

...

However, a blanket Failure Technique that effectively demands Landmark elements or roles on all HTML documents is an example of severe over-reach, which is why voices such as myself and James Nurthen (Oracle) have previously objected to the inclusion of David's proposal.

(NOTE: these are but 3 examples of "failure" that I could think of in real-time, and I'm sure with some focused thought we could come up with numerous other examples - the point being that there are tons of ways to "fail", and attempting to document all of those ways does very little IMHO towards actually addressing and providing anything resembling "successful"; that instead providing techniques and patterns that can be studied and applied to improve accessibility of real web-pages serves a much more useful resource for mainstream developers. Nobody goes to Stack Overflow to find out how to fail...)

JF

On Fri, Sep 22, 2017 at 9:17 AM, Katie Haritos-Shea < notifications@github.com> wrote:

In the instance where when a page loads and the focus is drawn to the login form, not the top, having navigation schemes for AT users that provide close-to-equal-access (as non AT users) to the rest of the page - seems clearly in our wheelhouse IMHO

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 9:10 AM, "Jake Abma" notifications@github.com wrote:

Hi @DavidMacDonald https://github.com/davidmacdonald

I totally feel you, totally agree on the value and within my company I do require landmarks, but…

In the end, isn’t it just a very important Best Practices (because of the benefit it delivers, but not because it eliminates any specific barrier) so…

without, it will be all about very poor user-experiences instead of a specific accessibility fail?

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

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

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

Advancing the mission of digital accessibility and inclusion

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

[johnfoliot]

FOR THE RECORD:

While I have long-standing reservations over the real usefulness of Failure Techniques (as being a potential never-ending and always incomplete list of ways to fail), I have never objected to their existence or creation, and in fact in this thread I proposed 3 examples of potential Failure Techniques specifically related to Landmarks.

I do however remains quite concerned about the statement in the Failures document that states "Content that has a failure does not meet WCAG success criteria", and the fact that it could be interpreted that the presence of any Failure Technique will automatically cause the page to fail (even though that is provably false: i.e. a Failure Technique that states that not using landmarks on all pages means those pages are non-conformant.)

Finally, as previously noted, we have a lot of work in front of us if we are to reach our mandated deadlines, and debating Failure Techniques at this time feels, to me, an inappropriate use of our resources today. We have much bigger issues that need to be addressed by this WG, such as a full editorial review of ALL of the Understanding documentation to ensure that the Working Group is both in agreement with the Understanding texts, as well as ensuring that those texts are properly formatted and able to be integrated into the DOT-RELEASE that is WCAG 2.1

JF

On Fri, Sep 22, 2017 at 10:12 AM, Katie Haritos-Shea < notifications@github.com> wrote:

Can this proposed failure technique be improved in language to cover simple pages, and outlier situations? I think so.

Providing failure techniques in no way prohibits sufficient techniques, and never has.

But killing it outright, because one opposes failure techniques in principle, without giving it a true shot, diminishes the value of our work IMHO.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Sep 22, 2017 9:55 AM, "John Foliot" notifications@github.com wrote:

Hi all,

Katie is, of course, correct: in that particular user-pattern example, providing "navigation-constructs" such as page landmarks will indeed make the user-experience and accessibility significantly better for screen-reader users.

It doesn't however address any potential needs of sighted, keyboard-only users (and in fact, I could argue that the pattern she suggested would be a potential fail, due to SC 1.3.2 Meaningful Sequence, and the fact that whole-page tab-navigation would be thrown out of Sequence).

However, the perrenial debate around David's proposed Failure Technique fails to address the very real fact that:

a) Some pages will not need landmarks

b) Some pages that are already compliant to WCAG 2.0 that lack landmark elements or roles today, would suddenly become non-compliant with the introduction of the Failure Technique.

Why? Because of what the Failure Techniques documentation states, specifically "Content that has a failure does not meet WCAG success criteria" (i.e. the non-normative techniques document is actually making something of a normative declaration here - which I do not think was intended, but still, can be interpreted that way, so any Failure we publish must indeed be a failure always).

REMEMBER, SC 1.3.1 successfully progressed to Rec Status in WCAG 2.0 at a time when we had neither landmark elements nor a standardized landmark roles specification, and so clearly in 2008 it was deemed that those constructs were not obligatory to author a WCAG compliant document then.

If we want to introduce specific examples of Landmark Failures, then bring them on. Here's a few patterns that I can think of off the top of my head that would be examples of Failures:

Improper nesting of Landmark elements or roles:

Duplicate use of landmark elements and roles:

Inappropriate use of Landmark Roles:

...

However, a blanket Failure Technique that effectively demands Landmark elements or roles on all HTML documents is an example of severe over-reach, which is why voices such as myself and James Nurthen (Oracle) have previously objected to the inclusion of David's proposal.

(NOTE: these are but 3 examples of "failure" that I could think of in real-time, and I'm sure with some focused thought we could come up with numerous other examples - the point being that there are tons of ways to "fail", and attempting to document all of those ways does very little IMHO towards actually addressing and providing anything resembling "successful"; that instead providing techniques and patterns that can be studied and applied to improve accessibility of real web-pages serves a much more useful resource for mainstream developers. Nobody goes to Stack Overflow to find out how to fail...)

JF

On Fri, Sep 22, 2017 at 9:17 AM, Katie Haritos-Shea < notifications@github.com> wrote:

In the instance where when a page loads and the focus is drawn to the login form, not the top, having navigation schemes for AT users that provide close-to-equal-access (as non AT users) to the rest of the page - seems clearly in our wheelhouse IMHO

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 9:10 AM, "Jake Abma" notifications@github.com wrote:

Hi @DavidMacDonald https://github.com/davidmacdonald

I totally feel you, totally agree on the value and within my company I do require landmarks, but…

In the end, isn’t it just a very important Best Practices (because of the benefit it delivers, but not because it eliminates any specific barrier) so…

without, it will be all about very poor user-experiences instead of a specific accessibility fail?

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

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

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

Advancing the mission of digital accessibility and inclusion

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

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

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

Advancing the mission of digital accessibility and inclusion

[Ryladog]

Opinion noted. As for how we spend our time, each of us should spend our time working on that which we feel is important. Debating this topic apparently has been your choice JF.

Katie Haritos-Shea 703-371-5545

[johnfoliot]

As for how we spend our time, each of us should spend our time working on that which we feel is important.

+1, and I suggested as much yesterday:

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?

(source: https://github.com/w3c/wcag21/issues/392#issuecomment-331350948)

​JF​

On Fri, Sep 22, 2017 at 10:40 AM, Katie Haritos-Shea < notifications@github.com> wrote:

Opinion noted. As for how we spend our time, each of us should spend our time working on that which we feel is important. Debating this topic apparently has been your choice JF.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Sep 22, 2017 10:27 AM, "John Foliot" notifications@github.com wrote:

FOR THE RECORD:

While I have long-standing reservations over the real usefulness of Failure Techniques (as being a potential never-ending and always incomplete list of ways to fail), I have never objected to their existence or creation, and in fact in this thread I proposed 3 examples of potential Failure Techniques specifically related to Landmarks.

I do however remains quite concerned about the statement in the Failures document that states "Content that has a failure does not meet WCAG success criteria", and the fact that it could be interpreted that the presence of any Failure Technique will automatically cause the page to fail (even though that is provably false: i.e. a Failure Technique that states that not using landmarks on all pages means those pages are non-conformant.)

Finally, as previously noted, we have a lot of work in front of us if we are to reach our mandated deadlines, and debating Failure Techniques at this time feels, to me, an inappropriate use of our resources today. We have much bigger issues that need to be addressed by this WG, such as a full editorial review of ALL of the Understanding documentation to ensure that the Working Group is both in agreement with the Understanding texts, as well as ensuring that those texts are properly formatted and able to be integrated into the DOT-RELEASE that is WCAG 2.1

JF

On Fri, Sep 22, 2017 at 10:12 AM, Katie Haritos-Shea < notifications@github.com> wrote:

Can this proposed failure technique be improved in language to cover simple pages, and outlier situations? I think so.

Providing failure techniques in no way prohibits sufficient techniques, and never has.

But killing it outright, because one opposes failure techniques in principle, without giving it a true shot, diminishes the value of our work IMHO.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 9:55 AM, "John Foliot" notifications@github.com wrote:

Hi all,

Katie is, of course, correct: in that particular user-pattern example, providing "navigation-constructs" such as page landmarks will indeed make the user-experience and accessibility significantly better for screen-reader users.

It doesn't however address any potential needs of sighted, keyboard-only users (and in fact, I could argue that the pattern she suggested would be a potential fail, due to SC 1.3.2 Meaningful Sequence, and the fact that whole-page tab-navigation would be thrown out of Sequence).

However, the perrenial debate around David's proposed Failure Technique fails to address the very real fact that:

a) Some pages will not need landmarks

b) Some pages that are already compliant to WCAG 2.0 that lack landmark elements or roles today, would suddenly become non-compliant with the introduction of the Failure Technique.

Why? Because of what the Failure Techniques documentation states, specifically "Content that has a failure does not meet WCAG success criteria" (i.e. the non-normative techniques document is actually making something of a normative declaration here - which I do not think was intended, but still, can be interpreted that way, so any Failure we publish must indeed be a failure always).

REMEMBER, SC 1.3.1 successfully progressed to Rec Status in WCAG 2.0 at a time when we had neither landmark elements nor a standardized landmark roles specification, and so clearly in 2008 it was deemed that those constructs were not obligatory to author a WCAG compliant document then.

If we want to introduce specific examples of Landmark Failures, then bring them on. Here's a few patterns that I can think of off the top of my head that would be examples of Failures:

Improper nesting of Landmark elements or roles:

Duplicate use of landmark elements and roles:

Inappropriate use of Landmark Roles:

...

However, a blanket Failure Technique that effectively demands Landmark elements or roles on all HTML documents is an example of severe over-reach, which is why voices such as myself and James Nurthen (Oracle) have previously objected to the inclusion of David's proposal.

(NOTE: these are but 3 examples of "failure" that I could think of in real-time, and I'm sure with some focused thought we could come up with numerous other examples - the point being that there are tons of ways to "fail", and attempting to document all of those ways does very little IMHO towards actually addressing and providing anything resembling "successful"; that instead providing techniques and patterns that can be studied and applied to improve accessibility of real web-pages serves a much more useful resource for mainstream developers. Nobody goes to Stack Overflow to find out how to fail...)

JF

On Fri, Sep 22, 2017 at 9:17 AM, Katie Haritos-Shea < notifications@github.com> wrote:

In the instance where when a page loads and the focus is drawn to the login form, not the top, having navigation schemes for AT users that provide close-to-equal-access (as non AT users) to the rest of the page - seems clearly in our wheelhouse IMHO

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

<(703)%20371-5545>

On Sep 22, 2017 9:10 AM, "Jake Abma" notifications@github.com wrote:

Hi @DavidMacDonald https://github.com/davidmacdonald

I totally feel you, totally agree on the value and within my company I do require landmarks, but…

In the end, isn’t it just a very important Best Practices (because of the benefit it delivers, but not because it eliminates any specific barrier) so…

without, it will be all about very poor user-experiences instead of a specific accessibility fail?

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

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

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

Advancing the mission of digital accessibility and inclusion

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331453737, or

mute

the thread https://github.com/notifications/unsubscribe-auth/ AFfqyqtWrNcbZoKNOafdkUBormwf12-Wks5sk7xkgaJpZM4OfpuQ .

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331458407, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK- c05wQS6nX1pB6iQ8jAynfTfX-CzZks5sk8BIgaJpZM4OfpuQ

.

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

Advancing the mission of digital accessibility and inclusion

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331462585, or mute the thread https://github.com/notifications/unsubscribe-auth/ AFfqypedSIV9lVJYJC1KDpKCtYKPc1gnks5sk8PngaJpZM4OfpuQ .

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

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

Advancing the mission of digital accessibility and inclusion

[DavidMacDonald]

a) Some pages will not need landmarks b) Some pages that are already compliant to WCAG 2.0 that lack landmarkelements or roles today, would suddenly become non-compliant with the introduction of the Failure Technique.

No, if a page does not have any visual indication of one of these regions there is no requirement for a non visual indicator. I find it astonishing that this is not understood, as it is part of the SC language. Do you have a recommendation to make it clearer? Quoting Jonathan Avila

"use of presentation without semantics or text is a failure of SC 1.3.1"

This failure technique is proposed for WCAG 2.1, not because it doesn't apply to 2.0 but because there is almost no possible way to get a failure into WCAG 2 even though WCAG was intended to grow with technology.

Regarding the work ahead of us, I'm quite surprised that this failure is experiencing such a struggle from a few. In my opinion it should have been a rubber stamp, with perhaps some tweaks to address concerns. The 10 hours I spent on it last year was over twice the time I put into the dozens of failures I had previously written for WCAG 2. Which brings us to issue #392

[Ryladog]

Exactly David!

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.

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 12:39 PM, "David MacDonald" notifications@github.com wrote:

a) Some pages will not need landmarks b) Some pages that are already compliant to WCAG 2.0 that lack landmarkelements or roles today, would suddenly become non-compliant with the introduction of the Failure Technique.

No, If a page does not have any visual indication of one of these regions there is no requirement for a non visual indicator. I find it astonishing that this is not understood, as it is part of the SC language. Do you have a recommendation to make it clearer?

This failure technique is proposed for WCAG 2.1, not because it doesn't apply to 2.0 but because there is almost no possible way to get a failure into WCAG 2 even though WCAG was intended to grow with technology.

Regarding the work ahead of us, I'm quite surprised that this failure is experiencing such a struggle from a few. In my opinion it should have been a rubber stamp, with perhaps some tweaks to address concerns. The 10 hours I spent on it last year was over twice the time I put into the dozens of failures I had previously written for WCAG 2.

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

[johnfoliot]

David, I am not opposed to adding Failure Techniques to the new SC being added to WCAG 2.1 (which is not a "new" spec, as you have previously and erroneously stated, but rather an update to the existing specification, which is what dot-releases are.) In fact, I have explicitly stated as such as part of this discussion, when Laura asked me "*John, would you categorically oppose any new WCAG failure techniques going forward?*" (My response was an emphatic No. - https://github.com/w3c/wcag21/issues/310#issuecomment- 318435035) Your desire to add this new failure technique however is fundamentally impacting existing web content, whether you are prepared to admit it or not. For example, with the addition of your proposal, it would automatically make the W3C web site non-conformant. (Go to w3.org, and search the source code for role="search", which is clearly visually present on the page, and quite discernible to non-sighted users too [1].) However, it would instantly fail with the addition of your retroactive Failure Technique (due to the lack of role="search"), and the language I have repeatedly quoted stating "*Content that has a failure does not meet WCAG success criteria*". I didn't write that, I'm not fully on-board with how that statement was crafted, but that is what cleared the bar with the publication of WCAG 2.0, so that is what we have to live with today.) Additionally, your own website at http://www.davidmacd.com/#endorse would also fail your proposed Failure Technique, as the testimonials are all in non-semantic divs (

), as opposed to ("The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable"). That may not be the intent of your proposal, but it is certainly a clear example of the potential unintended consequences of your proposal. > This failure technique is proposed for WCAG 2.1, not because it doesn't apply to 2.0 but because there is almost no possible way to get a failure into WCAG 2... This seems to indicate ​ to me that you ​may ​ have a fundamental misunderstanding over what we are doing with the dot-release of WCAG ​, and how the W3C as a standards organization approaches dot-releases​ ​. We are not creating a new specification, we are updating the existing specification incrementally, adding new SC to cover areas missed in the 2.0 time-frame/work-effort. This is what our charter states : The WCAG 2.1 update will be an incremental update to WCAG 2.0 rather than a major revision. WCAG 2.1 is designed to build on the WCAG 2.0 recommendation to ensure testability and technology independence, *and will also ensure backward compatibility with WCAG 2.0.* Work on something "new" (a major revision) is what Project Silver is for and about.​ ​So yes, any attempt to reframe or add additional requirements on existing 2.0 SC that breaks or negatively impacts backward compatibility will be strenuously objected to, at least by me.​ You have been very transparent in the past on your motivation for this, stating that one of your clients won't use landmark regions unless there is a Failure Technique for that. Attempting to use WCAG to advance your own agenda, or to add usability enhancements is a wrong application of WCAG, which is supposed to be about removing barriers [2], not 'sweetening' user experiences. That may seem cold and callous, but because our specification is also referenced in legislations, we need to remain steeled to these ideas, as sad as they may be. As I have repeatedly stated, I would support in a heartbeat a new Success Technique that showed how using HTML5 landmarks could address requirements of 1.3.1 (a companion to the existing ARIA11: Using ARIA landmarks to identify regions of a page ), but for the reasons stated above, I will remain firm in my resolve to reject this proposed Failure Technique in any 2.x work ​JF [1] (I am far from suggesting this is perfect, but it does not introduce a barrier to any user that I can determine, despite my reservation over the use of the positive integer for the tabindex attribute. David's proposal would fail this, and subsequently the entire page, for lack of a wrapper div with role="search" applied.) [2] *Failures are things that cause accessibility barriers* (JF: and *not* poor user-experiences) (https://www.w3.org/TR/UNDERSTANDING-WCAG20/understanding-techniques.html# ut-understanding-techniques-failures-head) On Fri, Sep 22, 2017 at 12:39 PM, David MacDonald wrote: > a) Some pages will not need landmarks b) Some pages that are already > compliant to WCAG 2.0 that lack landmarkelements or roles today, would > suddenly become non-compliant with the > introduction of the Failure Technique. > > No, If a page does not have any visual indication of one of these regions > there is no requirement for a non visual indicator. I find it astonishing > that this is not understood, as it is part of the SC language. Do you have > a recommendation to make it clearer? > > This failure technique is proposed for WCAG 2.1, not because it doesn't > apply to 2.0 but because there is almost no possible way to get a failure > into WCAG 2 even though WCAG was intended to grow with technology. > > Regarding the work ahead of us, I'm quite surprised that this failure is > experiencing such a struggle from a few. In my opinion it should have been > a rubber stamp, with perhaps some tweaks to address concerns. The 10 hours > I spent on it last year was over twice the time I put into the dozens of > failures I had previously written for WCAG 2. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or mute > the thread > > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[Ryladog]

Really? I'd be surprised to see the W3C site having a WCAG 2.1 Conformance Claim up somewhere already...

Katie Haritos-Shea 703-371-5545

On Sep 22, 2017 5:04 PM, "John Foliot" notifications@github.com wrote:

David, I am not opposed to adding Failure Techniques to the new SC being added to WCAG 2.1 (which is not a "new" spec, as you have previously and erroneously stated, but rather an update to the existing specification, which is what dot-releases are.) In fact, I have explicitly stated as such as part of this discussion, when Laura asked me "*John, would you categorically oppose any new WCAG failure techniques going forward?*" (My response was an emphatic No. - https://github.com/w3c/wcag21/issues/310#issuecomment- 318435035) Your desire to add this new failure technique however is fundamentally impacting existing web content, whether you are prepared to admit it or not. For example, with the addition of your proposal, it would automatically make the W3C web site non-conformant. (Go to w3.org, and search the source code for role="search", which is clearly visually present on the page, and quite discernible to non-sighted users too [1].) However, it would instantly fail with the addition of your retroactive Failure Technique (due to the lack of role="search"), and the language I have repeatedly quoted stating "*Content that has a failure does not meet WCAG success criteria*". I didn't write that, I'm not fully on-board with how that statement was crafted, but that is what cleared the bar with the publication of WCAG 2.0, so that is what we have to live with today.) Additionally, your own website at http://www.davidmacd.com/#endorse would also fail your proposed Failure Technique, as the testimonials are all in non-semantic divs (

), as opposed to ("The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable"). That may not be the intent of your proposal, but it is certainly a clear example of the potential unintended consequences of your proposal. > This failure technique is proposed for WCAG 2.1, not because it doesn't apply to 2.0 but because there is almost no possible way to get a failure into WCAG 2... This seems to indicate ​ to me that you ​may ​ have a fundamental misunderstanding over what we are doing with the dot-release of WCAG ​, and how the W3C as a standards organization approaches dot-releases​ ​. We are not creating a new specification, we are updating the existing specification incrementally, adding new SC to cover areas missed in the 2.0 time-frame/work-effort. This is what our charter states : The WCAG 2.1 update will be an incremental update to WCAG 2.0 rather than a major revision. WCAG 2.1 is designed to build on the WCAG 2.0 recommendation to ensure testability and technology independence, *and will also ensure backward compatibility with WCAG 2.0.* Work on something "new" (a major revision) is what Project Silver is for and about.​ ​So yes, any attempt to reframe or add additional requirements on existing 2.0 SC that breaks or negatively impacts backward compatibility will be strenuously objected to, at least by me.​ You have been very transparent in the past on your motivation for this, stating that one of your clients won't use landmark regions unless there is a Failure Technique for that. Attempting to use WCAG to advance your own agenda, or to add usability enhancements is a wrong application of WCAG, which is supposed to be about removing barriers [2], not 'sweetening' user experiences. That may seem cold and callous, but because our specification is also referenced in legislations, we need to remain steeled to these ideas, as sad as they may be. As I have repeatedly stated, I would support in a heartbeat a new Success Technique that showed how using HTML5 landmarks could address requirements of 1.3.1 (a companion to the existing ARIA11: Using ARIA landmarks to identify regions of a page ), but for the reasons stated above, I will remain firm in my resolve to reject this proposed Failure Technique in any 2.x work ​JF [1] (I am far from suggesting this is perfect, but it does not introduce a barrier to any user that I can determine, despite my reservation over the use of the positive integer for the tabindex attribute. David's proposal would fail this, and subsequently the entire page, for lack of a wrapper div with role="search" applied.) [2] *Failures are things that cause accessibility barriers* (JF: and *not* poor user-experiences) (https://www.w3.org/TR/UNDERSTANDING-WCAG20/understanding-techniques.html# ut-understanding-techniques-failures-head) On Fri, Sep 22, 2017 at 12:39 PM, David MacDonald < notifications@github.com> wrote: > a) Some pages will not need landmarks b) Some pages that are already > compliant to WCAG 2.0 that lack landmarkelements or roles today, would > suddenly become non-compliant with the > introduction of the Failure Technique. > > No, If a page does not have any visual indication of one of these regions > there is no requirement for a non visual indicator. I find it astonishing > that this is not understood, as it is part of the SC language. Do you have > a recommendation to make it clearer? > > This failure technique is proposed for WCAG 2.1, not because it doesn't > apply to 2.0 but because there is almost no possible way to get a failure > into WCAG 2 even though WCAG was intended to grow with technology. > > Regarding the work ahead of us, I'm quite surprised that this failure is > experiencing such a struggle from a few. In my opinion it should have been > a rubber stamp, with perhaps some tweaks to address concerns. The 10 hours > I spent on it last year was over twice the time I put into the dozens of > failures I had previously written for WCAG 2. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or mute > the thread > > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

[johnfoliot]

Hi Katie,

What part of Backward Compatibility is unclear to you?

This is a proposed Failure Technique for an existing, WCAG 2.0 SC, which somehow you and David now want to change, mid-stream. Meeting a Failure Technique (whether at 2.0 or 2.1) still means that the content fails, because that's what the documentation says that state means (Content that has a failure does not meet WCAG success criteria).

Currently the Failure Techniques make no distinction to dot-releases, and to preserve backward compat, we cannot change the meaning of current existing SC.

Previously, you wrote:

Does WCAG 2.0 require Headings be used for 1.3.1 for all pages? No.

...and yet, we fail pages all the time because of this, because, in part, of F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text, and the example code:

Introduction

This introduction provides detailed information about how to use this ........

...and the fact that "Content that has a failure does not meet WCAG success criteria".

JF

On Fri, Sep 22, 2017 at 5:09 PM, Katie Haritos-Shea < notifications@github.com> wrote:

Really? I'd be surprised to see the W3C site having a WCAG 2.1 Conformance Claim up somewhere already...

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Sep 22, 2017 5:04 PM, "John Foliot" notifications@github.com wrote:

David, I am not opposed to adding Failure Techniques to the new SC being added to WCAG 2.1 (which is not a "new" spec, as you have previously and erroneously stated, but rather an update to the existing specification, which is what dot-releases are.) In fact, I have explicitly stated as such as part of this discussion, when Laura asked me "*John, would you categorically oppose any new WCAG failure techniques going forward?*" (My response was an emphatic No. - https://github.com/w3c/wcag21/issues/310#issuecomment- 318435035) Your desire to add this new failure technique however is fundamentally impacting existing web content, whether you are prepared to admit it or not. For example, with the addition of your proposal, it would automatically make the W3C web site non-conformant. (Go to w3.org, and search the source code for role="search", which is clearly visually present on the page, and quite discernible to non-sighted users too [1].) However, it would instantly fail with the addition of your retroactive Failure Technique (due to the lack of role="search"), and the language I have repeatedly quoted stating "*Content that has a failure does not meet WCAG success criteria*". I didn't write that, I'm not fully on-board with how that statement was crafted, but that is what cleared the bar with the publication of WCAG 2.0, so that is what we have to live with today.) Additionally, your own website at http://www.davidmacd.com/#endorse would also fail your proposed Failure Technique, as the testimonials are all in non-semantic divs (

), as opposed to ("The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable"). That may not be the intent of your proposal, but it is certainly a clear example of the potential unintended consequences of your proposal. > This failure technique is proposed for WCAG 2.1, not because it doesn't apply to 2.0 but because there is almost no possible way to get a failure into WCAG 2... This seems to indicate ​ to me that you ​may ​ have a fundamental misunderstanding over what we are doing with the dot-release of WCAG ​, and how the W3C as a standards organization approaches dot-releases​ ​. We are not creating a new specification, we are updating the existing specification incrementally, adding new SC to cover areas missed in the 2.0 time-frame/work-effort. This is what our charter states : The WCAG 2.1 update will be an incremental update to WCAG 2.0 rather than a major revision. WCAG 2.1 is designed to build on the WCAG 2.0 recommendation to ensure testability and technology independence, *and will also ensure backward compatibility with WCAG 2.0.* Work on something "new" (a major revision) is what Project Silver is for and about.​ ​So yes, any attempt to reframe or add additional requirements on existing 2.0 SC that breaks or negatively impacts backward compatibility will be strenuously objected to, at least by me.​ You have been very transparent in the past on your motivation for this, stating that one of your clients won't use landmark regions unless there is a Failure Technique for that. Attempting to use WCAG to advance your own agenda, or to add usability enhancements is a wrong application of WCAG, which is supposed to be about removing barriers [2], not 'sweetening' user experiences. That may seem cold and callous, but because our specification is also referenced in legislations, we need to remain steeled to these ideas, as sad as they may be. As I have repeatedly stated, I would support in a heartbeat a new Success Technique that showed how using HTML5 landmarks could address requirements of 1.3.1 (a companion to the existing ARIA11: Using ARIA landmarks to identify regions of a page ), but for the reasons stated above, I will remain firm in my resolve to reject this proposed Failure Technique in any 2.x work ​JF [1] (I am far from suggesting this is perfect, but it does not introduce a barrier to any user that I can determine, despite my reservation over the use of the positive integer for the tabindex attribute. David's proposal would fail this, and subsequently the entire page, for lack of a wrapper div with role="search" applied.) [2] *Failures are things that cause accessibility barriers* (JF: and *not* poor user-experiences) (https://www.w3.org/TR/UNDERSTANDING-WCAG20/ understanding-techniques.html# ut-understanding-techniques-failures-head) On Fri, Sep 22, 2017 at 12:39 PM, David MacDonald < notifications@github.com> wrote: > a) Some pages will not need landmarks b) Some pages that are already > compliant to WCAG 2.0 that lack landmarkelements or roles today, would > suddenly become non-compliant with the > introduction of the Failure Technique. > > No, If a page does not have any visual indication of one of these regions > there is no requirement for a non visual indicator. I find it astonishing > that this is not understood, as it is part of the SC language. Do you have > a recommendation to make it clearer? > > This failure technique is proposed for WCAG 2.1, not because it doesn't > apply to 2.0 but because there is almost no possible way to get a failure > into WCAG 2 even though WCAG was intended to grow with technology. > > Regarding the work ahead of us, I'm quite surprised that this failure is > experiencing such a struggle from a few. In my opinion it should have been > a rubber stamp, with perhaps some tweaks to address concerns. The 10 hours > I spent on it last year was over twice the time I put into the dozens of > failures I had previously written for WCAG 2. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or mute > the thread > > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

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

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

Advancing the mission of digital accessibility and inclusion

[jake-abma]

Was just thinking about @DavidMacDonald comments of “visual indication” and trying to imagine the case for identifying the conditions and implication of testing landmarks. Soon I reached a state of a mind boggling minefield.

When will a “visual indication” pass and when not? What is the benchmark for visual indication? This could be very very hard for page regions / landmarks, much more than for contrast of text or a heading being present or not.

For some sites it’s obvious what the header and footer is. They have very clear backgrounds and could be used as an indication. For lots of other situation it’s just not and what to do in those cases?

Just some situations:

• A: The Header and Footer have backgrounds but the contrast doesn’t pass the 4.5:1 condition. It’s just a very light grey while the rest of the page is white. Is this enough? Do we need to account for a specific contrast ratio?
• B: The Header has 200px height but only the top 30px are dark with some white links, the rest of the 170px is white with a white Main below it. The Header has content (a main menu with colours and styling) which sets them apart from the rest of the page so you could make up what the header is, but also not really. Will it pass or not?
• C: There is a Header, Main, Footer and the Body has a gradient on the whole page with dark overlap of the Header and part of the Main, turning light in colour and ending at the footer again with dark. The Header and a part of the Main has light text (on the dark part of the gradient) but this ‘turn’ a bit further down the Main. Will it pass or fail?
• D: There are ‘cards’ or ‘panels’ on the right with no other coloured background but visually you could argue (also because of the content) it’s an Aside (complementary). But also there’s content in the ‘panels’ / ‘card/ which doesn’t really belong to the Aside. Will it pass or not?
• E: A designer just likes to add borders / horizontal rows / vertical rows on the page. The are between the Header and Main, but also in the Main itself. The contrast is very light though. Is it enough to pass or fail?
• F: The Header and Main have a ‘image’ between them (some place them in the Main, Some in the Header). Is this enough to pass / fail?

And so much more of those edge, but real live, cases that all the conditions are next to never possible to define. We will be left with subjective judgement of each tester.

[johnfoliot]

Exactly Jake.

JF

On Fri, Sep 22, 2017 at 5:21 PM, Jake Abma notifications@github.com wrote:

Was just thinking about @DavidMacDonald https://github.com/davidmacdonald comments of “visual indication” and trying to imagine the case for identifying the conditions and implication of testing landmarks. Soon I reached a state of a mind boggling minefield.

When will a “visual indication” pass and when not? What is the benchmark for visual indication? This could be very very hard for page regions / landmarks, much more than for contrast of text or a heading being present or not.

For some sites it’s obvious what the header and footer is. They have very clear backgrounds and could be used as an indication. For lots of other situation it’s just not and what to do in those cases?

Just some situations:

• A: The Header and Footer have backgrounds but the contrast doesn’t pass the 4.5:1 condition. It’s just a very light grey while the rest of the page is white. Is this enough? Do we need to account for a specific contrast ratio?
• B: The Header has 200px height but only the top 30px are dark with some white links, the rest of the 170px is white with a white Main below it. The Header has content (a main menu with colours and styling) which sets them apart from the rest of the page so you could make up what the header is, but also not really. Will it pass or not?
• C: There is a Header, Main, Footer and the Body has a gradient on the whole page with dark overlap of the Header and part of the Main, turning light in colour and ending at the footer again with dark. The Header and a part of the Main has light text (on the dark part of the gradient) but this ‘turn’ a bit further down the Main. Will it pass or fail?
• D: There are ‘cards’ or ‘panels’ on the right with no other coloured background but visually you could argue (also because of the content) it’s an Aside (complementary). But also there’s content in the ‘panels’ / ‘card/ which doesn’t really belong to the Aside. Will it pass or not?
• E: A designer just likes to add borders / horizontal rows / vertical rows on the page. The are between the Header and Main, but also in the Main itself. The contrast is very light though. Is it enough to pass or fail?
• F: The Header and Main have a ‘image’ between them (some place them in the Main, Some in the Header). Is this enough to pass / fail?

And so much more of those edge, but real live, cases that all the conditions are next to never possible to define. We will be left with subjective judgement of each tester.

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

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

Advancing the mission of digital accessibility and inclusion

[Ryladog]

You mean your definition of backwards compatible? Apparently, nothing.

There are many things that I do not understand about many things in life, John.

I happen to be rather familiar with WCAG 2.0 as well as Conformance claims and general conformance to it.

If/when WCAG 2.1 becomes a W3C Recommendation it will become a NEW standard, in its own right. And as such, new things can fall under existing SC scope. As it should be.

Such as; possibly Landmarks and Regions under 1.3.1, because we are not only addressing LV and COGA issues. We, in 2.1 are also addressing new technologies and paradigms, mobile and otherwise, including new interaction models.

At least, that is my understanding of what we are doing, as I approach my 18th year on this working group.

Those continuing to claim Conformance to 2.0 will fail nothing. Their site will still be 2.0 compliant.

Katie Haritos-Shea 703-371-5545

[johnfoliot]

Once again, I am hearing an assumption that sites will either be all WCAG 2.O or all WCAG 2.1, with no apparent room for sites being somewhere between the two. In situations like that, will the site claim conformance to SC 1.3.1 (2.0) or SC 1.3.1 (2.1)? And how do you propose that would work in actual practice?

At issue is the fact that while we are versioning WCAG itself, the Techniques are not being versioned, and because of the "Any meeting of a failure technique = a failure" language we currently have, you are effectively changing the 2.0 interpretation of 1.3.1 by adding this new Technique, whether or not that is the intention.

This is not to say that this WG cannot address this conundrum as part of our current work, but again, given the volume of other things we need to accomplish before next summer, I will suggest that we also need to prioritize our activities accordingly. In my personal opinion, this is fairly low on the list. If you and others disagree, and want to tackle this now, then at a minimum can we poll the WG to see if others agree of that urgency?

I have repeatedly stated that I am not opposed to Failure Techniques (despite my personal feelings about them), but introducing un-versioned Failure Techniques today impact both existing and future conformance claims, which is why I continue to oppose this proposal.

JF

On Sep 22, 2017 5:40 PM, "Katie Haritos-Shea" notifications@github.com wrote:

You mean your definition of backwards compatible? Apparently, nothing.

There are many things that I do not understand about many things in life, John.

I happen to be rather familiar with WCAG 2.0 as well as Conformance claims and general conformance to it.

If/when WCAG 2.1 becomes a W3C Recommendation it will become a NEW standard, in its own right. And as such, new things can fall under existing SC scope. As it should be.

Such as; possibly Landmarks and Regions under 1.3.1, because we are not only addressing LV and COGA issues. We, in 2.1 are also addressing new technologies and paradigms, mobile and otherwise, including new interaction models.

At least, that is my understanding of what we are doing, as I approach my 18th year on this working group.

Those continuing to claim Conformance to 2.0 will fail nothing. Their site will still be 2.0 compliant.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Sep 22, 2017 5:21 PM, "John Foliot" notifications@github.com wrote:

Hi Katie,

What part of Backward Compatibility is unclear to you?

This is a proposed Failure Technique for an existing, WCAG 2.0 SC, which somehow you and David now want to change, mid-stream. Meeting a Failure Technique (whether at 2.0 or 2.1) still means that the content fails, because that's what the documentation says that state means (Content that has a failure does not meet WCAG success criteria).

Currently the Failure Techniques make no distinction to dot-releases, and to preserve backward compat, we cannot change the meaning of current existing SC.

Previously, you wrote:

Does WCAG 2.0 require Headings be used for 1.3.1 for all pages? No.

...and yet, we fail pages all the time because of this, because, in part, of F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text, and the example code:

Introduction

This introduction provides detailed information about how to use this ........

...and the fact that "Content that has a failure does not meet WCAG success criteria".

JF

On Fri, Sep 22, 2017 at 5:09 PM, Katie Haritos-Shea < notifications@github.com> wrote:

Really? I'd be surprised to see the W3C site having a WCAG 2.1 Conformance Claim up somewhere already...

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 5:04 PM, "John Foliot" notifications@github.com wrote:

David, I am not opposed to adding Failure Techniques to the new SC being added to WCAG 2.1 (which is not a "new" spec, as you have previously and erroneously stated, but rather an update to the existing specification, which is what dot-releases are.) In fact, I have explicitly stated as such as part of this discussion, when Laura asked me "*John, would you categorically oppose any new WCAG failure techniques going forward?*" (My response was an emphatic No. - https://github.com/w3c/wcag21/issues/310#issuecomment- 318435035) Your desire to add this new failure technique however is fundamentally impacting existing web content, whether you are prepared to admit it or not. For example, with the addition of your proposal, it would automatically make the W3C web site non-conformant. (Go to w3.org, and search the source code for role="search", which is clearly visually present on the page, and quite discernible to non-sighted users too [1].) However, it would instantly fail with the addition of your retroactive Failure Technique (due to the lack of role="search"), and the language I have repeatedly quoted stating "*Content that has a failure does not meet WCAG success criteria*". I didn't write that, I'm not fully on-board with how that statement was crafted, but that is what cleared the bar with the publication of WCAG 2.0, so that is what we have to live with today.) Additionally, your own website at http://www.davidmacd.com/#endorse would also fail your proposed Failure Technique, as the testimonials are all in non-semantic divs (

), as opposed to ("The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable"). That may not be the intent of your proposal, but it is certainly a clear example of the potential unintended consequences of your proposal. > This failure technique is proposed for WCAG 2.1, not because it doesn't apply to 2.0 but because there is almost no possible way to get a failure into WCAG 2... This seems to indicate ​ to me that you ​may ​ have a fundamental misunderstanding over what we are doing with the dot-release of WCAG ​, and how the W3C as a standards organization approaches dot-releases​ ​. We are not creating a new specification, we are updating the existing specification incrementally, adding new SC to cover areas missed in the 2.0 time-frame/work-effort. This is what our charter states : The WCAG 2.1 update will be an incremental update to WCAG 2.0 rather than a major revision. WCAG 2.1 is designed to build on the WCAG 2.0 recommendation to ensure testability and technology independence, *and will also ensure backward compatibility with WCAG 2.0.* Work on something "new" (a major revision) is what Project Silver is for and about.​ ​So yes, any attempt to reframe or add additional requirements on existing 2.0 SC that breaks or negatively impacts backward compatibility will be strenuously objected to, at least by me.​ You have been very transparent in the past on your motivation for this, stating that one of your clients won't use landmark regions unless there is a Failure Technique for that. Attempting to use WCAG to advance your own agenda, or to add usability enhancements is a wrong application of WCAG, which is supposed to be about removing barriers [2], not 'sweetening' user experiences. That may seem cold and callous, but because our specification is also referenced in legislations, we need to remain steeled to these ideas, as sad as they may be. As I have repeatedly stated, I would support in a heartbeat a new Success Technique that showed how using HTML5 landmarks could address requirements of 1.3.1 (a companion to the existing ARIA11: Using ARIA landmarks to identify regions of a page ), but for the reasons stated above, I will remain firm in my resolve to reject this proposed Failure Technique in any 2.x work ​JF [1] (I am far from suggesting this is perfect, but it does not introduce a barrier to any user that I can determine, despite my reservation over the use of the positive integer for the tabindex attribute. David's proposal would fail this, and subsequently the entire page, for lack of a wrapper div with role="search" applied.) [2] *Failures are things that cause accessibility barriers* (JF: and *not* poor user-experiences) (https://www.w3.org/TR/UNDERSTANDING-WCAG20/ understanding-techniques.html# ut-understanding-techniques-failures-head) On Fri, Sep 22, 2017 at 12:39 PM, David MacDonald < notifications@github.com> wrote: > a) Some pages will not need landmarks b) Some pages that are already > compliant to WCAG 2.0 that lack landmarkelements or roles today, would > suddenly become non-compliant with the > introduction of the Failure Technique. > > No, If a page does not have any visual indication of one of these regions > there is no requirement for a non visual indicator. I find it astonishing > that this is not understood, as it is part of the SC language. Do you have > a recommendation to make it clearer? > > This failure technique is proposed for WCAG 2.1, not because it doesn't > apply to 2.0 but because there is almost no possible way to get a failure > into WCAG 2 even though WCAG was intended to grow with technology. > > Regarding the work ahead of us, I'm quite surprised that this failure is > experiencing such a struggle from a few. In my opinion it should have been > a rubber stamp, with perhaps some tweaks to address concerns. The 10 hours > I spent on it last year was over twice the time I put into the dozens of > failures I had previously written for WCAG 2. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or mute > the thread > > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or

mute

the thread https://github.com/notifications/unsubscribe-auth/ AFfqyhjYWl5LkRtFqKzoZMWz9dfIqE2-ks5slCDSgaJpZM4OfpuQ .

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331561228, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c8- eeB8D8sUK3vxl6cmjNoU0Da_xks5slCH9gaJpZM4OfpuQ

.

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

Advancing the mission of digital accessibility and inclusion

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331563541, or mute the thread https://github.com/notifications/unsubscribe- auth/AFfqykzo0-ovP78mDBeuL2hO-iMqZ0yMks5slCTSgaJpZM4OfpuQ .

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

[Ryladog]

The way I propose it would be handled is that organizations will conform to either WCAG 1.0, 2.0, or 2.1.

Katie Haritos-Shea 703-371-5545

On Sep 22, 2017 7:04 PM, "John Foliot" notifications@github.com wrote:

Once again, I am hearing an assumption that sites will either be all WCAG 2.O or all WCAG 2.1, with no apparent room for sites being somewhere between the two. In situations like that, will the site claim conformance to SC 1.3.1 (2.0) or SC 1.3.1 (2.1)? And how do you propose that would work in actual practice?

At issue is the fact that while we are versioning WCAG itself, the Techniques are not being versioned, and because of the "Any meeting of a failure technique = a failure" language we currently have, you are effectively changing the 2.0 interpretation of 1.3.1 by adding this new Technique, whether or not that is the intention.

This is not to say that this WG cannot address this conundrum as part of our current work, but again, given the volume of other things we need to accomplish before next summer, I will suggest that we also need to prioritize our activities accordingly. In my personal opinion, this is fairly low on the list. If you and others disagree, and want to tackle this now, then at a minimum can we poll the WG to see if others agree of that urgency?

I have repeatedly stated that I am not opposed to Failure Techniques (despite my personal feelings about them), but introducing un-versioned Failure Techniques today impact both existing and future conformance claims, which is why I continue to oppose this proposal.

JF

On Sep 22, 2017 5:40 PM, "Katie Haritos-Shea" notifications@github.com wrote:

You mean your definition of backwards compatible? Apparently, nothing.

There are many things that I do not understand about many things in life, John.

I happen to be rather familiar with WCAG 2.0 as well as Conformance claims and general conformance to it.

If/when WCAG 2.1 becomes a W3C Recommendation it will become a NEW standard, in its own right. And as such, new things can fall under existing SC scope. As it should be.

Such as; possibly Landmarks and Regions under 1.3.1, because we are not only addressing LV and COGA issues. We, in 2.1 are also addressing new technologies and paradigms, mobile and otherwise, including new interaction models.

At least, that is my understanding of what we are doing, as I approach my 18th year on this working group.

Those continuing to claim Conformance to 2.0 will fail nothing. Their site will still be 2.0 compliant.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 5:21 PM, "John Foliot" notifications@github.com wrote:

Hi Katie,

What part of Backward Compatibility is unclear to you?

This is a proposed Failure Technique for an existing, WCAG 2.0 SC, which somehow you and David now want to change, mid-stream. Meeting a Failure Technique (whether at 2.0 or 2.1) still means that the content fails, because that's what the documentation says that state means (Content that has a failure does not meet WCAG success criteria).

Currently the Failure Techniques make no distinction to dot-releases, and to preserve backward compat, we cannot change the meaning of current existing SC.

Previously, you wrote:

Does WCAG 2.0 require Headings be used for 1.3.1 for all pages? No.

...and yet, we fail pages all the time because of this, because, in part, of F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text, and the example code:

Introduction

This introduction provides detailed information about how to use this ........

...and the fact that "Content that has a failure does not meet WCAG success criteria".

JF

On Fri, Sep 22, 2017 at 5:09 PM, Katie Haritos-Shea < notifications@github.com> wrote:

Really? I'd be surprised to see the W3C site having a WCAG 2.1 Conformance Claim up somewhere already...

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 5:04 PM, "John Foliot" notifications@github.com wrote:

David, I am not opposed to adding Failure Techniques to the new SC being added to WCAG 2.1 (which is not a "new" spec, as you have previously and erroneously stated, but rather an update to the existing specification, which is what dot-releases are.) In fact, I have explicitly stated as such as part of this discussion, when Laura asked me "*John, would you categorically oppose any new WCAG failure techniques going forward?*" (My response was an emphatic No. - https://github.com/w3c/wcag21/ issues/310#issuecomment- 318435035) Your desire to add this new failure technique however is fundamentally impacting existing web content, whether you are prepared to admit it or not. For example, with the addition of your proposal, it would automatically make the W3C web site non-conformant. (Go to w3.org, and search the source code for role="search", which is clearly visually present on the page, and quite discernible to non-sighted users too [1].) However, it would instantly fail with the addition of your retroactive Failure Technique (due to the lack of role="search"), and the language I have repeatedly quoted stating "*Content that has a failure does not meet WCAG success criteria*". I didn't write that, I'm not fully on-board with how that statement was crafted, but that is what cleared the bar with the publication of WCAG 2.0, so that is what we have to live with today.) Additionally, your own website at http://www.davidmacd.com/#endorse would also fail your proposed Failure Technique, as the testimonials are all in non-semantic divs (

), as opposed to ("The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable"). That may not be the intent of your proposal, but it is certainly a clear example of the potential unintended consequences of your proposal. > This failure technique is proposed for WCAG 2.1, not because it doesn't apply to 2.0 but because there is almost no possible way to get a failure into WCAG 2... This seems to indicate ​ to me that you ​may ​ have a fundamental misunderstanding over what we are doing with the dot-release of WCAG ​, and how the W3C as a standards organization approaches dot-releases​ ​. We are not creating a new specification, we are updating the existing specification incrementally, adding new SC to cover areas missed in the 2.0 time-frame/work-effort. This is what our charter states : The WCAG 2.1 update will be an incremental update to WCAG 2.0 rather than a major revision. WCAG 2.1 is designed to build on the WCAG 2.0 recommendation to ensure testability and technology independence, *and will also ensure backward compatibility with WCAG 2.0.* Work on something "new" (a major revision) is what Project Silver is for and about.​ ​So yes, any attempt to reframe or add additional requirements on existing 2.0 SC that breaks or negatively impacts backward compatibility will be strenuously objected to, at least by me.​ You have been very transparent in the past on your motivation for this, stating that one of your clients won't use landmark regions unless there is a Failure Technique for that. Attempting to use WCAG to advance your own agenda, or to add usability enhancements is a wrong application of WCAG, which is supposed to be about removing barriers [2], not 'sweetening' user experiences. That may seem cold and callous, but because our specification is also referenced in legislations, we need to remain steeled to these ideas, as sad as they may be. As I have repeatedly stated, I would support in a heartbeat a new Success Technique that showed how using HTML5 landmarks could address requirements of 1.3.1 (a companion to the existing ARIA11: Using ARIA landmarks to identify regions of a page ), but for the reasons stated above, I will remain firm in my resolve to reject this proposed Failure Technique in any 2.x work ​JF [1] (I am far from suggesting this is perfect, but it does not introduce a barrier to any user that I can determine, despite my reservation over the use of the positive integer for the tabindex attribute. David's proposal would fail this, and subsequently the entire page, for lack of a wrapper div with role="search" applied.) [2] *Failures are things that cause accessibility barriers* (JF: and *not* poor user-experiences) (https://www.w3.org/TR/UNDERSTANDING-WCAG20/ understanding-techniques.html# ut-understanding-techniques-failures-head) On Fri, Sep 22, 2017 at 12:39 PM, David MacDonald < notifications@github.com> wrote: > a) Some pages will not need landmarks b) Some pages that are already > compliant to WCAG 2.0 that lack landmarkelements or roles today, would > suddenly become non-compliant with the > introduction of the Failure Technique. > > No, If a page does not have any visual indication of one of these regions > there is no requirement for a non visual indicator. I find it astonishing > that this is not understood, as it is part of the SC language. Do you have > a recommendation to make it clearer? > > This failure technique is proposed for WCAG 2.1, not because it doesn't > apply to 2.0 but because there is almost no possible way to get a failure > into WCAG 2 even though WCAG was intended to grow with technology. > > Regarding the work ahead of us, I'm quite surprised that this failure is > experiencing such a struggle from a few. In my opinion it should have been > a rubber stamp, with perhaps some tweaks to address concerns. The 10 hours > I spent on it last year was over twice the time I put into the dozens of > failures I had previously written for WCAG 2. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or mute > the thread > > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or

mute

the thread https://github.com/notifications/unsubscribe-auth/ AFfqyhjYWl5LkRtFqKzoZMWz9dfIqE2-ks5slCDSgaJpZM4OfpuQ .

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331561228, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c8- eeB8D8sUK3vxl6cmjNoU0Da_xks5slCH9gaJpZM4OfpuQ

.

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

Advancing the mission of digital accessibility and inclusion

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331563541, or mute the thread https://github.com/notifications/unsubscribe- auth/AFfqykzo0-ovP78mDBeuL2hO-iMqZ0yMks5slCTSgaJpZM4OfpuQ .

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

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

[Ryladog]

I am sure we all recall David's suggestion long ago to version techniques. Marking the failure as a 2.1 technique for 1.3.1 doesn't seem like a difficult task. All Techniques developed for 2.1 new SCs will need that identifier' anyway right?

Katie Haritos-Shea 703-371-5545

On Sep 22, 2017 7:33 PM, "Katie Haritos-Shea" ryladog@gmail.com wrote:

The way I propose it would be handled is that organizations will conform to either WCAG 1.0, 2.0, or 2.1.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545>

On Sep 22, 2017 7:04 PM, "John Foliot" notifications@github.com wrote:

Once again, I am hearing an assumption that sites will either be all WCAG 2.O or all WCAG 2.1, with no apparent room for sites being somewhere between the two. In situations like that, will the site claim conformance to SC 1.3.1 (2.0) or SC 1.3.1 (2.1)? And how do you propose that would work in actual practice?

At issue is the fact that while we are versioning WCAG itself, the Techniques are not being versioned, and because of the "Any meeting of a failure technique = a failure" language we currently have, you are effectively changing the 2.0 interpretation of 1.3.1 by adding this new Technique, whether or not that is the intention.

This is not to say that this WG cannot address this conundrum as part of our current work, but again, given the volume of other things we need to accomplish before next summer, I will suggest that we also need to prioritize our activities accordingly. In my personal opinion, this is fairly low on the list. If you and others disagree, and want to tackle this now, then at a minimum can we poll the WG to see if others agree of that urgency?

I have repeatedly stated that I am not opposed to Failure Techniques (despite my personal feelings about them), but introducing un-versioned Failure Techniques today impact both existing and future conformance claims, which is why I continue to oppose this proposal.

JF

On Sep 22, 2017 5:40 PM, "Katie Haritos-Shea" notifications@github.com wrote:

You mean your definition of backwards compatible? Apparently, nothing.

There are many things that I do not understand about many things in life, John.

I happen to be rather familiar with WCAG 2.0 as well as Conformance claims and general conformance to it.

If/when WCAG 2.1 becomes a W3C Recommendation it will become a NEW standard, in its own right. And as such, new things can fall under existing SC scope. As it should be.

Such as; possibly Landmarks and Regions under 1.3.1, because we are not only addressing LV and COGA issues. We, in 2.1 are also addressing new technologies and paradigms, mobile and otherwise, including new interaction models.

At least, that is my understanding of what we are doing, as I approach my 18th year on this working group.

Those continuing to claim Conformance to 2.0 will fail nothing. Their site will still be 2.0 compliant.

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 5:21 PM, "John Foliot" notifications@github.com wrote:

Hi Katie,

What part of Backward Compatibility is unclear to you?

This is a proposed Failure Technique for an existing, WCAG 2.0 SC, which somehow you and David now want to change, mid-stream. Meeting a Failure Technique (whether at 2.0 or 2.1) still means that the content fails, because that's what the documentation says that state means (Content that has a failure does not meet WCAG success criteria).

Currently the Failure Techniques make no distinction to dot-releases, and to preserve backward compat, we cannot change the meaning of current existing SC.

Previously, you wrote:

Does WCAG 2.0 require Headings be used for 1.3.1 for all pages? No.

...and yet, we fail pages all the time because of this, because, in part, of F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text, and the example code:

Introduction

This introduction provides detailed information about how to use this ........

...and the fact that "Content that has a failure does not meet WCAG success criteria".

JF

On Fri, Sep 22, 2017 at 5:09 PM, Katie Haritos-Shea < notifications@github.com> wrote:

Really? I'd be surprised to see the W3C site having a WCAG 2.1 Conformance Claim up somewhere already...

Katie Haritos-Shea 703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 5:04 PM, "John Foliot" notifications@github.com wrote:

David, I am not opposed to adding Failure Techniques to the new SC being added to WCAG 2.1 (which is not a "new" spec, as you have previously and erroneously stated, but rather an update to the existing specification, which is what dot-releases are.) In fact, I have explicitly stated as such as part of this discussion, when Laura asked me "*John, would you categorically oppose any new WCAG failure techniques going forward?*" (My response was an emphatic No. - https://github.com/w3c/wcag21/ issues/310#issuecomment- 318435035) Your desire to add this new failure technique however is fundamentally impacting existing web content, whether you are prepared to admit it or not. For example, with the addition of your proposal, it would automatically make the W3C web site non-conformant. (Go to w3.org, and search the source code for role="search", which is clearly visually present on the page, and quite discernible to non-sighted users too [1].) However, it would instantly fail with the addition of your retroactive Failure Technique (due to the lack of role="search"), and the language I have repeatedly quoted stating "*Content that has a failure does not meet WCAG success criteria*". I didn't write that, I'm not fully on-board with how that statement was crafted, but that is what cleared the bar with the publication of WCAG 2.0, so that is what we have to live with today.) Additionally, your own website at http://www.davidmacd.com/#endorse would also fail your proposed Failure Technique, as the testimonials are all in non-semantic divs (

), as opposed to ("The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable"). That may not be the intent of your proposal, but it is certainly a clear example of the potential unintended consequences of your proposal. > This failure technique is proposed for WCAG 2.1, not because it doesn't apply to 2.0 but because there is almost no possible way to get a failure into WCAG 2... This seems to indicate ​ to me that you ​may ​ have a fundamental misunderstanding over what we are doing with the dot-release of WCAG ​, and how the W3C as a standards organization approaches dot-releases​ ​. We are not creating a new specification, we are updating the existing specification incrementally, adding new SC to cover areas missed in the 2.0 time-frame/work-effort. This is what our charter states : The WCAG 2.1 update will be an incremental update to WCAG 2.0 rather than a major revision. WCAG 2.1 is designed to build on the WCAG 2.0 recommendation to ensure testability and technology independence, *and will also ensure backward compatibility with WCAG 2.0.* Work on something "new" (a major revision) is what Project Silver is for and about.​ ​So yes, any attempt to reframe or add additional requirements on existing 2.0 SC that breaks or negatively impacts backward compatibility will be strenuously objected to, at least by me.​ You have been very transparent in the past on your motivation for this, stating that one of your clients won't use landmark regions unless there is a Failure Technique for that. Attempting to use WCAG to advance your own agenda, or to add usability enhancements is a wrong application of WCAG, which is supposed to be about removing barriers [2], not 'sweetening' user experiences. That may seem cold and callous, but because our specification is also referenced in legislations, we need to remain steeled to these ideas, as sad as they may be. As I have repeatedly stated, I would support in a heartbeat a new Success Technique that showed how using HTML5 landmarks could address requirements of 1.3.1 (a companion to the existing ARIA11: Using ARIA landmarks to identify regions of a page ), but for the reasons stated above, I will remain firm in my resolve to reject this proposed Failure Technique in any 2.x work ​JF [1] (I am far from suggesting this is perfect, but it does not introduce a barrier to any user that I can determine, despite my reservation over the use of the positive integer for the tabindex attribute. David's proposal would fail this, and subsequently the entire page, for lack of a wrapper div with role="search" applied.) [2] *Failures are things that cause accessibility barriers* (JF: and *not* poor user-experiences) (https://www.w3.org/TR/UNDERSTANDING-WCAG20/ understanding-techniques.html# ut-understanding-techniques-failures-head) On Fri, Sep 22, 2017 at 12:39 PM, David MacDonald < notifications@github.com> wrote: > a) Some pages will not need landmarks b) Some pages that are already > compliant to WCAG 2.0 that lack landmarkelements or roles today, would > suddenly become non-compliant with the > introduction of the Failure Technique. > > No, If a page does not have any visual indication of one of these regions > there is no requirement for a non visual indicator. I find it astonishing > that this is not understood, as it is part of the SC language. Do you have > a recommendation to make it clearer? > > This failure technique is proposed for WCAG 2.1, not because it doesn't > apply to 2.0 but because there is almost no possible way to get a failure > into WCAG 2 even though WCAG was intended to grow with technology. > > Regarding the work ahead of us, I'm quite surprised that this failure is > experiencing such a struggle from a few. In my opinion it should have been > a rubber stamp, with perhaps some tweaks to address concerns. The 10 hours > I spent on it last year was over twice the time I put into the dozens of > failures I had previously written for WCAG 2. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > the thread > > . > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or

mute

the thread https://github.com/notifications/unsubscribe-auth/ AFfqyhjYWl5LkRtFqKzoZMWz9dfIqE2-ks5slCDSgaJpZM4OfpuQ .

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331561228, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c8- eeB8D8sUK3vxl6cmjNoU0Da_xks5slCH9gaJpZM4OfpuQ

.

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

Advancing the mission of digital accessibility and inclusion

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/310#issuecomment-331563541, or mute the thread https://github.com/notifications/unsubscribe- auth/AFfqykzo0-ovP78mDBeuL2hO-iMqZ0yMks5slCTSgaJpZM4OfpuQ .

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

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

[johnfoliot]

I am sure we all recall David's suggestion long ago to version techniques. I don't. (Source / citation?) His latest revisitation made no mention of versioning. Does this WG have consensus on this approach? Marking the failure as a 2.1 technique for 1.3.1 doesn't seem like a difficult task.  No, but it is a new idea. What is (or will be) the impact of that decision on existing non-versioned Techniques? Will only Failure Techniques be versioned, or will we extend that to Advisory and Success Techniques too? Has anybody calculated the cost of those proposed changes? This certainly seems worthwhile discussing, but I think we are still far from assuming that this idea is a given. All Techniques developed for 2.1 new SCs will need that identifier' anyway right? All Techniques are currently numbered, but current numbering has no visible indication of a versioning concept, so, again what would be the impact of the WG's decision here? I would support discussing this idea amongst the larger WG, but until then I think this remains an open question.  JF

[Ryladog]

The impact is that Techniques created for WCAG 2.1 new SC cannot/will-not be applicable to WCAG 2.0. Nothing magical or needing of difficult consensus there, I don't think.

For new Techniques for existing WCAG 2.0 SCs in WCAG 2.1 (like possibly page regions/landmarks for 1.3.1), they would also need that 2.1 identifier' attached.

Doesn't seem too complex to me.

Katie Haritos-Shea 703-371-5545

On Sep 23, 2017 10:03 AM, "John Foliot" notifications@github.com wrote:

I am sure we all recall David's suggestion long ago to version techniques. I don't. (Source / citation?) His latest revisitation made no mention of versioning. Does this WG have consensus on this approach? Marking the failure as a 2.1 technique for 1.3.1 doesn't seem like a difficult task. No, but it is a new idea. What is (or will be) the impact of that decision on existing non-versioned Techniques? Will only Failure Techniques be versioned, or will we extend that to Advisory and Success Techniques too? Has anybody calculated the cost of those proposed changes? This certainly seems worthwhile discussing, but I think we are still far from assuming that this idea is a given. All Techniques developed for 2.1 new SCs will need that identifier' anyway right? All Techniques are currently numbered, but current numbering has no visible indication of a versioning concept, so, again what would be the impact of the WG's decision here? I would support discussing this idea amongst the larger WG, but until then I think this remains an open question. JF Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Katie Haritos-Shea < notifications@github.com> Date: 9/23/17 8:18 AM (GMT-05:00) To: w3c/wcag21 wcag21@noreply.github.com Cc: John Foliot < john.foliot@deque.com>, Mention mention@noreply.github.com Subject: Re: [w3c/wcag21] Failure Technique around page regions (Header, Footer, Nav, Main etc.) (#310) I am sure we all recall David's suggestion long ago to version techniques.

Marking the failure as a 2.1 technique for 1.3.1 doesn't seem like a

difficult task. All Techniques developed for 2.1 new SCs will need that

identifier' anyway right?

Katie Haritos-Shea

703-371-5545 <(703)%20371-5545>

On Sep 22, 2017 7:33 PM, "Katie Haritos-Shea" ryladog@gmail.com wrote:

The way I propose it would be handled is that organizations will conform

to either WCAG 1.0, 2.0, or 2.1.

Katie Haritos-Shea

703-371-5545 <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 7:04 PM, "John Foliot" notifications@github.com wrote:

Once again, I am hearing an assumption that sites will either be all WCAG

2.O or all WCAG 2.1, with no apparent room for sites being somewhere

between the two. In situations like that, will the site claim conformance

to SC 1.3.1 (2.0) or SC 1.3.1 (2.1)? And how do you propose that would

work

in actual practice?

At issue is the fact that while we are versioning WCAG itself, the

Techniques are not being versioned, and because of the "Any meeting of a

failure technique = a failure" language we currently have, you are

effectively changing the 2.0 interpretation of 1.3.1 by adding this new

Technique, whether or not that is the intention.

This is not to say that this WG cannot address this conundrum as part of

our current work, but again, given the volume of other things we need to

accomplish before next summer, I will suggest that we also need to

prioritize our activities accordingly. In my personal opinion, this is

fairly low on the list. If you and others disagree, and want to tackle

this

now, then at a minimum can we poll the WG to see if others agree of that

urgency?

I have repeatedly stated that I am not opposed to Failure Techniques

(despite my personal feelings about them), but introducing un-versioned

Failure Techniques today impact both existing and future conformance

claims, which is why I continue to oppose this proposal.

JF

On Sep 22, 2017 5:40 PM, "Katie Haritos-Shea" <notifications@github.com

wrote:

You mean your definition of backwards compatible? Apparently, nothing.

There are many things that I do not understand about many things in

life,

John.

I happen to be rather familiar with WCAG 2.0 as well as Conformance

claims

and general conformance to it.

If/when WCAG 2.1 becomes a W3C Recommendation it will become a NEW

standard, in its own right. And as such, new things can fall under

existing

SC scope. As it should be.

Such as; possibly Landmarks and Regions under 1.3.1, because we are not

only addressing LV and COGA issues. We, in 2.1 are also addressing new

technologies and paradigms, mobile and otherwise, including new

interaction

models.

At least, that is my understanding of what we are doing, as I approach

my

18th year on this working group.

Those continuing to claim Conformance to 2.0 will fail nothing. Their

site

will still be 2.0 compliant.

Katie Haritos-Shea

703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 5:21 PM, "John Foliot" notifications@github.com

wrote:

Hi Katie,

What part of Backward Compatibility is unclear to you?

This is a proposed Failure Technique for an existing, WCAG 2.0 SC, which

somehow you and David now want to change, mid-stream. Meeting a Failure

Technique (whether at 2.0 or 2.1) still means that the content fails,

because that's what the documentation says that state means (*Content

that

has a failure does not meet WCAG success criteria*).

Currently the Failure Techniques make no distinction to dot-releases,

and

to preserve backward compat, we cannot change the meaning of current

existing SC.

Previously, you wrote:

Does WCAG 2.0 require Headings be used for 1.3.1 for all pages? No.

...and yet, we fail pages all the time because of this, because, in

part,

of *F2: Failure of Success Criterion 1.3.1 due to using changes in text

presentation to convey information without using the appropriate markup

or

text,* and the example code:

Introduction

This introduction provides detailed information about how to use this ........

...and the fact that "Content that has a failure does not meet WCAG

success

criteria".

JF

On Fri, Sep 22, 2017 at 5:09 PM, Katie Haritos-Shea <

notifications@github.com> wrote:

Really? I'd be surprised to see the W3C site having a WCAG 2.1

Conformance

Claim up somewhere already...

Katie Haritos-Shea

703-371-5545 <(703)%20371-5545> <(703)%20371-5545> <(703)%20371-5545>

<(703)%20371-5545> <(703)%20371-5545>

On Sep 22, 2017 5:04 PM, "John Foliot" notifications@github.com

wrote:

David, I am not opposed to adding Failure Techniques to the new SC being

added

to

WCAG 2.1 (which is not a "new" spec, as you have previously and

erroneously

stated, but rather an update to the existing specification, which is

what

dot-releases are.) In fact, I have explicitly stated as such as

part of

this discussion, when Laura asked me "*John, would you categorically

oppose

any new WCAG failure techniques going forward?*" (My response was an

emphatic No. - https://github.com/w3c/wcag21/

issues/310#issuecomment-

318435035)

Your desire to add this new failure technique however is

fundamentally

impacting existing web content, whether you are prepared to admit

it or

not. For example, with the addition of your proposal, it would

automatically make the W3C web site non-conformant. (Go to w3.org ,

and

search the source code for role="search", which is clearly visually

present

on the page, and quite discernible to non-sighted users too [1].)

However, it would instantly fail with the addition of your

retroactive

Failure Technique (due to the lack of role="search"), and the

language

I

have repeatedly quoted

<https://www.w3.org/TR/UNDERSTANDING-WCAG20/

understanding-techniques.html#

ut-understanding-techniques-failures-head>

stating "*Content that has a failure does not meet WCAG success

criteria*". I

didn't write that, I'm not fully on-board with how that statement

was

crafted, but that is what cleared the bar with the publication of

WCAG

2.0,

so that is what we have to live with today.)

Additionally, your own website at http://www.davidmacd.com/# endorse

would

also fail your proposed Failure Technique, as the testimonials are

all

in

non-semantic divs (

), as opposed to

> >

("The

article element represents a complete, or self-contained,

composition

in

a

document, page, application, or site and that is, in principle,

independently distributable or reusable"). That may not be the

intent

of

your proposal, but it is certainly a clear example of the potential

unintended consequences of your proposal.

This failure technique is proposed for WCAG 2.1, not because it

doesn't

apply to 2.0 but because there is almost no possible way to get a

failure

into WCAG 2...

This seems to indicate

​

to me that you

​may ​

have a fundamental misunderstanding over what we are doing with the

dot-release of WCAG

​, and how the W3C as a standards organization approaches

dot-releases​

​. We are not creating a new specification, we are updating the

existing

specification incrementally, adding new SC to cover areas missed in

the

2.0

time-frame/work-effort. This is what our charter states

https://www.w3.org/2017/01/ag-charter:

The WCAG 2.1 update will be an incremental update to WCAG 2.0 rather

than a

major revision.

WCAG 2.1 is designed to build on the WCAG 2.0 recommendation to

ensure

testability and technology independence, *and will also ensure

backward

compatibility with WCAG 2.0.*

Work on something "new" (a major revision) is what Project Silver is

for

and about.​

​So yes, any attempt to reframe or add additional requirements on

existing

2.0 SC that breaks or negatively impacts backward compatibility

will be

strenuously objected to, at least by me.​

You have been very transparent in the past on your motivation for

this,

stating that one of your clients won't use landmark regions unless

there

is

a Failure Technique for that. Attempting to use WCAG to advance your

own

agenda, or to add usability enhancements is a wrong application of

WCAG,

which is supposed to be about removing barriers [2], not

'sweetening'

user

experiences. That may seem cold and callous, but because our

specification

is also referenced in legislations, we need to remain steeled to

these

ideas, as sad as they may be.

As I have repeatedly stated, I would support in a heartbeat a new

Success

Technique that showed how using HTML5 landmarks could address

requirements

of 1.3.1 (a companion to the existing ARIA11: Using ARIA landmarks

to

identify regions of a page <https://www.w3.org/TR/WCAG20-

TECHS/ARIA11.html

),

but for the reasons stated above, I will remain firm in my resolve

to

reject this proposed Failure Technique in any 2.x work

​JF

[1] <input tabindex="3" class="text" name="q" value=""

title="Search">

(I am far from suggesting this is perfect, but it does not

introduce a

barrier to any user that I can determine, despite my reservation

over

the

use of the positive integer for the tabindex attribute. David's

proposal

would fail this, and subsequently the entire page, for lack of a

wrapper

div with role="search" applied.)

[2] Failures are things that cause accessibility barriers (JF: and

not

poor user-experiences)

(https://www.w3.org/TR/UNDERSTANDING-WCAG20/

understanding-techniques.html#

ut-understanding-techniques-failures-head)

On Fri, Sep 22, 2017 at 12:39 PM, David MacDonald <

notifications@github.com>

wrote:

a) Some pages will not need landmarks b) Some pages that are

already

compliant to WCAG 2.0 that lack landmarkelements or roles today,

would

suddenly become non-compliant with the

introduction of the Failure Technique.

No, If a page does not have any visual indication of one of these

regions

there is no requirement for a non visual indicator. I find it

astonishing

that this is not understood, as it is part of the SC language. Do

you

have

a recommendation to make it clearer?

This failure technique is proposed for WCAG 2.1, not because it

doesn't

apply to 2.0 but because there is almost no possible way to get a

failure

into WCAG 2 even though WCAG was intended to grow with technology.

Regarding the work ahead of us, I'm quite surprised that this

failure

is

experiencing such a struggle from a few. In my opinion it should

have

been

a rubber stamp, with perhaps some tweaks to address concerns. The

10

hours

I spent on it last year was over twice the time I put into the

dozens

of

failures I had previously written for WCAG 2.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub

<https://github.com/w3c/wcag21/issues/310# issuecomment-331497881

,

or

mute

the thread

<https://github.com/notifications/unsubscribe-

auth/ABK-c9yCBVAkmios76aJj-EMI3z73VnGks5sk-KlgaJpZM4OfpuQ>

.

--

John Foliot

Principal Accessibility Strategist

Deque Systems Inc.

john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub

<https://github.com/w3c/wcag21/issues/310#issuecomment-331560173 ,

or

mute

the thread

<https://github.com/notifications/unsubscribe-auth/

AFfqyhjYWl5LkRtFqKzoZMWz9dfIqE2-ks5slCDSgaJpZM4OfpuQ>

.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub

https://github.com/w3c/wcag21/issues/310#issuecomment-331561228, or

mute

the thread

<https://github.com/notifications/unsubscribe-auth/ABK-c8-

eeB8D8sUK3vxl6cmjNoU0Da_xks5slCH9gaJpZM4OfpuQ>

.

--

John Foliot

Principal Accessibility Strategist

Deque Systems Inc.

john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub

https://github.com/w3c/wcag21/issues/310#issuecomment-331563541, or

mute

the thread

<https://github.com/notifications/unsubscribe-

auth/AFfqykzo0-ovP78mDBeuL2hO-iMqZ0yMks5slCTSgaJpZM4OfpuQ>

.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub

https://github.com/w3c/wcag21/issues/310#issuecomment-331566974, or

mute

the thread

<https://github.com/notifications/unsubscribe-auth/ABK-c3N7Q

D2D4zuv3ClTpI2MfaAlGFfYks5slCkzgaJpZM4OfpuQ>

.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub

https://github.com/w3c/wcag21/issues/310#issuecomment-331579832, or mute

the thread

https://github.com/notifications/unsubscribe-auth/AFfqyu7MTEjuC_ YpsNRJ2oMl6Zy9lyQhks5slD0LgaJpZM4OfpuQ

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

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