DavidMacDonald commented 7 years ago

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

Text of the Failure Proposal

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

Description

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

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

If the design visually indicates any of the following:

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

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

Failure Procedure

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

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

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

Related Techniques

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

This failure was created April 5, 2016

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

DavidMacDonald commented 7 years ago

There is the ability to navigate with keyboard to landmarks without a screen reader http://pauljadam.com/bookmarklets/landmark-heading-nav.html Although I would say even without this functionality creating a failure for not marking up visual regions programmatically has all kinds of precedence in WCAG.

DavidMacDonald commented 7 years ago

No, but it is a new idea.

The first sentence of this issue says:

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.

Does it need be any clearer?

detlevhfischer commented 7 years ago

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). In that sense, new Techniques, even very focused Failure Techniques like the ones JF has sketched, make sense. I think the attempt to limit this Failure to 2.1 conformance claims is missing the point that it will not always apply to all content, which I think has been convincingly argued. This objection holds even if there was consensus to tie Techniques to particular WCAG releases (which I think would further complicate an already very complex standard and make its application more difficult).

DavidMacDonald commented 7 years ago

it will not always apply to all content, which I think has been convincingly argued

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.

detlevhfischer commented 7 years ago

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. One further example would be the use of <nav> or role=navigation. We have had (in tandem tests and in quality assurance) various discussions about pages using landmarks where we have debated whether an author should have marked up all navigation constructs including breadcrumb, or whether sticking to fewer might actually be advantageous for non-sighted use. I think this is an open call and depends on the complexity of the page - and is certainly not something that can be nailed down with the hammer of a Failure technique.

jake-abma commented 7 years ago

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

Ryladog commented 7 years ago

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" notifications@github.com 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 https://github.com/w3c/wcag21/issues/310#issuecomment-331702532, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqyrcwTR0GAWriWABG7TuP6jweUeHpks5sljcjgaJpZM4OfpuQ .

DavidMacDonald commented 7 years ago

Just some situations:

A: The Header and Footer have backgrounds but the contrast doesn’t pass the 4.5:1 condition. It’s just a very light grey while the rest of the page is white. Is this enough? Do we need to account for a specific contrast ratio?

If there is distinct content in those sections and a visual indication it should have a landmark

B: The Header has 200px height but only the top 30px are dark with some white links, the rest of the 170px is white with a white Main below it. The Header has content (a main menu with colours and styling) which sets them apart from the rest of the page so you could make up what the header is, but also not really. Will it pass or not?

I think the clue here is the discussion of the characteristics of header. It would require a role.

C: There is a Header, Main, Footer and the Body has a gradient on the whole page with dark overlap of the Header and part of the Main, turning light in colour and ending at the footer again with dark. The Header and a part of the Main has light text (on the dark part of the gradient) but this ‘turn’ a bit further down the Main. Will it pass or fail?

Again there is discussion of the different parts of the page. Those sections would require roles.

D: There are ‘cards’ or ‘panels’ on the right with no other coloured background but visually you could argue (also because of the content) it’s an Aside (complementary). But also there’s content in the ‘panels’ / ‘card/ which doesn’t really belong to the Aside. Will it pass or not?

If there content makes up part of the main topic of the page it does not require a new role for aside.

E: A designer just likes to add borders / horizontal rows / vertical rows on the page. The are between the Header and Main, but also in the Main itself. The contrast is very light though. Is it enough to pass or fail?

If the content in those sections was distinct and there are visual indicators it would require roles.

F: The Header and Main have a ‘image’ between them (some place them in the Main, Some in the Header). Is this enough to pass / fail?

The image does not need a role.

One further example would be the use of
or role=navigation. We have had (in tandem tests and in quality assurance) various discussions about pages using landmarks where we have debated whether an author should have marked up all navigation constructs including breadcrumb.

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.

jake-abma commented 7 years ago

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)

DavidMacDonald commented 7 years ago

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.

Ø "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."

jake-abma commented 7 years ago

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? The same for other landmarks like footer with only one ordered list or search with only an input and button.

mraccess77 commented 7 years ago

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

Ryladog commented 7 years ago

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" notifications@github.com 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 https://github.com/w3c/wcag21/issues/310#issuecomment-331749127, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqykF5-GGDHS6M8lJbGoZ0YwUJ2nFSks5slu1UgaJpZM4OfpuQ .

mraccess77 commented 7 years ago

"Distinct" doesn't necessarily mean that it communicates information needed to understand the relationship. Decorative content can be distinct.
As I said I would support a failure if it allowed a range of solutions such as use of an headings as an example of programmatic determination.
The Failure doesn't seem to cover sections or articles -- is the parenthesis just example or an inclusive list of what is covered?

johnfoliot commented 7 years ago

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 .

JF

On Saturday, September 23, 2017, David MacDonald notifications@github.com wrote:

No, but it is a new idea.

The first sentence of this issue says:

This is an issue originally filed as Issue #173 https://github.com/w3c/wcag21/issues/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 https://github.com/w3c/wcag21/issues/310#issuecomment-331679856, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c7UzHxLZwLvTSNrGTSXKQTB_DWc3ks5slazNgaJpZM4OfpuQ .

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

Advancing the mission of digital accessibility and inclusion

johnfoliot commented 7 years ago

As a clarification of my previous comment, David previously stated:

The first sentence of this issue says:

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.

Does it need be any clearer? (https://github.com/w3c/wcag21/issues/310#issuecomment-331679856)

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

DavidMacDonald commented 7 years ago

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.

johnfoliot commented 7 years ago

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 notifications@github.com Date: 9/26/17 5:12 PM (GMT-05:00) To: w3c/wcag21 wcag21@noreply.github.com Cc: John Foliot john.foliot@deque.com, Mention mention@noreply.github.com Subject: Re: [w3c/wcag21] Failure Technique around page regions (Header, Footer, Nav, Main etc.) (#310) 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\nfiled as Issue #173 for WCAG 2.\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":"https://github.com/w3c/wcag21/issues/310#issuecomment-332337773"}}}

johnfoliot commented 7 years ago

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

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 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 and fundamentally changing the backward compatibility requirements we are working under.

Ryladog commented 7 years ago

John,

You wrote

Finally, elsewhere https://github.com/w3c/wcag21/issues/392#issuecomment-331558048 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 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)

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

From: John Foliot [mailto:notifications@github.com] Sent: Wednesday, October 4, 2017 3:21 PM To: w3c/wcag21 wcag21@noreply.github.com Cc: Katie Haritos-Shea ryladog@gmail.com; Mention mention@noreply.github.com 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 https://github.com/w3c/wcag21/issues/310#issuecomment-318435035 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 https://github.com/w3c/wcag21/issues/310#issuecomment-331453737 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 https://github.com/w3c/wcag21/issues/392#issuecomment-331558048 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 https://github.com/w3c/wcag21/issues/310#issuecomment-334261987 , or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqysU6cfBKOE1BmfnjcXnNNMSHdfUDks5so9qIgaJpZM4OfpuQ . https://github.com/notifications/beacon/AFfqyhg72hXwevA9hyKTHBhjDwebcDkBks5so9qIgaJpZM4OfpuQ.gif

johnfoliot commented 7 years ago

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 - 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 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 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: https://github.com/w3c/wcag21/issues/310#issuecomment-317749771)
"...I do not see the viability of a Failure technique here." (source: https://github.com/w3c/wcag21/issues/310#issuecomment-330059040)

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.

Ryladog commented 7 years ago

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:

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 https://github.com/w3c/wcag21/issues/2 and #3 https://github.com/w3c/wcag21/issues/3 are false then this failure condition applies. Related Techniques

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

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" notifications@github.com 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 https://github.com/w3c/wcag21/issues/310#issuecomment-318435035 - and here as well https://github.com/w3c/wcag21/issues/310#issuecomment-331462585), 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

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 https://github.com/w3c/wcag21/issues/310#issuecomment-331708742 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) https://github.com/w3c/wcag21/issues/310#issuecomment-317749771)

"...I do not see the viability of a Failure technique here." (source: #310 (comment) https://github.com/w3c/wcag21/issues/310#issuecomment-330059040)

Feel free to argue against the technical concerns, but stop attempting to make this about me (or others opposed to this proposal) https://github.com/w3c/wcag21/issues/310#issuecomment-317827612, 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. https://github.com/w3c/wcag21/issues/310#issuecomment-317715703" That, I could support fully.

Thanks.

— You are receiving this because you were mentioned.

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

DavidMacDonald commented 7 years ago

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

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?

joshueoconnor commented 6 years ago

@DavidMacDonald Can this be closed?

DavidMacDonald commented 6 years ago

Let's punt it to a techniques discussion, so leave it open but defer it to after Rec.

michael-n-cooper commented 6 years ago

Migrated to https://github.com/w3c/wcag21/issues/307.

w3c / wcag21

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

Text of the Failure Proposal

Description

Failure Procedure

Related Techniques

Continuing to suggest otherwise is nothing but an ad hominem attack on your part.

"...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) https://github.com/w3c/wcag21/issues/310#issuecomment-317749771)