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

[michael-n-cooper]

From @DavidMacDonald on July 21, 2017 16:58

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.

Copied from original issue: w3c/wcag21#310

[michael-n-cooper]

From @johnfoliot on July 21, 2017 18:16

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

[michael-n-cooper]

From @Ryladog on July 21, 2017 19:39

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 .

[michael-n-cooper]

From @Ryladog on July 21, 2017 19:48

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 .

[michael-n-cooper]

From @kerstinp on July 22, 2017 8:43

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).

[michael-n-cooper]

From @johnfoliot on July 22, 2017 14:18

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

[michael-n-cooper]

From @Ryladog on July 22, 2017 18:40

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 .

[michael-n-cooper]

From @patrickhlauke on July 23, 2017 7:49

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.

[michael-n-cooper]

From @Ryladog on July 25, 2017 11:59

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 .

[michael-n-cooper]

From @patrickhlauke on July 25, 2017 14:10

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.

[michael-n-cooper]

From @Ryladog on July 25, 2017 14:33

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 .

[michael-n-cooper]

From @patrickhlauke on July 25, 2017 14:41

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.

[michael-n-cooper]

From @johnfoliot on July 25, 2017 15:44

+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

[michael-n-cooper]

From @Ryladog on July 25, 2017 16:30

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

[michael-n-cooper]

From @patrickhlauke on July 25, 2017 18:29

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.

[michael-n-cooper]

From @detlevhfischer on July 26, 2017 7:27

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.

[michael-n-cooper]

From @lauracarlson on July 27, 2017 13:20

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

[michael-n-cooper]

From @patrickhlauke on July 27, 2017 15:35

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.

[michael-n-cooper]

From @johnfoliot on July 27, 2017 17:44

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

[michael-n-cooper]

From @lauracarlson on July 27, 2017 20:6

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

[michael-n-cooper]

From @patrickhlauke on July 27, 2017 20:11

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

[michael-n-cooper]

From @DavidMacDonald on July 28, 2017 20:59

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.

[michael-n-cooper]

From @jake-abma on September 17, 2017 9:32

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.

[michael-n-cooper]

From @Ryladog on September 17, 2017 15:9

+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 .

[michael-n-cooper]

From @detlevhfischer on September 17, 2017 16:8

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.

[michael-n-cooper]

From @johnfoliot on September 17, 2017 16:21

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

[michael-n-cooper]

From @jake-abma on September 17, 2017 16:21

@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.

[michael-n-cooper]

From @detlevhfischer on September 17, 2017 16:24

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.

[michael-n-cooper]

From @jake-abma on September 17, 2017 16:39

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… :-(

[michael-n-cooper]

From @johnfoliot on September 17, 2017 16:53

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

[michael-n-cooper]

From @DavidMacDonald on September 22, 2017 11:51

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.

[michael-n-cooper]

From @jake-abma on September 22, 2017 13:10

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?

[michael-n-cooper]

From @Ryladog on September 22, 2017 13:17

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 .

[michael-n-cooper]

From @johnfoliot on September 22, 2017 13:55

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

[michael-n-cooper]

From @Ryladog on September 22, 2017 14:12

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 .

[michael-n-cooper]

From @johnfoliot on September 22, 2017 14:27

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

[michael-n-cooper]

This issue did not port properly. Check w3c/wcag21#310 for the remainder of the context.

[LiLoDavis]

Could this failure technique address incorrect landmarks? Some examples:

• An area that functions as a banner has role="contentinfo"
• Some of the page's primary content is not included in the main landmark
• The main landmark contains content that repeats on multiple pages

[jake-abma]

Hi @LiLoDavis

My view:

An area that functions as a banner has role="contentinfo"

I would place this one under SC 4.1.2, the role fails

Some of the page's primary content is not included in the main landmark

This is not a failure but surely a best practice to place it in the main

The main landmark contains content that repeats on multiple pages

This is not a failure but surely a best practice to place it outside of the main but in the header

[LiLoDavis]

Thanks for your reply @jake-abma.

IMO, all three would be failures under SC 1.3.1, as the information/structure that's conveyed through presentation would appear to be programmatically determinable, but in fact not so because it's incorrect.

[mraccess77]

The "as text" portion of SC 1.3.1 doesn't specifically say the word "header", "footer", etc. have to be written out. The use of headings or the words in headings themselves can indicate sections ending and starting. This issue has also been discussed on the webAIM list and while most people agree that landmarks should be used there isn't agreement from experts that is required under WCAG 2.1 A/AA but it would fall under SC 1.3.6 AAA.

[LiLoDavis]

I agree that missing landmarks is not a failure of 1.3.1. At this time, I'm focused on incorrect landmarks.