Failure Technique around page regions (Header, Footer, Nav, Main etc.) #310
Comments
|
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 ***@***.***> wrote:
This is an issue originally filed as Issue #173 for WCAG 2
<w3c/wcag#173>. I've moved it here, which is
the active list. It has good momentum and agreement from many AGWG members.
Ø "Failure of 1.3.1 due to regions of a page which are visually distinct
AND which contain distinct groups of content (headers, footers,
navigation bars, main content, asides) not being programmatically
determinable or identified by text."
Description
This failure addresses the problem that occurs when regions of a page are
visually distinct from other parts of the page, and contain different
content (such as groups of links, advertisements, etc.) that are distinct
from the main content of the page, but are not easy to identify for those
who cannot see those visual distinctions. People who are blind rely on
screen reading software that identifies regions of the page. There are a
number of ways to identify regions, but if these regions contain distinct
content from each other, they must be identifiable in a way the screen
reader can relay to the user: either programmatically or by identifying
them in text that can be read by the screen reader. A few clarifications of
exceptions are:
- Content that is not distinct visually is not a failure
- Content that is not distinct in substance is not a failure
- Content that only has one or two items is not a failure because it
is not a region (group of cohesive content). For instance, a footer with
only a copyright notice, or a header with only a logo are not examples of
regions because neither of these would be a group of content.
Failure Procedure
Examine the page to confirm there are regions that are visually distinct
and contain distinct content. Check each region to confirm:
1.
- It has been identified in a programmatically determinable way
(Landmarks, HTML 5 regions, etc.) OR
2.
- The sections are identified by text, ("Header, Footer, Navigation
etc.")
If #2 <#2> and #3
<#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
<#310>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
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" ***@***.***> 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 <
***@***.***>
wrote:
> This is an issue originally filed as Issue #173 for WCAG 2
> <w3c/wcag#173>. I've moved it here, which is
> the active list. It has good momentum and agreement from many AGWG
members.
>
> Ø "Failure of 1.3.1 due to regions of a page which are visually distinct
> AND which contain distinct groups of content (headers, footers,
> navigation bars, main content, asides) not being programmatically
> determinable or identified by text."
> Description
>
> This failure addresses the problem that occurs when regions of a page are
> visually distinct from other parts of the page, and contain different
> content (such as groups of links, advertisements, etc.) that are distinct
> from the main content of the page, but are not easy to identify for those
> who cannot see those visual distinctions. People who are blind rely on
> screen reading software that identifies regions of the page. There are a
> number of ways to identify regions, but if these regions contain distinct
> content from each other, they must be identifiable in a way the screen
> reader can relay to the user: either programmatically or by identifying
> them in text that can be read by the screen reader. A few clarifications
of
> exceptions are:
>
> - Content that is not distinct visually is not a failure
> - Content that is not distinct in substance is not a failure
> - Content that only has one or two items is not a failure because it
> is not a region (group of cohesive content). For instance, a footer with
> only a copyright notice, or a header with only a logo are not examples of
> regions because neither of these would be a group of content.
>
> Failure Procedure
>
> Examine the page to confirm there are regions that are visually distinct
> and contain distinct content. Check each region to confirm:
>
> 1.
> - It has been identified in a programmatically determinable way
> (Landmarks, HTML 5 regions, etc.) OR
> 2.
> - The sections are identified by text, ("Header, Footer, Navigation
> etc.")
>
> If #2 <#2> and #3
> <#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
> <#310>, or mute the thread
> <https://github.com/notifications/unsubscribe-
auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ>
> .
>
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
***@***.***
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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ>
.
|
|
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" ***@***.***> 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" ***@***.***> 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 <
> ***@***.***>
> wrote:
>
> > This is an issue originally filed as Issue #173 for WCAG 2
> > <w3c/wcag#173>. I've moved it here, which is
> > the active list. It has good momentum and agreement from many AGWG
> members.
> >
> > Ø "Failure of 1.3.1 due to regions of a page which are visually
> distinct
> > AND which contain distinct groups of content (headers, footers,
> > navigation bars, main content, asides) not being programmatically
> > determinable or identified by text."
> > Description
> >
> > This failure addresses the problem that occurs when regions of a page
> are
> > visually distinct from other parts of the page, and contain different
> > content (such as groups of links, advertisements, etc.) that are
> distinct
> > from the main content of the page, but are not easy to identify for
> those
> > who cannot see those visual distinctions. People who are blind rely on
> > screen reading software that identifies regions of the page. There are a
> > number of ways to identify regions, but if these regions contain
> distinct
> > content from each other, they must be identifiable in a way the screen
> > reader can relay to the user: either programmatically or by identifying
> > them in text that can be read by the screen reader. A few
> clarifications of
> > exceptions are:
> >
> > - Content that is not distinct visually is not a failure
> > - Content that is not distinct in substance is not a failure
> > - Content that only has one or two items is not a failure because it
> > is not a region (group of cohesive content). For instance, a footer with
> > only a copyright notice, or a header with only a logo are not examples
> of
> > regions because neither of these would be a group of content.
> >
> > Failure Procedure
> >
> > Examine the page to confirm there are regions that are visually distinct
> > and contain distinct content. Check each region to confirm:
> >
> > 1.
> > - It has been identified in a programmatically determinable way
> > (Landmarks, HTML 5 regions, etc.) OR
> > 2.
> > - The sections are identified by text, ("Header, Footer, Navigation
> > etc.")
> >
> > If #2 <#2> and #3
> > <#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
> > <#310>, or mute the thread
> > <https://github.com/notifications/unsubscribe-auth/ABK-
> czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ>
> > .
> >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> ***@***.***
>
> 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
> <#310 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AFfqytzX4elk5KxnGuLZrd0BQBvmNG90ks5sQOr_gaJpZM4OfpuQ>
> .
>
|
|
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). |
|
Hi Katie,
Respectfully, if you read David's new proposal it directly references two
new "issues" (proposed new SC):
<#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 <
[email protected]> 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" ***@***.***> 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 <
> ***@***.***>
> wrote:
>
> > This is an issue originally filed as Issue #173 for WCAG 2
> > <w3c/wcag#173>. I've moved it here, which is
> > the active list. It has good momentum and agreement from many AGWG
> members.
> >
> > Ø "Failure of 1.3.1 due to regions of a page which are visually
distinct
> > AND which contain distinct groups of content (headers, footers,
> > navigation bars, main content, asides) not being programmatically
> > determinable or identified by text."
> > Description
> >
> > This failure addresses the problem that occurs when regions of a page
are
> > visually distinct from other parts of the page, and contain different
> > content (such as groups of links, advertisements, etc.) that are
distinct
> > from the main content of the page, but are not easy to identify for
those
> > who cannot see those visual distinctions. People who are blind rely on
> > screen reading software that identifies regions of the page. There are
a
> > number of ways to identify regions, but if these regions contain
distinct
> > content from each other, they must be identifiable in a way the screen
> > reader can relay to the user: either programmatically or by identifying
> > them in text that can be read by the screen reader. A few
clarifications
> of
> > exceptions are:
> >
> > - Content that is not distinct visually is not a failure
> > - Content that is not distinct in substance is not a failure
> > - Content that only has one or two items is not a failure because it
> > is not a region (group of cohesive content). For instance, a footer
with
> > only a copyright notice, or a header with only a logo are not examples
of
> > regions because neither of these would be a group of content.
> >
> > Failure Procedure
> >
> > Examine the page to confirm there are regions that are visually
distinct
> > and contain distinct content. Check each region to confirm:
> >
> > 1.
> > - It has been identified in a programmatically determinable way
> > (Landmarks, HTML 5 regions, etc.) OR
> > 2.
> > - The sections are identified by text, ("Header, Footer, Navigation
> > etc.")
> >
> > If #2 <#2> and #3
> > <#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
> > <#310>, or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ>
> > .
> >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> ***@***.***
>
> 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
> <#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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-cz6aaGXPRg4LO-JAWGwNWi9k4Q_tks5sQP5kgaJpZM4OfpuQ>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
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" ***@***.***> wrote:
Hi Katie,
Respectfully, if you read David's new proposal it directly references two
new "issues" (proposed new SC):
> If #2 <#2> and #3
<#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 <
***@***.***> 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" ***@***.***> 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 <
> > ***@***.***>
> > wrote:
> >
> > > This is an issue originally filed as Issue #173 for WCAG 2
> > > <w3c/wcag#173>. I've moved it here, which
is
> > > the active list. It has good momentum and agreement from many AGWG
> > members.
> > >
> > > Ø "Failure of 1.3.1 due to regions of a page which are visually
> distinct
> > > AND which contain distinct groups of content (headers, footers,
> > > navigation bars, main content, asides) not being programmatically
> > > determinable or identified by text."
> > > Description
> > >
> > > This failure addresses the problem that occurs when regions of a page
> are
> > > visually distinct from other parts of the page, and contain different
> > > content (such as groups of links, advertisements, etc.) that are
> distinct
> > > from the main content of the page, but are not easy to identify for
> those
> > > who cannot see those visual distinctions. People who are blind rely
on
> > > screen reading software that identifies regions of the page. There
are
> a
> > > number of ways to identify regions, but if these regions contain
> distinct
> > > content from each other, they must be identifiable in a way the
screen
> > > reader can relay to the user: either programmatically or by
identifying
> > > them in text that can be read by the screen reader. A few
> clarifications
> > of
> > > exceptions are:
> > >
> > > - Content that is not distinct visually is not a failure
> > > - Content that is not distinct in substance is not a failure
> > > - Content that only has one or two items is not a failure because it
> > > is not a region (group of cohesive content). For instance, a footer
> with
> > > only a copyright notice, or a header with only a logo are not
examples
> of
> > > regions because neither of these would be a group of content.
> > >
> > > Failure Procedure
> > >
> > > Examine the page to confirm there are regions that are visually
> distinct
> > > and contain distinct content. Check each region to confirm:
> > >
> > > 1.
> > > - It has been identified in a programmatically determinable way
> > > (Landmarks, HTML 5 regions, etc.) OR
> > > 2.
> > > - The sections are identified by text, ("Header, Footer, Navigation
> > > etc.")
> > >
> > > If #2 <#2> and #3
> > > <#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
> > > <#310>, or mute the thread
> > > <https://github.com/notifications/unsubscribe-
> > auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ>
> > > .
> > >
> >
> >
> >
> > --
> > John Foliot
> > Principal Accessibility Strategist
> > Deque Systems Inc.
> > ***@***.***
> >
> > 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
> > <#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
> <#310 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ABK-cz6aaGXPRg4LO-
JAWGwNWi9k4Q_tks5sQP5kgaJpZM4OfpuQ>
> .
>
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
***@***.***
Advancing the mission of digital accessibility and inclusion
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqyvze6LoKCf-j47javUOxLvzZEJAlks5sQgTDgaJpZM4OfpuQ>
.
|
|
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 ***@***.***> 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" ***@***.***> wrote:
> Hi Katie,
>
> Respectfully, if you read David's new proposal it directly references two
> new "issues" (proposed new SC):
>
> > If #2 <#2> and #3
> <#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 <
> ***@***.***> 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" ***@***.***> 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 <
> > > ***@***.***>
> > > wrote:
> > >
> > > > This is an issue originally filed as Issue #173 for WCAG 2
> > > > <w3c/wcag#173>. I've moved it here, which
> is
> > > > the active list. It has good momentum and agreement from many AGWG
> > > members.
> > > >
> > > > Ø "Failure of 1.3.1 due to regions of a page which are visually
> > distinct
> > > > AND which contain distinct groups of content (headers, footers,
> > > > navigation bars, main content, asides) not being programmatically
> > > > determinable or identified by text."
> > > > Description
> > > >
> > > > This failure addresses the problem that occurs when regions of a page
> > are
> > > > visually distinct from other parts of the page, and contain different
> > > > content (such as groups of links, advertisements, etc.) that are
> > distinct
> > > > from the main content of the page, but are not easy to identify for
> > those
> > > > who cannot see those visual distinctions. People who are blind rely
> on
> > > > screen reading software that identifies regions of the page. There
> are
> > a
> > > > number of ways to identify regions, but if these regions contain
> > distinct
> > > > content from each other, they must be identifiable in a way the
> screen
> > > > reader can relay to the user: either programmatically or by
> identifying
> > > > them in text that can be read by the screen reader. A few
> > clarifications
> > > of
> > > > exceptions are:
> > > >
> > > > - Content that is not distinct visually is not a failure
> > > > - Content that is not distinct in substance is not a failure
> > > > - Content that only has one or two items is not a failure because it
> > > > is not a region (group of cohesive content). For instance, a footer
> > with
> > > > only a copyright notice, or a header with only a logo are not
> examples
> > of
> > > > regions because neither of these would be a group of content.
> > > >
> > > > Failure Procedure
> > > >
> > > > Examine the page to confirm there are regions that are visually
> > distinct
> > > > and contain distinct content. Check each region to confirm:
> > > >
> > > > 1.
> > > > - It has been identified in a programmatically determinable way
> > > > (Landmarks, HTML 5 regions, etc.) OR
> > > > 2.
> > > > - The sections are identified by text, ("Header, Footer, Navigation
> > > > etc.")
> > > >
> > > > If #2 <#2> and #3
> > > > <#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
> > > > <#310>, or mute the thread
> > > > <https://github.com/notifications/unsubscribe-
> > > auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ>
> > > > .
> > > >
> > >
> > >
> > >
> > > --
> > > John Foliot
> > > Principal Accessibility Strategist
> > > Deque Systems Inc.
> > > ***@***.***
> > >
> > > 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
> > > <#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
> > <#310 (comment)>, or
> mute
> > the thread
> > <https://github.com/notifications/unsubscribe-auth/ABK-cz6aaGXPRg4LO-
> JAWGwNWi9k4Q_tks5sQP5kgaJpZM4OfpuQ>
> > .
> >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> ***@***.***
>
> Advancing the mission of digital accessibility and inclusion
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#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.
|
|
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" <[email protected]>
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 ***@***.***>
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" ***@***.***>
wrote:
>
> > Hi Katie,
> >
> > Respectfully, if you read David's new proposal it directly references
two
> > new "issues" (proposed new SC):
> >
> > > If #2 <#2> and #3
> > <#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 <
> > ***@***.***> 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" ***@***.***>
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 <
> > > > ***@***.***>
> > > > wrote:
> > > >
> > > > > This is an issue originally filed as Issue #173 for WCAG 2
> > > > > <w3c/wcag#173>. I've moved it here,
which
> > is
> > > > > the active list. It has good momentum and agreement from many
AGWG
> > > > members.
> > > > >
> > > > > Ø "Failure of 1.3.1 due to regions of a page which are visually
> > > distinct
> > > > > AND which contain distinct groups of content (headers, footers,
> > > > > navigation bars, main content, asides) not being programmatically
> > > > > determinable or identified by text."
> > > > > Description
> > > > >
> > > > > This failure addresses the problem that occurs when regions of a
page
> > > are
> > > > > visually distinct from other parts of the page, and contain
different
> > > > > content (such as groups of links, advertisements, etc.) that are
> > > distinct
> > > > > from the main content of the page, but are not easy to identify
for
> > > those
> > > > > who cannot see those visual distinctions. People who are blind
rely
> > on
> > > > > screen reading software that identifies regions of the page.
There
> > are
> > > a
> > > > > number of ways to identify regions, but if these regions contain
> > > distinct
> > > > > content from each other, they must be identifiable in a way the
> > screen
> > > > > reader can relay to the user: either programmatically or by
> > identifying
> > > > > them in text that can be read by the screen reader. A few
> > > clarifications
> > > > of
> > > > > exceptions are:
> > > > >
> > > > > - Content that is not distinct visually is not a failure
> > > > > - Content that is not distinct in substance is not a failure
> > > > > - Content that only has one or two items is not a failure
because it
> > > > > is not a region (group of cohesive content). For instance, a
footer
> > > with
> > > > > only a copyright notice, or a header with only a logo are not
> > examples
> > > of
> > > > > regions because neither of these would be a group of content.
> > > > >
> > > > > Failure Procedure
> > > > >
> > > > > Examine the page to confirm there are regions that are visually
> > > distinct
> > > > > and contain distinct content. Check each region to confirm:
> > > > >
> > > > > 1.
> > > > > - It has been identified in a programmatically determinable way
> > > > > (Landmarks, HTML 5 regions, etc.) OR
> > > > > 2.
> > > > > - The sections are identified by text, ("Header, Footer,
Navigation
> > > > > etc.")
> > > > >
> > > > > If #2 <#2> and #3
> > > > > <#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
> > > > > <#310>, or mute the thread
> > > > > <https://github.com/notifications/unsubscribe-
> > > > auth/ABK-czIdn-j5Wz582wyBpR_rpf12pfGVks5sQNisgaJpZM4OfpuQ>
> > > > > .
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > John Foliot
> > > > Principal Accessibility Strategist
> > > > Deque Systems Inc.
> > > > ***@***.***
> > > >
> > > > 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
> > > > <#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
> > > <#310 (comment)>,
or
> > mute
> > > the thread
> > > <https://github.com/notifications/unsubscribe-
auth/ABK-cz6aaGXPRg4LO-
> > JAWGwNWi9k4Q_tks5sQP5kgaJpZM4OfpuQ>
> > > .
> > >
> >
> >
> >
> > --
> > John Foliot
> > Principal Accessibility Strategist
> > Deque Systems Inc.
> > ***@***.***
> >
> > Advancing the mission of digital accessibility and inclusion
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <#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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqyuuhnzm41zdQmzbd3HtICNqQIGhcks5sQvslgaJpZM4OfpuQ>
.
|
|
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.
|
|
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" <[email protected]>
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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqyjXZz8ECGSSjbmPux00B-OJrwZykks5sRfdjgaJpZM4OfpuQ>
.
|
|
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.
|
|
+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 ***@***.***> 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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-cyOaa_BAaM1KqS6Drju-WjqAAfhSks5sRf6cgaJpZM4OfpuQ>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
Again, this can be worked on and improved upon once more people on the WG have the experience with crafting solid standards language and are willing to put the diligent thought and well-intentioned work into properly crafting it…..
* katie *
Katie Haritos-Shea
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
Cell: 703-371-5545 | <mailto:[email protected]> [email protected] | Oakton, VA | <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 | <https://twitter.com/Ryladog> @Ryladog
NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.
From: John Foliot [mailto:[email protected]]
Sent: Tuesday, July 25, 2017 11:54 AM
To: w3c/wcag21 <[email protected]>
Cc: Katie Haritos-Shea <[email protected]>; Comment <[email protected]>
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 ***@***.*** ***@***.***> > 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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-cyOaa_BAaM1KqS6Drju-WjqAAfhSks5sRf6cgaJpZM4OfpuQ>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected] <mailto:[email protected]>
Advancing the mission of digital accessibility and inclusion
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#310 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AFfqym88xCdevwdabpPwzzsk5EyNdkHJks5sRg-RgaJpZM4OfpuQ> . <https://github.com/notifications/beacon/AFfqyjB4pgzcKtWv6JbXXHicF2jGRageks5sRg-RgaJpZM4OfpuQ.gif>
|
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. |
|
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 ***@***.***>:
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.
|
|
Hi @johnfoliot and all,
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, |
|
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. |
|
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 ***@***.*** > 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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c3EnygD02N1AZ2cguN9HY9u6VFdFks5sSK5YgaJpZM4OfpuQ>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
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 |
|
as long as "improperly" doesn't mean "doesn't follow the exact markup pattern that we cooked up", sure... |
|
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. |
|
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:
…but, adding it as a new failure to 2.1 seems a valid approach and thus I agree with @DavidMacDonald
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. |
|
+1 to Jake
** katie **
Katie Haritos-Shea
Senior Accessibility SME (WCAG/Section 508/ADA)
703-371-5545
[email protected]
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 ***@***.***> 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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqyqe89kRVzeb2Y1iqKHXLm6oHETXFks5sjOdHgaJpZM4OfpuQ>
.
|
|
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? |
|
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 <
[email protected]> wrote:
… +1 to Jake
** katie **
Katie Haritos-Shea
Senior Accessibility SME (WCAG/Section 508/ADA)
703-371-5545 <(703)%20371-5545>
***@***.***
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 ***@***.***>
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
> <#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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c93VsEUyMI4gGgeWcPoUIQJ2L_10ks5sjTYVgaJpZM4OfpuQ>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
@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 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. |
|
Hi Jake, |
|
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… :-( |
|
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 ***@***.***> 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
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c-_oVxDMe3gZu9QDw64698JmUX7uks5sjUtYgaJpZM4OfpuQ>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
The first sentence of this issue says:
Does it need be any clearer? |
|
If this is a new Failure Technique for an 'old' WCAG 2.0 SC that persists in 2.1, then it would seem odd to exclude it from application in 2.0 conformance tests. The general idea has been that as technologies change, new Techniques will be added and others might drop out because better solutions exists and the old way is no longer recommended (this could apply to using accessibly hidden headings to meet SC 2.4.1 - not sure whether such a technique exists, but it could). |
Can you provide an example of where it would not apply? If something is not designed to visually look like a header, footer, search component, navigation or aside, then there is no requirement. If there is such an example that cannot be managed through the language of the failure, then of course I would concede this failure. I think that if something looks like a duck, walks like a duck, and talks like a duck, it should be called a "duck" so that blind people will know what it is and how to get there. |
|
Hi David, I don't see the need to dig up additional examples. Just look at the situations Jake has described above in his comment. |
|
@DavidMacDonald whether or not this one will make it for this round, I do like to mention a concern (or two) There are two issues I'm not yet comfortable with starting with "visually designed". This brings me right to the next issue which gives a somewhat awkward feeling. So, even when totally agreeing that clear headers with header content and a visual distinction need landmarks, it probably needs to be judged on its contextual content to be fully effective. |
|
Which is what human evaluators do. Much of 1.3.1 requires human judgment to
determine. And 1.3.1 is about providing programmatically access to visually
apparent relationships.
Katie Haritos-Shea
703-371-5545
…On Sep 24, 2017 7:04 AM, "Jake Abma" ***@***.***> wrote:
@DavidMacDonald <https://github.com/davidmacdonald> whether or not this
one will make it for this round, I do like to mention a concern (or two)
There are two issues I'm not yet comfortable with starting with "visually
designed".
What is the definition of "visually designed" in this case and when does
this not apply?
In fact, every page, part of pages, are by definition "visually designed"
even when there's almost nothing on it or no colors and lots of white
space, that's all about aesthetics.
There's no rule in visual design that parts need to be mandatory visually
distinct.
Only focusing on "visually designed" will miss great opportunity to
capture so much more use cases for landmarks...
In 1.3.1 we're talking about "information, structure and relationship
conveyed through presentation (rendering of content) not visual design.
This brings me right to the next issue which gives a somewhat awkward
feeling.
Landmarks are not visual elements / roles but should contain specific
content in context.
Judging visual appearance with context elements / roles looses lots of
otherwise useful implementation options.
So, even when totally agreeing that clear headers with header content and
a visual distinction need landmarks, it probably needs to be judged on its
contextual content to be fully effective.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqyrcwTR0GAWriWABG7TuP6jweUeHpks5sljcjgaJpZM4OfpuQ>
.
|
|
Just some situations:
If there is distinct content in those sections and a visual indication it should have a landmark
I think the clue here is the discussion of the characteristics of header. It would require a role.
Again there is discussion of the different parts of the page. Those sections would require roles.
If there content makes up part of the main topic of the page it does not require a new role for aside.
If the content in those sections was distinct and there are visual indicators it would require roles.
The image does not need a role.
If navigation roles are on the main menu and secondary menu and there are a bunch of sub menus, which have been optimized, they would not require a role. We could address that in the language without difficulty. |
|
So, concluding we always have some form of visual indication and it's all about contextual content, are we just making Landmarks mandatory, period, as sites, except, maybe, for-one off promo pages, always contain contextual content fitting in landmark definitions? (Not taking into account the different perceptions of the right use of landmark) |
|
If there is a visual indicator of a header, footer, main, search, aside, navigation AND there is distinct content in those sections, then yes.... we are saying there should be landmarks. In years of constant audits, I've never had an author say, "I can't do that". If fact they've always said, "oh sure, that's an easy win". I think perhaps I should post the failure text again.
|
|
The conditions for the visual indicator are still not clear. Is a main navigation on it's own enough for a visual indication? If yes, a main navigation without a nav or role navigation will always fail? Same for other UI components like search. Are conditions met because they are there? And for distinct groups, is this meant to be plural? As in, one group of links in an Aside don't need to comply although the best practice is they should be part of an Aside? |
|
@Ryladog wrote And 1.3.1 is about providing programmatically access to visually Programmatically OR as text. Use of a heading at the start of a section communicates that section iva text. I support requiring visual information relationships being communicated programmatically -- but this does not require ARIA landmarks -- WCAG can't require specific technologies be used. So this could be met through lists, headings, heading text, text labels, or in situations where the purpose is ambiguous to all users or simply decorative -- nothing extra is needed. I would suggest that we come up with specific failure situations and what could be used to not fail. Failures are helpful for others to have some examples of the groups thought process I support adding more failures that are true failures. |
|
You are right Jon about the 'or in text'. This failure doesn't require the
use of ARIA landmarks. Reread the proposed text.
…On Sep 24, 2017 8:01 PM, "Jonathan Avila" ***@***.***> wrote:
@Ryladog <https://github.com/ryladog> wrote And 1.3.1 is about providing
programmatically access to visually
apparent relationships.
Programmatically OR as text. Use of a heading at the start of a section
communicates that section iva text. I support requiring visual information
relationships being communicated programmatically -- but this does not
require ARIA landmarks -- WCAG can't require specific technologies be used.
So this could be met through lists, headings, heading text, text labels, or
in situations where the purpose is ambiguous to all users or simply
decorative -- nothing extra is needed. I would suggest that we come up with
specific failure situations and what could be used to not fail. Failures
are helpful for others to have some examples of the groups thought process
I support adding more failures that are true failures.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqykF5-GGDHS6M8lJbGoZ0YwUJ2nFSks5slu1UgaJpZM4OfpuQ>
.
|
|
|
David,
You do realize you pointed to a comment I posed regarding the proposed SC
for printing, and nothing to do with versioning Failure Techniques?
Clear as mud, apparently <grin>.
JF
…On Saturday, September 23, 2017, David MacDonald ***@***.***> wrote:
No, but it is a new idea.
The first sentence of this issue says:
This is an issue originally filed as Issue #173
<#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.
Does it need be any clearer?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c7UzHxLZwLvTSNrGTSXKQTB_DWc3ks5slazNgaJpZM4OfpuQ>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
As a clarification of my previous comment, David previously stated:
Note that the link to Issue #173 applies to a completely different subject (Printing), and has nothing to do with Failure techniques, so I'm sorry, but what is David talking about, exactly? I have no idea. JF |
|
The link has always been correct. The issue refers correctly to Issue #173 for WCAG 2 in the WCAG 2 repository ... not this WCAG 2.1 repository, where, as you mention, number 173 goes to printing. |
|
Hi David,
I followed the link you provided in your initial email. Perhaps it was you that got mixed up?
At any rate, I continue to oppose the thrust of this Failure Technique as being overly broad, and of having the net effect of redefining SC 1.3.1. I have previously offered suggestions of what kind of specific landmark Failures that could be added to the Failure Techniques, while also noting that currently we have a Success Technique that shows how to use ARIA landmark roles, but lack an equivalent for HTML 5 Landmark elements.
My personal preference at this time is that we see this WG focus on Success Techniques for emergent new SC. I've long held that teaching people how to swim has far more value than documenting ways to drown.
JF
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: David MacDonald <[email protected]> Date: 9/26/17 5:12 PM (GMT-05:00) To: w3c/wcag21 <[email protected]> Cc: John Foliot <[email protected]>, Mention <[email protected]> Subject: Re: [w3c/wcag21] Failure Technique around page regions (Header, Footer, Nav, Main etc.) (#310)
Actually, that is not where the link goes. The link goes here.
filed as Issue #173 for WCAG 2.
Perhaps you've got your repositories mixed up and got tricked ... It's number 173 for the WCAG 2 repository not this one which is 2.1. That's where the link has always gone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/w3c/wcag21","title":"w3c/wcag21","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/w3c/wcag21"}},"updates":{"snippets":[{"icon":"PERSON","message":"@DavidMacDonald in #310: Actually, that is not where the link goes. The link goes here.\r\n[filed as Issue #173 for WCAG 2](w3c/wcag#173).\r\n\r\nPerhaps you've got your repositories mixed up and got tricked ... It's number 173 for the WCAG 2 repository not this one which is 2.1. That's where the link has always gone."}],"action":{"name":"View Issue","url":"#310 (comment)"}}}
|
|
Related to a "Mechanism" in David's comment, some Working Group members may not be aware of the following: https://www.w3.org/2017/Process-20170301/#Consensus I have categorically and repeatedly stated that I am not opposed to Failure Techniques per-se, but equally I am on record as opposing THIS particular proposal for the technical reasons I have previously outlined on multiple occasions. I have also previously suggested some potential Failure Techniques that could be applied around the correct (versus incorrect and thus failing) usage of Landmark elements and roles, and so any attempt to try and make this appear as a black and white opposition to Failure Techniques is both insulting and patently and provably false. I also note with continued frustration that while we currently have a Success Technique that shows how using ARIA Landmark roles can achieve success for this Success Criteria, we still lack a Success Technique that does the same for HTML 5's Landmark elements (yet David keeps pushing for a Failure Technique if they aren't present). Thus, what this proposed Failure Technique appears to be seeking is that content authors MUST meet a specific code-pattern requirement, as opposed to meeting a specified functional outcome, which is yet one more reason to reject this overly broad proposal. Finally, elsewhere Katie wrote:
Respectfully, that's simply not true: What is true is that 'There is no SC that says use Landmarks in WCAG 2.0 (nor should there be).' If this Working Group wishes to address that current gap, then that is a reasonable observation to open up for discussion. Meanwhile, any Failure Technique that seeks to re-define existing SC in WCAG 2.0 will continue to be rejected as out-of-scope and fundamentally changing the backward compatibility requirements we are working under. |
|
John,
You wrote
* Finally, elsewhere <#392 (comment)> Katie wrote:
“There is no SC that says ‘use headings’ in WCAG 2.0 (nor should there be).”
Yes, and I stand by that.
You should have known that I was specifically talking about that in relation to 1.3.1 (as you noted you thought I was trying to redefine it), as that is what the discussion was around. But, even in 2.4.10 (a AAA SC) it doesn’t say you must use the HTML <heading> element – in fact, it says – “Note 1: "Heading" is used in its general sense and includes titles and other ways to add a heading to different types of content.”
And, the suggested failure (Failure Technique around page regions (Header, Footer, Nav, Main etc.) language doesn’t say anything about requiring landmarks at all, it talks about regions. The full text for testing the Failure Technique identifies *one way* as using sections and ARIA, however, that is *one of three* possible options.
I think I understand the apparent desire to prove me wrong, but luckily the decision to include new Failure Techniques is not up to one working group participant.
* katie *
Katie Haritos-Shea
Principal ICT Accessibility Architect, IAAP <http://www.accessibilityassociation.org/recentlycertified> CPACC+WAS = <http://www.accessibilityassociation.org/cpwacertificants> CPWA (WCAG/Section 508/ADA/AODA)
Cell: 703-371-5545 | <mailto:[email protected]> [email protected] | Oakton, VA | <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 | <https://twitter.com/Ryladog> @Ryladog
NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.
From: John Foliot [mailto:[email protected]]
Sent: Wednesday, October 4, 2017 3:21 PM
To: w3c/wcag21 <[email protected]>
Cc: Katie Haritos-Shea <[email protected]>; Mention <[email protected]>
Subject: Re: [w3c/wcag21] Failure Technique around page regions (Header, Footer, Nav, Main etc.) (#310)
Related to a "Mechanism" in David's comment, some Working Group members may not be aware of the following: https://www.w3.org/2017/Process-20170301/#Consensus
Any attempts to override W3C process are clearly out-of-scope for this Working Group.
I have categorically and repeatedly stated <#310 (comment)> that I am not opposed to Failure Techniques per-se, but equally I am on record as opposing THIS particular proposal for the technical reasons I have previously outlined on multiple occasions. I have also previously suggested some potential Failure Techniques <#310 (comment)> that could be applied around the correct (versus incorrect and thus failing) usage of Landmark elements and roles, and so any attempt to try and make this appear as a black and white opposition to Failure Techniques is both insulting and patently and provably false.
I also note with continued frustration that while we currently have a Success Technique that shows how using ARIA Landmark roles can achieve success for this Success Criteria, we still lack a Success Technique that does the same for HTML 5's Landmark elements (yet David keeps pushing for a Failure Technique if they aren't present).
Thus, what this proposed Failure Technique appears to be seeking is that content authors MUST meet a specific code-pattern requirement, as opposed to meeting a specified functional outcome, which is yet one more reason to reject this overly broad proposal.
Finally, elsewhere <#392 (comment)> Katie wrote:
There is no SC that says use headings in WCAG 2.0 (nor should there be).
Respectfully, that's simply not true:
Success Criteria 2.4.10 <https://www.w3.org/TR/WCAG20/#navigation-mechanisms-headings> Section Headings: Section headings are used to organize the content. (Level AAA)
What is true is that 'There is no SC that says use Landmarks in WCAG 2.0 (nor should there be).'
If this Working Group wishes to address that current gap, then that is a reasonable observation to open up for discussion. Meanwhile, any Failure Technique that seeks to re-define existing SC in WCAG 2.0 will continue to be rejected as out-of-scope <https://www.w3.org/2017/10/03-ag-minutes.html#item02> and fundamentally changing the backward compatibility requirements we are working under.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#310 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AFfqysU6cfBKOE1BmfnjcXnNNMSHdfUDks5so9qIgaJpZM4OfpuQ> . <https://github.com/notifications/beacon/AFfqyhg72hXwevA9hyKTHBhjDwebcDkBks5so9qIgaJpZM4OfpuQ.gif>
|
My opposition isn't to adding ANY Failure Techniques (despite the fact that you and David keep suggesting that, and DESPITE THE FACT THAT I'VE PUBLICLY STATED OTHERWISE - and here as well), but rather my opposition to this specific proposed Failure Technique, based upon the technical reasons I've previously given, as well as concerns raised by others in this thread. Continuing to suggest otherwise is nothing but an ad hominem attack on your part.
The proposed text states:
(So, in other words, I have to either use the Additionally, David's response of 10 days ago also confirms that this is about Landmarks:
You are free to believe this isn't about requiring Landmarks, but I think the above quoted text makes it clear to many of us this is exactly about requiring Landmarks (especially when the author of the proposal comes right out and says so). While I have been the most vocal about this, there are others voicing concerns about this proposal as well:
Feel free to argue against the technical concerns, but stop attempting to make this about me (or others opposed to this proposal), or presuming to know what my or others motivations and goals are. Better yet, perhaps follow your own suggestion that "...we table this until after 2.1." That, I could support fully. Thanks. |
|
John,
Again, if one reads and understands the technique as written it says....
Failure Procedure
Examine the page to confirm there are regions that are visually distinct
which identify any of the following and contain distinct content:
header/banner, footer/contentinfo, navigation section, complementary/aside,
search region, main region, then check each region to confirm:
1. It has been identified in a programmatically determinable way
(Landmarks, HTML 5 regions, etc.) OR
2. The sections are identified by text, ("Header, Footer, Navigation
etc.")
If #2 <#2> and #3
<#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.
Landmarks are *one* way to determine if the region's are 'visually
distinct' and programmatically determinable. Not the only way. Headings or
text may also be also be used.
Therefore this failure does not prescribe a specific design pattern, but
does prescribe an outcome.
If you consider my defense of this relevant failure as an attack on you,
you would be mistaken. This isn't about you. I believe it is an important
and viable failure of 1.3.1 given today's technology.
There is no reason that 2.1 should not be moving the bar forward.
Katie
On Oct 4, 2017 7:13 PM, "John Foliot" <[email protected]> wrote:
luckily the decision to include new Failure Techniques is not up to one
working group participant.
My opposition isn't to adding ANY Failure Techniques (despite the fact that
you and David keep suggesting that, and *DESPITE THE FACT THAT I'VE
PUBLICLY STATED OTHERWISE*
<#310 (comment)> - and *here
as well* <#310 (comment)>),
but rather my opposition to this specific proposed Failure Technique, based
upon the technical reasons I've previously given, as well as concerns
raised by others in this thread.
*Continuing to suggest otherwise is nothing but an ad hominem attack on
your part.*
------------------------------
...the suggested failure (Failure Technique around page regions (Header,
Footer, Nav, Main etc.) language doesn’t say anything about requiring
landmarks at all...
The proposed text states:
If the design visually indicates any of the following:
- header/banner
- footer/contentinfo *(Question: what exactly does a contentinfo region
visually look like?)*
- 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.
(So, in other words, I have to either use the <main> element or somehow
state in text "This is the main content of the page", because those are
apparently the only two options to avoid this Failure Technique, and
failing to do either means it would "...trigger a failure" on any page
currently reporting conformance to SC 1.3.1 today without either condition
present)
Additionally, David's response of 10 days ago
<#310 (comment)> also
confirms that this is about Landmarks:
"If there is a visual indicator of a header, footer, main, search, aside,
navigation AND there is distinct content in those sections, then yes.... *we
are saying there should be landmarks*."
You are free to believe this isn't about requiring Landmarks, but I think
the above quoted text makes it clear to many of us this is *exactly* about
requiring Landmarks (especially when the author of the proposal comes right
out and says so).
While I have been the most vocal about this, there *are* others voicing
concerns about this proposal as well:
-
"*...feel free to add this and see how the market responds to a new
failure being introduced that retrospectively makes conformant pages
non-conformant.*" (source: #310 (comment)
<#310 (comment)>)
-
"*...I do not see the viability of a Failure technique here.*" (source: #310
(comment)
<#310 (comment)>)
Feel free to argue against the technical concerns, but stop attempting to
make this about me (or others opposed to this proposal)
<#310 (comment)>, or
presuming to know what my or others motivations and goals are.
Better yet, perhaps follow your own suggestion that "...we table this until
after 2.1. <#310 (comment)>"
That, I could support fully.
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqyuGFDTBaf0IlaPrRtLeppthZ2DvZks5spBEPgaJpZM4OfpuQ>
.
|
The suggestion is in favour of failing someone for trying to do the right thing, but not failing a author for not trying? Shouldn't we put the cart before the horse? |
|
@DavidMacDonald Can this be closed? |
|
Let's punt it to a techniques discussion, so leave it open but defer it to after Rec. |
![https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open](https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open){kind=link}
|
Migrated to #307. |
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:
If the design visually indicates any of the following:
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:
If #2 and #3 are false then this failure condition applies.
Related Techniques
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.
The text was updated successfully, but these errors were encountered: