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

michael-n-cooper · 2018-06-12T15:14:41Z

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:

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.

Copied from original issue: w3c/wcag21#310

michael-n-cooper · 2018-06-12T15:14:43Z

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
#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:

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 w3c/wcag21#2 and #3
w3c/wcag21#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
w3c/wcag21#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 · 2018-06-12T15:14:44Z

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
#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:

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 w3c/wcag21#2 and #3
w3c/wcag21#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
w3c/wcag21#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
w3c/wcag21#310 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ
.

michael-n-cooper · 2018-06-12T15:14:45Z

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
#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:

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 w3c/wcag21#2 and #3
w3c/wcag21#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
w3c/wcag21#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
w3c/wcag21#310 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ
.

michael-n-cooper · 2018-06-12T15:14:46Z

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 · 2018-06-12T15:14:46Z

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 w3c/wcag21#2 and #3
w3c/wcag21#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
#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:

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 w3c/wcag21#2 and #3
w3c/wcag21#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
w3c/wcag21#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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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 · 2018-06-12T15:14:47Z

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 w3c/wcag21#2 and #3
w3c/wcag21#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
#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:

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 w3c/wcag21#2 and #3
w3c/wcag21#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
w3c/wcag21#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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfqyvze6LoKCf-j47javUOxLvzZEJAlks5sQgTDgaJpZM4OfpuQ
.

michael-n-cooper · 2018-06-12T15:14:48Z

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 w3c/wcag21#2 and #3
w3c/wcag21#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
#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:

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 w3c/wcag21#2 and #3
w3c/wcag21#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
w3c/wcag21#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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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 · 2018-06-12T15:14:49Z

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 w3c/wcag21#2 and #3
w3c/wcag21#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
#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:

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 w3c/wcag21#2 and #3
w3c/wcag21#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
w3c/wcag21#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
w3c/wcag21#310 (comment),
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
w3c/wcag21#310 (comment),
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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfqyuuhnzm41zdQmzbd3HtICNqQIGhcks5sQvslgaJpZM4OfpuQ
.

michael-n-cooper · 2018-06-12T15:14:50Z

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 · 2018-06-12T15:14:50Z

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
w3c/wcag21#310 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfqyjXZz8ECGSSjbmPux00B-OJrwZykks5sRfdjgaJpZM4OfpuQ
.

michael-n-cooper · 2018-06-12T15:14:51Z

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 · 2018-06-12T15:14:52Z

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
w3c/wcag21#310 (comment), 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 · 2018-06-12T15:14:52Z

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)

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
w3c/wcag21#310 (comment), 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 w3c/wcag21#310 (comment) , or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqym88xCdevwdabpPwzzsk5EyNdkHJks5sRg-RgaJpZM4OfpuQ . https://github.com/notifications/beacon/AFfqyjB4pgzcKtWv6JbXXHicF2jGRageks5sRg-RgaJpZM4OfpuQ.gif

michael-n-cooper · 2018-06-12T15:14:53Z

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 · 2018-06-12T15:14:54Z

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 · 2018-06-12T15:14:54Z

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 · 2018-06-12T15:14:55Z

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 · 2018-06-12T15:14:56Z

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
w3c/wcag21#310 (comment), 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 · 2018-06-12T15:14:57Z

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 · 2018-06-12T15:14:57Z

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 · 2018-06-12T15:14:58Z

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 · 2018-06-12T15:14:58Z

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 · 2018-06-12T15:14:59Z

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
w3c/wcag21#310 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfqyqe89kRVzeb2Y1iqKHXLm6oHETXFks5sjOdHgaJpZM4OfpuQ
.

michael-n-cooper · 2018-06-12T15:15:00Z

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 · 2018-06-12T15:15:01Z

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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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 · 2018-06-12T15:15:02Z

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 · 2018-06-12T15:15:03Z

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 · 2018-06-12T15:15:03Z

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 · 2018-06-12T15:15:04Z

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
w3c/wcag21#310 (comment), 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 · 2018-06-12T15:15:05Z

From @DavidMacDonald on September 22, 2017 11:51

There are 2 things that landmarks provide

Programmatic identification of parts of the page that are identified visually (header, footer, navigation, etc.)
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 · 2018-06-12T15:15:06Z

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 · 2018-06-12T15:15:07Z

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
w3c/wcag21#310 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfqyuvnfFRp6FhQCvIhfflID6ySsAazks5sk7HDgaJpZM4OfpuQ
.

michael-n-cooper · 2018-06-12T15:15:07Z

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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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 · 2018-06-12T15:15:08Z

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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfqyqtWrNcbZoKNOafdkUBormwf12-Wks5sk7xkgaJpZM4OfpuQ
.

michael-n-cooper · 2018-06-12T15:15:09Z

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
w3c/wcag21#310 (comment),
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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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
w3c/wcag21#310 (comment), 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 · 2018-06-12T15:27:58Z

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

LiLoDavis · 2019-05-20T17:41:19Z

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 · 2019-05-20T19:19:11Z

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 · 2019-05-21T17:03:30Z

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 · 2019-05-21T17:23:34Z

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 · 2019-05-21T18:25:06Z

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

michael-n-cooper assigned DavidMacDonald Jun 12, 2018

michael-n-cooper added AGWG Work item Techniques labels Jun 12, 2018

michael-n-cooper closed this as completed Jun 12, 2018

michael-n-cooper reopened this Jun 12, 2018

alastc added the WCAG 2.0 label Aug 15, 2019

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

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

Comments

michael-n-cooper commented Jun 12, 2018

Text of the Failure Proposal

Description

Failure Procedure

Related Techniques

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

SKIP NAVS have limitations

Headings provide a separate semantic and do not replace landmarks.

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

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

michael-n-cooper commented Jun 12, 2018

LiLoDavis commented May 20, 2019

jake-abma commented May 20, 2019

LiLoDavis commented May 21, 2019

mraccess77 commented May 21, 2019

LiLoDavis commented May 21, 2019