Wcag: Language of Findable Help 3.2.6 is contradictory

[guyhickling]

SC3.2.6 says "For single page Web applications .... in the same relative order on each page". Single page Web applications by definition usually have only one page, so how can it say "on each page" for that type of site?

At the very least single page Web applications need some explanation in the Understanding doc.

Perhaps also some improved wording also in the SC? E.g. add "...or view" to the "on each page" (but that is just an off the cuff suggestion, I haven't thought the implications through).

[alastc]

Single page Web applications by definition usually have only one page, so how can it say "on each page" for that type of site?

Yep, so it is easy to fulfill in that scenario - you have it.

I'll add the 'needs assigning' label, hopefully we can get someone to add some text to the understanding doc.

[jake-abma]

So I got a question from my teams:

We have a SPA but of course do the routing ourselves (as lot's of site do)
In this case you do not have one page (or do you?!)

This is not clear as you do not 'get the page' from a server...

[scottaohara]

Single page Web applications by definition usually have only one page, so how can it say "on each page" for that type of site?

Yep, so it is easy to fulfill in that scenario - you have it.

I don't understand this response. Regardless of being an SPA or 'regular' website, users encounter different "pages".

SPAs have different screens/views which might have different templates/layouts, and if built with proper routing, each of these screens/views should have their own routing / individual URLs, making them indistinguishable to 'regular' website "pages" to the average user.

So with all that said, I really don't understand why SPAs are called out as if their "single page" implementation actually matters.

[patrickhlauke]

perhaps time to update this definition of "Web page" to explain that it's not so much the URI/URL per se, but the view/screen that matters? there's (badly made) SPAs that have all pages with the same URI, but completely different content depending on where you navigated to, and that content can have a completely different layout, navigation, content order, etc... So perhaps that definition needs to aknowledge that somehow?

https://www.w3.org/TR/WCAG21/#dfn-web-page-s

[guyhickling]

There are different ways of doing SPAs, but so long as the Understanding doc has a sentence or so mentioning SPA views to cover it, as @alastc plans above, I think that will be sufficient. Just to make sure this SC is watertight!

[scha14]

Draft response

https://github.com/w3c/wcag/pull/1538 PR to add text to understanding document

For a single page Web application, if the same URI routes to pages or views with different layouts or content, then each of those pages or views, have the supported ways of finding help in the same relative order

[alastc]

The following paragraph was added to the understanding document to clarify the SPA vs web page aspect:

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.

[jake-abma]

Our developers and also myself still have a hard time with this explanation.
This definition is just not what an SPA stand for, also not what multi-page web applications stand for.

See:

• https://en.wikipedia.org/wiki/Single-page_application
• https://medium.com/@NeotericEU/single-page-application-vs-multiple-page-application-2591588efe58

Of course we do understand how and why we want to make 'our own' definition to get in line with the Web Page definition WCAG already had, but the biggest issue raised here is:

A SPA with routing, does not make it a multi-page application.
It's still an SPA with the perception and navigability of separate logical pages in the application.

Not sure if creating our own / not globally shared definition of an SPA is the right way to go.

[jake-abma]

in short we're more in favor of talking about the proposed:

• Change of context

OR

• Change of content

So we do not have to define SPA at all

[alastc]

Jake, in the description from Wikipedia it says:

the location hash or the HTML5 History API can be used to provide the perception and navigability of separate logical pages in the application.

That means it clashes with our definition of web page, which is a resource at a URI. Where an SPA does that, it fits the definition of web page so it's covered. What we're trying to cover is SPAs which do not change the URI.

We also have a definition for change of context, which does not align, and we have a mention of 'change of content' as part of the change of context definition.

[jake-abma]

think a decision is already made, closing this one...