Re: Adding Findable Help - SPAs

Hey Alastair,
I think this definition works reasonably well. I see no reason to leave
SPAs out as long as we can define it, which I think this does. But there
certainly could be things I've missed in that suggested definition.

W

On Tue, Jun 16, 2020 at 8:13 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Trying to take this off the CFC thread again...
>
> I'm now wondering if we need to include SPAs at all?
>
> For context, there are generally two types:
> 1. The old fashioned variety where you load the first page and everything
> happens under the same URL (and title).
>
> 2. Newer SPAs (generally based on newer frameworks) usually update the URL
> (and title), even though the mechanics Steve described are the same.
>
> The second type fits our current definition of page (reasonably) because
> the URI updates.
>
> The first type does not, but also doesn't tend to change the header/footer
> (likely locations for help) either.
>
> Wilco wrote:
>         > The suggestion I made before was to base "SPA" on navigation
> mechanisms that change the purpose of the web page. I think that's a fairly
> reliable way to define an SPA. It's based on some existing language in
> WCAG, so that would help.
>
> That would be a change of "content that changes the meaning of the Web
> page".
>
> We'd have to convert that to something like:
> "Single page web apps: Pages obtained from a single URI that provide
> navigation which changes the meaning of the Web page."
>
> I'm not sure we need to include SPAs now that we've switched the structure
> to an "if/then", but if so does that help?
>
> -Alastair
>


-- 
*Wilco Fiers*
Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R