Are headers/footer or ARIA equivalents required to meet WCAG success criteria SC 1.3.1

[mraccess77]

Some accessibility SME contend markup for headers footers and navigation are required. What does the working group say.

https://twitter.com/pauljadam/status/707661594818252802?cn=cmVwbHk%3D&refsrc=email

[awkawk]

At a minimum not all pages have headers, footers, and navigation, so ARIA landmarks are not required by WCAG for all pages and the first reason to not make such a blanket statement. I'd say pose the question to the group, ideally with an example page as a reference, and see what people think.

[pauljadam]

Both www.google.com http://www.google.com/ and www.apple.com http://www.apple.com/ have a clearly designed header and footer areas that visually stand out as the header and footer sections. The navigation areas also stand out visually. Most all real-word websites have the same visually identifiable headers, footers, main content areas, and navigation areas.

1.3.1 http://www.w3.org/TR/2008/REC-WCAG20-20081211/#content-structure-separation-programmatic Info and Relationships: Information, structure https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#structuredef, and relationships https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#relationshipsdef conveyed through presentation https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#presentationdef can be programmatically determined https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#programmaticallydetermineddef or are available in text. (Level A)

So the page’s structure is conveyed through presentation clearly. This structure must also be programmatically determinable to AT.

Landmarks and/or HTML5 semantic structural elements are the best way to meet that SC. There really is no other way to say that the large footer section on apple.com http://apple.com/ is the footer to a screen reader user other than using landmarks or

tag. Otherwise they’d just have to guess the area of the page or you’d have to use visually hidden headings that say

Footer Section:

. No one uses a visually hidden heading method to make their page’s structure programmatically determinable.

Apple’s footer area:

Apple wraps their footer area in a contentinfo landmark and wraps the footer navigation in a navigation landmark.

I have heard people argue that landmarks could not possibly be required by WCAG because they were not invented when WCAG was released. That’s a weak argument that would lead to exclusions for mobile native apps as those were not around either when WCAG came out.

Thanks!

Paul J. Adam
paul@pauljadam.com

On Mar 31, 2016, at 2:42 PM, Andrew Kirkpatrick notifications@github.com wrote:

At a minimum not all pages have headers, footers, and navigation, so ARIA landmarks are not required by WCAG for all pages and the first reason to not make such a blanket statement. I'd say pose the question to the group, ideally with an example page as a reference, and see what people think.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #171 (comment)

[awkawk]

@pauljadam That's fine, your point is clear, we will see what others say.

You do indicate that one might use HTML elements to address the same goal of conveying the structure, instead of using ARIA landmarks. As Jon indicated, the ARIA11 technique is sufficient, but not required to meet 1.3.1, and you seem to agree based on what you wrote above. Is that a fair statement?

[pauljadam]

I’m saying that you have to use either ARIA Landmarks, HTML5 Semantic Structural Tags, or both. One or both are required.

Paul J. Adam
paul@pauljadam.com

On Mar 31, 2016, at 3:27 PM, Andrew Kirkpatrick notifications@github.com wrote:

@pauljadam https://github.com/pauljadam That's fine, your point is clear, we will see what others say.

You do indicate that one might use HTML elements to address the same goal of conveying the structure, instead of using ARIA landmarks. As Jon indicated, the ARIA11 technique is sufficient, but not required to meet 1.3.1, and you seem to agree based on what you wrote above. Is that a fair statement?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #171 (comment)

[awkawk]

But what you said before was "Yes #WCAG requires #ARIALandmarks."

[pauljadam]

That’s what I’m still saying.

I’m talking about real world websites like apple.com http://apple.com/, google.com http://google.com/, adobe.com http://adobe.com/, deque.com http://deque.com/ these all require landmarks. If it’s just a plain page with no header, footer, no navigation those landmarks would not be required. However, if a basic page has a clearly defined main content area styled to look that way visually then we’d have to make that programmatically determinable to AT.

Paul J. Adam
paul@pauljadam.com

On Mar 31, 2016, at 4:38 PM, Andrew Kirkpatrick notifications@github.com wrote:

But what you said before was "Yes #WCAG requires #ARIALandmarks."

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #171 (comment)

[awkawk]

Please reconcile these statements:
"Landmarks and/or HTML5 semantic structural elements are the best way to meet that [1.3.1] SC."
"Yes #WCAG requires #ARIALandmarks."

Let us know and we will discuss this and the other half of the issue, which is whether a page like google.com meets 1.3.1 without either, which I understand you are saying is doesn't.

[pauljadam]

I’m not sure how many different ways I have to say that Landmarks are Required by WCAG?

On all the links I provided landmarks are required for 1.3.1. I’ve already said why many times. It’s up to you if you’d like to discuss the issue. It’s pretty clear to me from the normative wording of 1.3.1.

Thanks!

Paul J. Adam
paul@pauljadam.com

On Mar 31, 2016, at 4:44 PM, Andrew Kirkpatrick notifications@github.com wrote:

Please reconcile these statements:
"Landmarks and/or HTML5 semantic structural elements are the best way to meet that [1.3.1] SC."
"Yes #WCAG requires #ARIALandmarks."

Let us know and we will discuss this and the other half of the issue, which is whether a page like google.com meets 1.3.1 without either, which I understand you are saying is doesn't.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #171 (comment)

[MakotoUeki]

If it’s just a plain page with no header, footer, no navigation those landmarks would not be required. However, if a basic page has a clearly defined main content area styled to look that way visually then we’d have to make that programmatically determinable to AT.

I agree with Paul on this.

I’m saying that you have to use either ARIA Landmarks, HTML5 Semantic Structural Tags, or both. One or both are required.

It would be an "accessibility supported" iisue whether ARIA landmarks are required or not. If HTML5 Semantic Structural Tags are considered to be "accessibility supported" and they are used on the page, ARIA landmarks are not required. But if HTML5 Tags are not "accessibility supported", then ARIA landmarks or any other alternatives must be provided.

In Japanese, HTML5 Semantic Structural Tags are not "accessibility supported" at this moment. So when we use them on Japanese websites, we must use ARIA landmarks to meet SC 1.3.1. Once HTML5 tags become "accessibility supported", using HTML5 tags only could meet SC 1.3.1.

[mraccess77]

[paul wrote] I’m not sure how many different ways I have to say that Landmarks are Required by WCAG?

Paul, this is your interpretation. A success criteria can be met many ways. For example, the search field of a page is clear by a field with a label of search without requiring a search landmark. A header or footer could be communicated via off-screen text without using a landmark – if even that is necessary for users to understand it’s a heading or footer. Just because Google places footer links in an area with a different background doesn’t mean the user cannot perceive the purpose of the link from the link text and understand it’s a global link. Users have been working with web pages for 20 years and this was never seen as a requirement until now -- why is it now an issue?

If the working group determines these are required then we need documented failures – without documented failures I don’t see how we can say something specific is required. If it’s so important that it’s a failure then the techniques need to support that.

Jonathan

[awkawk]

@pauljadam To clarify the distinction that I'm drawing here, I don't consider HTML native elements to be ARIA landmarks. As a result, when you say "WCAG requires ARIA Landmarks", I disagree, and feel that you do also. In your last reply you switched to saying "Landmarks are required" instead of ARIA landmarks, and that is a more general case.

Even with that, we will discuss this more general case and provide the working group's opinion.

[pauljadam]

Folks don’t use off screen text to convey their header, footer, navigation, or main content areas. Sure it’s possible to do that but I’ve never seen it done!

It seems very obvious that most headers, footers, navigations all have a very distinct visual design, gray backgrounds, solid rectangle borders, something to really help them stand out visually to sighted users. Sighted users have the visual cues to quickly identify these page areas.

I don’t think 16 year old kids are have been on the web for 20 years. I myself have not been on the web for 20 years or maybe I have just reached that age :)

It’s always been an issue that sighted folks get the visual design and screen reader users have not received that same presentation conveyed in a method they can understand via their AT.

I’ll volunteer to write a failure technique.

I’ve never written one before but here’s a first draft idea.
———————
F131: Failure of Success Criterion 1.3.1 due to conveying structure and relationships through presentation that are not programmatically determinable.

Tests

Procedure

1. Check that the structure and relationships conveyed through presentation are also programmatically determinable.

Expected Results

1. If check Text edit line 1837 remove quotation marks #1 is false then this failure condition applies.
   ———————

Thanks!

Paul J. Adam
paul@pauljadam.com

On Apr 1, 2016, at 9:12 AM, Jonathan Avila notifications@github.com wrote:

Ø I’m not sure how many different ways I have to say that Landmarks are Required by WCAG?

Paul, this is your interpretation. A success criteria can be met many ways. For example, the search field of a page is clear by a field with a label of search without requiring a search landmark. A header or footer could be communicated via off-screen text without using a landmark – if even that is necessary for users to understand it’s a heading or footer. Just because Google places footer links in an area with a different background doesn’t mean the user cannot perceive the purpose of the link from the link text and understand it’s a global link. Users have been working with web pages for 20 years and this was never seen as a requirement until now -- why is it now an issue?

If the working group determines these are required then we need documented failures – without documented failures I don’t see how we can say something specific is required. If it’s so important that it’s a failure then the techniques need to support that.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.commailto:jon.avila@ssbbartgroup.com
703.637.8957 (Office)

Visit us online: Websitehttp://www.ssbbartgroup.com/ | Twitterhttps://twitter.com/SSBBARTGroup | Facebookhttps://www.facebook.com/ssbbartgroup | Linkedinhttps://www.linkedin.com/company/355266?trk=tyah | Bloghttp://www.ssbbartgroup.com/blog/
Check out our Digital Accessibility Webinars!http://www.ssbbartgroup.com/webinars/

From: Paul J. Adam [mailto:notifications@github.com]
Sent: Thursday, March 31, 2016 5:48 PM
To: w3c/wcag
Cc: Jonathan Avila
Subject: Re: [w3c/wcag] Are headers/footer or ARIA equivalents required to meet WCAG success criteria SC 1.3.1 (#171)

I’m not sure how many different ways I have to say that Landmarks are Required by WCAG?

On all the links I provided landmarks are required for 1.3.1. I’ve already said why many times. It’s up to you if you’d like to discuss the issue. It’s pretty clear to me from the normative wording of 1.3.1.

Thanks!

Paul J. Adam
paul@pauljadam.commailto:paul@pauljadam.com

On Mar 31, 2016, at 4:44 PM, Andrew Kirkpatrick <notifications@github.commailto:notifications@github.com> wrote:

Please reconcile these statements:
"Landmarks and/or HTML5 semantic structural elements are the best way to meet that [1.3.1] SC."
"Yes #WCAG requires #ARIALandmarks."

Let us know and we will discuss this and the other half of the issue, which is whether a page like google.com meets 1.3.1 without either, which I understand you are saying is doesn't.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #171 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/171#issuecomment-204145688
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #171 (comment)

[yatil]

I think landmarks are already in the sufficient techniques (quickref link), so this is already covered. WCAG is technology independent and this can’t require ARIA. ARIA11 and G115 might cover the ARIA and the HTML5 case, but a dedicated HTML5 technique probably would be useful.

Note that we (EO/I, and reviewed by WCAG) recommend using HTML5 structural elements in the draft tutorial on page structure.

[DavidMacDonald]

I would like to introduce a new failure based on this discussion.

"Failure of 1.3.1 due to visually distinct headers, footers, navigation bars, main content, or asides providing no ACCESSIBLE NAME (or ACCESSIBLE DESCRIPTION)"

WCAG does not require any specific technique to do this (landmarks, html 5

etc, and headings could all work), however, in the API the ACCNAME, or ACCDESCRIPTION need to be populated with meaningful Label (Name).

[jnurthen]

@DavidMacDonald I strongly disagree with this proposed new failure. Most landmarks do not require an accessible name if only used once on the page, and I don't see how adding an accessible name for a header, footer or main for example adds to the usability for anyone. Indeed I believe it only adds extra noise for screen reader users.

[LJWatson]

Strongly agree with @jnurthen on this. For unique landmark regions there is no need to provide an accessible name, and to do so would usually add to the "noise" of the page for screen reader users.

[pauljadam]

Yes I’m only asking for the usage of all landmarks necessary for the page, not that each landmark have an accessible name. I do recommend unique accessible names for multiple navigation landmarks if possible but not sure if that’s required.

This is the sort of landmark usage I’m looking for http://pauljadam.com/demos/landmarks.html

Once all the HTML5 sectioning elements correctly identify themselves as landmarks to screen readers there would be no need for the aria role landmark attributes. I only add them right now due to AT bugs not supporting all HTML5 tags and as training so people know the difference in wording e.g. footer vs contentinfo.

Thanks!

Paul J. Adam
paul@pauljadam.com

On Apr 5, 2016, at 11:32 AM, Léonie Watson notifications@github.com wrote:

Strongly agree with @jnurthen https://github.com/jnurthen on this. For unique landmark regions there is no need to provide an accessible name, and to do so would usually add to the "noise" of the page for screen reader users.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #171 (comment)

[DavidMacDonald]

OK how about

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

[Ryladog]

Better

[awkawk]

What about "or available in text"?

[DavidMacDonald]

We have a nice tight definition of Programatically determined, which is consistent with the intent here that these sections be discoverable with AT
https://www.w3.org/TR/WCAG20/#programmaticallydetermineddef

[mraccess77]

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

You would have to add “or available as text” per SC 1.3.1 or else the failure would be stronger than the SC.

Also, the wording “visually distinct” isn’t enough IMO to warrant a failure – that is there would have to be some information or relationship that was not communicated another way.

Jonathan

[DavidMacDonald]

I think the information that needs to be communicated is that it is a header, footer etc... that's what the section colour does in the visual interface... I don't think more is required...

[awkawk]

From today's call we discussed the survey item around this issue (https://www.w3.org/2016/04/05-wai-wcag-minutes.html#item05):

The resolution:
WG agrees that Landmarks are not required to meet SC 1.3.1 for any page with head/foot/navigation areas as there are other ways to indicate a page's structure.

We will send that out for a Call for Consensus to the list (https://lists.w3.org/Archives/Public/w3c-wai-gl/2016AprJun/0060.html)

Regarding new failures or success techniques, can we do that as a new issue and reference this discussion from that?

[Ryladog]

Agree to add "or available in text"

[awkawk]

Discussed on April 5 WCAG call, following a survey, and the WG reached consensus on this statement:

"The Working Group agrees that Landmarks are not required to meet SC 1.3.1 for any page with head/foot/navigation areas as there are other ways to indicate a page's structure."

CfC reference: https://lists.w3.org/Archives/Public/w3c-wai-gl/2016AprJun/0095.html