Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
LiLoDavis opened this issue Sep 17, 2020 · 16 comments

Comments

@LiLoDavis
Copy link

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"?

@alastc alastc added this to To do in WCAG 2.2 via automation Sep 19, 2020
@scha14 scha14 self-assigned this Nov 21, 2020
@scha14
Copy link
Contributor

scha14 commented Nov 21, 2020

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.

@scottaohara
Copy link
Member

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’t render help in the same location, just because it was built with react vs php? That’s ridiculous.

@patrickhlauke
Copy link
Member

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

@scha14
Copy link
Contributor

scha14 commented Nov 23, 2020

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

@scottaohara
Copy link
Member

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

@scha14
Copy link
Contributor

scha14 commented Nov 23, 2020

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.

@scottaohara
Copy link
Member

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

@bruce-usab
Copy link
Contributor

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

@scottaohara
Copy link
Member

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.

@mfairchild365
Copy link

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"?

@patrickhlauke
Copy link
Member

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.

@bruce-usab
Copy link
Contributor

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?

@jake-abma
Copy link
Contributor

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)

@patrickhlauke
Copy link
Member

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)

@alastc
Copy link
Contributor

alastc commented Dec 31, 2020

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.

@alastc
Copy link
Contributor

alastc commented Jan 5, 2021

The response was accepted by the group, so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
WCAG 2.2
  
Done
Development

No branches or pull requests

8 participants