Wcag: 3.2.6 Findable Help - Does this SC really apply to "single page" web applications?

Created on 17 Sep 2020  路  16Comments  路  Source: w3c/wcag

For single page Web applications or any set of Web pages, if one of the following is available, then access to at least one option is included in the same relative order on each page:

  • Human contact details;
  • Human contact mechanism;
  • Self-help option;
  • A fully automated contact mechanism.

I don't see how a UI component can be included in the same relative order on each page within a single page web application.

Perhaps "single page" should be replaced with "multiple page"?

3.2.6 Findable help Public Comment Survey - Ready for WCAG 2.2

Most helpful comment

agree, this sounds more like a fundamental misunderstanding of what an SPA is?

All 16 comments

Initial draft response

That relative order on each page part of the sentence by definition, only applies to the set of Web pages and not single page Web applications.
This is valid for the relative order on a single page web application that is in fact just one view/ screen. This PR is meant to clarify that the intent is to have the same order even if the same URI is used to route between different views/ screens.

Single page web applications mean that there is a single file that serves the app, but that app can have multiple pages/screens.

Would there really be an exception for a web app that didn鈥檛 render help in the same location, just because it was built with react vs php? That鈥檚 ridiculous.

agree, this sounds more like a fundamental misunderstanding of what an SPA is?

https://github.com/w3c/wcag/pull/1538 this PR from another issue is meant to clarify that in the understanding document but we might need to address the definition of a web page. Didn't do that yet because it might have some downstream effects on other SCs that we didn't intend. Will do an inventory this week to make sure.

This suggested draft response seems to create confusion/ contradiction to the linked PR

The draft response is still valid for the relative order on a single page web application that is in fact just one view/ screen. The PR is meant to clarify that the intent is to have the same order even if the same URI is used to route between different views/ screens.

I would submit that the draft needs to explicitly say that then. As I would agree with that explanation, but that鈥檚 not what the draft (in this thread) says.

Single page web applications mean that there is a single file that serves the app, but that app can have multiple pages/screens.

My understanding is that the distinguishing feature of a SPA is that the URL does not change. Regardless, talking about a SPA having multiple pages is contradictory. But since a SPA could offer multiple screens, 3.2.6 could be applicable (as would 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification).

But I agree that we might need to tweak the phrasing for one or more of the above...

My understanding is that the distinguishing feature of a SPA is that the URL does not change

No. that's atypical for most SPAs that use proper routing, which update the URL for each "screen/view" and allow for the browser back button to function as if the spa wasn't loaded into a single file.

My understanding is that the distinguishing feature of a SPA is that the URL does not change

No. that's atypical for most SPAs that use proper routing, which update the URL for each "screen/view" and allow for the browser back button to function as if the spa wasn't loaded into a single file.

I agree with you @scottaohara . Perhaps it would be good to add a definition for "single page Web applications"?

My understanding is that the distinguishing feature of a SPA is that the URL does not change

back in the 90s perhaps ;)

but no, a distinguishing feature of an SPA is that the page is dynamically changed to different states, including changes that look like a completely different page was loaded. good SPAs also update the URL visible in the browser's URL bar, and can handle it when a user goes directly to this new "faked"/routed URL.

The 90s comment stings because it is true...

a distinguishing feature of an SPA is that the page is dynamically changed to different states, including changes that look like a completely different page was loaded

That is, I presume, the main thing. So if a modern SPA fakes looking like any other web app, why do we need to call them out?

That is, I presume, the main thing. So if a modern SPA fakes looking like any other web app, why do we need to call them out?

It might be a good idea to get rid of SPA completely and define the page based on browser's URL bar and talk about change of context and change of content.

Not being trapped in what a technical approach like routing in SPAs are... (do your thing however you like to, but we talk about URL and changes of context/content)

i think some of the discussion here is pointing to the fact that the actual definition of "Web page" may have flaws https://www.w3.org/TR/WCAG/#dfn-web-page-s

because weirdly there, it does normatively define things purely based on URL, including even mentioning single-page apps and saying essentially that they all count as a single web page (which yes, if the purpose is "is it in scope / do i need to test it" sure, that's true, but when it comes to SCs that talk about "web page" in terms of within a set or similar, it weirdly exempts them under the same logic)

New draft response:


I don't see how a UI component can be included in the same relative order on each page within a single page web application.
Perhaps "single page" should be replaced with "multiple page"?

Part of the confusion comes from the original definition of web-page, which is based on the URI, so oddly (to modern thinking) an SPA which does not update the URL is a 'web page', not a set of web pages.

For this SC we have three conditions covered by 2 definitions:

  • Web pages, in the traditional sense.
  • SPAs with different URIs, covered by the standard definition of web pages and 'set of web pages'.
  • SPA without routing (same URI), covered by the new SPA definition.

It is possible in an SPA (same URI style) could move navigation and/or help links around the layout, so the SC is intended to apply in this instance.

Please note we have added a paragraph on SPAs to the understanding document recently:

A single page Web application (compared to a Web page) shows multiple "pages" or views of content at the same URI. If a web application uses different URIs for each view of the content, that is considered multiple Web pages because the URI changes.

With that update to the understanding document, and this explanation, the group considers this issue addressed, but please re-open if there is something about this issues that you don't consider to be addressed.

The response was accepted by the group, so closing.

Was this page helpful?
0 / 5 - 0 ratings