Failure Technique around page regions

[DavidMacDonald]

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

[pauljadam]

Looks great! Thanks David!

Paul J. Adam
paul@pauljadam.com

On Apr 5, 2016, at 5:18 PM, David MacDonald notifications@github.com wrote:

Ø "Failure of 1.3.1 due to visually distinct headers, footers, navigation bars, main content, or asides not being programmatically determinable or identified by text."

Note: the 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.

Description

This failure addresses the problem that occurs when sections of a page are visually distinct from other parts of the page, but are not easy to identify for those who cannot see those visual distinctions. People who are blind rely of screen reading software that identifies sections. There are a number of ways they can do this, but these sections must be identifiable, either in a way the screen reader can perceive, or they are identified in text that can be read by the screen reader.

Failure Procedure

Visually examine the page to confirm there are sections that are distinct
Check each section to confirm:

1. • These have been identified programmatically determinable way by Assistive Technology 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 HTML Section elements
Using text to identify sections of a page.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #173

[KerstinProbiesch]

Although I had to leave the WG out of time reasons I want to draw attention to SC 2.4.10 Section Headings (AAA). If the WG decides that the above failure is a failure for 1.3.1 (A) the WG should I believe clarify what the specific difference between 1.3.1 and 2.4.10 is. Especially because in the Understanding of 2.4.10 is written: "Other page elements may complement headings to improve presentation (e.g., horizontal rules and boxes), but visual presentation is not sufficient to identify document sections."

I think that the difference between 1.3.1 and 2.4.10 when we talk about section headings needs more attention. Also the Sufficient Techniques needs some attention I believe. H69 (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20160317/H69) is at that time a Sufficient Technique for 2.4.1 Bypass Blocks and 2.4.10 Section Headings but not for 1.3.1.

Cheers

Kerstin

[DavidMacDonald]

2.4.10 is not about regions of the page such as header, footer, nav, main content etc...
Here is a note from the SC
Note 2: This success criterion covers sections within writing, ...

Here is a clip from the understanding

"For instance, long documents are often divided into a variety of chapters, chapters have subtopics and subtopics are divided into various sections, sections into paragraphs, etc. When such sections exist, they need to have headings that introduce them. "

I think this shows the intent is to break up the actual document into manageable bites, rather than identify regions of a page. Perhaps I could add a sentence making the distinction, if people think there might be confusion.

[awkawk]

David, I'm not so sure that this is clear from the SC. 2.4.10 says that section headings are used to organize the content (and "section" is defined as "A self-contained portion of written content that deals with one or more related topics or thoughts", which is rather vague).

I do think that 1.3.1 applies, but I can also see people making a defensible argument that 2.4.10 does as well for a AAA site. Unfortunately that might mean that what we are thinking is the best way to meet 1.3.1 in conveying the structure of a page (landmarks) wouldn't pass AAA.

[KerstinProbiesch]

If 2.4.10 is not about regions H69 can not apply to 2.4.10:

"The objective of this technique is to use section headings to convey the structure of the content. Heading markup can be used: (...) to demarcate different navigational sections like top or main navigation, left or secondary navigation and footer navigation"

Also Example 2 of H69 would not apply to 2.4.10 if 2.4.10 is just about main content.

[DavidMacDonald]

Hmmm... I see the logic of that, but I wouldn't say that an example in a technique modifies or trumps what is discussed in the Understanding. The understandingof 2.4.10 is fairly clear that it applies to written content, and was intended to break long prose up into chapters etc... H69 can apply to it, but if a technique has an example that addresses some other SC, in this case 1.3.1, then I wouldn't say it modifies the understanding...

I would say the hierarchy is

• Normative SC
• Non-Normative Understanding
• Non-normative technique.

I wouldn't say that any of these can modify the one above it. I'd say they cascade downwards....

Anyway... I'm fine with managing any confusion in the description of the error. I'll add to it above...

[patrickhlauke]

So as soon as there's a visually distinct header or footer, and it's not explicitly marked up/denoted somehow, it's a failure? If I have a simple

<div><img src="logo.png" alt="MY SITE"></div>

styled to look like a horizontal banner, it's a failure that I don't use <header> or some other technique to explicitly mark this as a header?

or if I have a standard <div> with a simple "(C)2016 ..." type text, and I don't use <footer> or similar? Outright failure? ALWAYS? I would say this needs to be far more nuanced than an absolute statement

[patrickhlauke]

Rather than hinging on "visually distinct" regions, the wording should perhaps concentrate more on something along the lines of "if there are distinct regions, and it's important for the user to be able to distinguish them, as otherwise they may not be able to understand the overall structure of the page/screen/whatever, THEN it's a failure if these distinct regions are not somehow denoted either programmatically or in text" (or even through context/their content perhaps?)

[DavidMacDonald]

let's ask our blind friends what they want...

This is super easy to do and super useful for navigation. It's hard for me to say whether someone will understand the overall structure of the page without it ... but having content in the middle of the page with other distinct content in the footer and distinct content in the header, and distinct content in the Nav bar, should do be sufficient to trigger this failure... I'd say...

[DavidMacDonald]

I've updated it to say "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."

[KerstinProbiesch]

Let it be supposed that 2.4.10 covers just Headings and Labels in main content: In this case H69 in it's actual form should not apply to 2.4.10 as Sufficient Technique - not only because of example 2 but also because of the following two points in the description: "to demarcate different navigational sections like top or main navigation, left or secondary navigation and footer navigation" and "to allow users the ability to navigate a page by sections or skip repeated blocks of information" and because of the second part of the testing procedure.

Of course we have Note 2 in the SC which says that "This success criterion covers sections within writing, not User Interface components". But Note 2 also says: User Interface Components are covered under 4.1.2. If one would argue that for example a footer or a header is a Userface Component than the Note 2 indicates that 4.1.2 is relevant. Or am I missing something. When it comes to regions / sections like Footer etc. Note 2 seems to be a bit confusing and there is no way to change the wording of 2.4.10. Also the SC says "organize the content." not "organize the main content". Ok. Probably a bit quibbling ;-)

Beside of the actual discussion of regions I think the whole Understanding of 2.4.10 needs some attention and H69 should not apply to 2.4.10 but another technique is needed and that a separate issue on github and later for related documents is needed.

But back to the discussion of the new failure:

In case a failure is needed, a proper definition about what "visual distinct" means should be included to explicitly seperate this failure for SC X from a failure for 1.4.1 and to avoid confusion.

The wording "not easy to identify" seems to be a bit vague - although it is not part the testing procedure. Or?

One example (the page is not live, therefore no link): A university website with different disciplines / subjects. At the end (let's say a page with FAQ) two contact addresses are given - one for the specific discipline (let's say 'Arts and Sciences') and one for the central administration. For each contact address a different background is provided and for each contact address a proper heading nested correctly in the overall H-Hierachy of the document is also provided.

Would we have in the light of the new failure for WCAG in this case a region (because of "different content") and how many regions? One region (both contact addresses together) or two regions because of two different visual distincts at the end of the page? Or would it be still sufficient because of the proper heading structure which indicates the relationship of the contact addresses to the main content and other contents (and of course a proper wording (2.4.6) is given)?

[DavidMacDonald]

This is a failure based on regions of a page not being programmatically determinable (or marked in text). So minor changes within the region don't apply. I think the audience will know the examples of header, footer, main, navigation, aside. These regions are so well known that HTML5 created tags for them.

I don't expect much confusion

[cstrobbe]

I would like to propose some editorial changes:

• "rely of" -> "rely on"
• "ways they can do identify regions" -> "ways they can identify regions"
• I would also rephrase the last part of the last sentence:
  "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." (I deleted the comma after "text" because text that is hidden to a screen reader would be useless.)

[DavidMacDonald]

I've made the adjustments... thanks Christophe

[MakotoUeki]

+1 to David's proposal.

1.3.1 requires "Information, structure, and relationships conveyed through presentation" to be machine-readable ("be programmatically determined or are available in text"). If there are visually distinct regions, then the regions must be machine-readable. It doesn't require each section/region to have a heading.

On the other hand, 2.4.10 requires each section of a web page to have a heading. If there is a section which doesn't have a heading, we must add a heading to the section.

This is my understanding. So I don't see any confusion on this difference.

[Ryladog]

+1

​​​​​

• katie *

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

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

From: Makoto Ueki [mailto:notifications@github.com]
Sent: Monday, April 11, 2016 9:52 PM
To: w3c/wcag wcag@noreply.github.com
Subject: Re: [w3c/wcag] New Failure around page regions (#173)

+1 to David's proposal.

1.3.1 requires "Information, structure, and relationships conveyed through presentation" to be machine-readable ("be programmatically determined or are available in text"). If there are visually distinct regions, then the regions must be machine-readable. It doesn't require each section/region to have a heading.

On the other hand, 2.4.10 requires each section of a web page to have a heading. If there is a section which doesn't have a heading, we must add a heading to the section.

This is my understanding. So I don't see any confusion on this difference.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #173 (comment) https://github.com/notifications/beacon/AFfqyuVGPnfNig-1lL8N34uYbwmeFjl8ks5p2vq3gaJpZM4IAh6M.gif

[spanchang]

ARIA11 was added only in 2014 to the techniques and quickly became the first in the list of techniques for SC 1.3.1.
In 2014, the following statements in ARIA11 did pass muster:
"Landmarks should supplement native semantic markup such as HTML headings, lists and other structural markup. Landmarks are interpretable by WAI-ARIA-aware assistive technologies and are not exposed by browsers directly to users. ... It is a best practice to include ALL content on the page in landmarks, so that screen reader users who rely on them to navigate from section to section do not lose track of content".

As a SR user, sure landmarks are a great help when used consistently and not incompletely (like nav and contentinfo are present on some pages but not banner and main).
At a minimum, skip links also help and has been on the books from the beginning. Technique G124, (Adding links at the top of the page to each area of the content) sort of addresses this and may be sufficient to expose page structure in some circumstances but surely is not as effective as landmarks.

But can we now fail a page today that has passed WCAG2 yesterday without landmarks? So for practical reasons, I hesitate to call it a failure.
I stongly believe accessibility consultants should nudge developers to use HTML5 sectioning elements and ARIA landmarks when content is being developed or re-done or accessibility issues are being addressed.

SC 2.4.10 requires adding section headings when headings are simply not present and may not be germane to the discussion to the question on use of landmarks.
Making info relationships available in text requires placing text labels like, "Main content:" or "Footer content: " before those sections for instance. And these need not be headings. This is a minimum in the absence of programmatic markup to expose those sections. Technically those labels need to be visible too but that will seldom pass muster from a UI design QA viewpoint.
Off-screen headings marked up as an h5 or h6 before breadcrumb nav, like "You are here ..." is an example ofmarkup to aid non-sighted users only.
Thanks and regards,
Sailesh

[DavidMacDonald]

There is no requirement in this failure to use Landmarks or HTML 5 elements. It is the easiest way not to fail, but using headings, or text is also an acceptable way not to fail this. This is about the easiest win any web site can have, and there is no reason why its not done. Information and Relationships 1.3.1 requires notifying the user of visually distinct sections of distinct content, that are not programatically determinable or available in text.

[patrickhlauke]

relative to my comment #173 (comment) I guess if it's contextually clear that something is, say, a footer (if it's only a copyright notice) count as "easy to identify" from context in light of

are not easy to identify for those who cannot see those visual distinctions

so those examples I gave woud pass, and not fail, by their nature. if this aspect is clear, i'd have no objection to this particular failure per se, cautiously anyway.

[adamsolomon]

using headings brings us back to 2.4.10. For whatever reason headings were not required at AA to distinguish regions of the page. Every web page will generally have different regions of content yet headers are optional. The argument that there might be some other way to avoid this failure besides headings and landmarks might theoretically be true yet perhaps not requiring headings in spirit meant that WCAG did not require markup for different regions of the page.

[patrickhlauke]

well you can't require headings (which are only but one possible technique) if there are other ways to achieve an acceptable outcome for the SC.

[adamsolomon]

At AAA we do require headings (2.4.10)

[patrickhlauke]

yes but here we're talking about 1.3.1, which is A. or am i missing the point you're trying to make?

[adamsolomon]

the point is that headings were clearly not required for 1.3.1 to distinguish regions from the fact that 2.4.10 did not mandate them, and even though some would then immediately point out that some other technique could possibly be used besides headings, yet it seems that the spirit of 2.4.10 indicates that WCAG did not consider distinguishing regions as being required under 1.3.1 (though certainly I would defer to those who were present at the drafting of WCAG). Not every structure is required to have programmatic determination in 1.3.1

[cstrobbe]

Hi @adamsolomon,
As far as I can remember, headings were not required at level AA because there can be web content where headings do not apply. However, if something visually looks like a heading, SC 1.3.1 requires that it be programmatically determinable as a heading.

[adamsolomon]

agreed. i was actually referring to regions. What I meant was:
2.4.10 mandates headings for regions of content only at AAA, indicating (but not proving) that regions of content were not covered by 1.3.1 at AA (for if they were there would be no need for 2.4.10 at AAA).
Of course the argument could be made that since 1.3.1 might theoretically be satisfied by something other than headings therefore 2.4.10 would in any event be necessary. However, since landmarks did not exist it is likely that the spirit was that regions of content did not need to be distinguished under 1.3.1
Not all content is covered by 1.3.1. As an example we had a big discussion a while back about definition lists. There was a debate as to whether or not they needed a special markup such as dl-dd-dt. Actually I pushed for an example of definition list to be added to the h48 but my point is that not all content structure is covered by 1.3.1. I agree that this is important and should definitely be included in the extensions, however i am not convinced that wcag 2 covers it.
I referred to headings only as a possible way of satisfying 1.3.1 for regioned content.

[awkawk]

Closing as a result of the May 24 discussion and adding the "WCAG.Next label" to ensure it doesn't get lost.