Client-side routing

[penx]

Suggestion

Please can you clarify whether client side routing can be used in a web application and still meet the UK Government Service Standard?

If it is possible to achieve this, are you able to detail what technical issues must be overcome and any tests developers can do to ensure they are building accessible client side routing?

If it is not possible, can you please outline why, in a way that can be retested in future?

Evidence (where applicable)

While we were developing govuk-react, we tried to offer advice on this in our accessibility statement here:

https://github.com/govuk-react/govuk-react/blob/master/ACCESSIBILITY.md#client-side-routing

Unfortunately this advice isn't completely clear, and I'm not sure we can make any progress on it.

This was a couple of years ago, but from memory, our understanding (via @NickColley) was that on certain devices, there was no way to announce navigation to a new route. However, without a list of the devices that exhibit these issues, we are not able to find the current status (e.g. via a software update) or research potential fixes.

Related

• https://almerosteyn.com/2017/03/accessible-react-navigation
• https://simplyaccessible.com/article/react-a11y/
• SPA Accessibility - focus not reset when route changed remix-run/react-router#5210
• a11y issues: page nav doesn't trigger assistive tech gatsbyjs/gatsby#5581
• https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/

[NickColley]

I no longer work at GDS but will give my take and unsubscribe (😂) but at minimum you'd need to confirm your alternative routing meets the needs of real disabled people in user research to have proper confidence, generally speaking it's just not worth doing, it's better to invest time in maintaining a simpler server-first approach.
Sorts of things you'll see is that even if you do manage to announce page transitions in some assistive technologies you'll still be missing out on:

• status of load times (VoiceOver)
• overview of landmarks in the page (JAWs)

These are things you definitely would not want to try to replicate but you get for free by keeping things boring. The amount of engineering time to get this right is better spent making stronger server-first abstractions, unless you are solving evidenced and clear user needs that you can show you need client-first (not often the case).

[joelanman]

Unfortunately the Design System team don’t have extensive experience with React so I’m not sure we can help any further. In addition our team does not look after the Service Manual ourselves. But as you and Nick have said, any service needs to meet the standard, no matter what tech stack it uses, so it needs to be progressively enhanced and accessible to WCAG 2.1 AA

Some related guidance in case you haven’t seen it already:

• https://www.gov.uk/service-manual/technology/using-progressive-enhancement#building-more-complex-services
• https://www.gov.uk/service-manual/technology/accessibility-for-developers-an-introduction

You can submit feedback on these pages using the ‘Report a problem with this page’ links.

[penx]

It's important to note that this is not a React-specific issue, but an issue with client side routing in general.

i.e. using the History API and history.pushState

I think it is broadly thought that client side routing can be done in a way that adheres to the WCAG 2.1 AA guidelines (on paper) - but it's the real world user research that has been done on this that I am hoping to understand better.

I believe there has been research on this within GDS, where the announcing of route changes proved problematic, but only on certain devices.

I am not aware of the specific devices that exhibited these issues, so it would be great to surface this data, if anyone knows which team may have done this testing?

I agree with Nick's point that a server-first architecture would be the way to go, but that would still leave open the question of whether, with a server-first architecture, can I enable client side routing, in a way that passes WCAG 2.1 AA, and still meet the UK Government Service Standard.

I think the design system team may be best placed to enable this question being answered and documented somewhere.

@joelanman I will raise this question via the feedback links you provided above and post back here with any progress. I would have preferred to have this dialog in an open forum, are you aware of another GDS GitHub repository where this question may be more appropriate?

[penx]

@joelanman I will raise this question via the feedback links you provided above and post back here with any progress.

Correction - I have submitted feedback, but the form is one-way/anonymous so I won't get a reply

I also notice that the guidance was updated on 21 May 2019 (after we wrote the accessibility statement above) with the following

You can use server-side rendering, also known as isomorphic JavaScript or Universal JavaScript

As isomorphic/universal JavaScript applications are broadly understood to include client side routing, I think that should answer my original question (though clarification on this page would be good, especially as I understand there are a lot of caveats).

Also to reiterate Nick's point, I agree that following guidelines is not a substitute for real world testing, and real world testing should be done to have proper confidence.

[joelanman]

Just to clarify, it's the service team's responsibility to ensure their service is tested for accessibility etc, regardless of the technical approach.

[penx]

Just to clarify, it's the service team's responsibility to ensure their service is tested for accessibility etc, regardless of the technical approach.

Sure, I am just hoping that where there are known issues/pitfalls that are generic to all client side routing approaches, these can be highlighted somewhere so that developers can test for and resolve them in advance of user research/accessibility testing.

[joelanman]

ah cool, gotcha yes. In terms of an open forum, the Service Standard doesn't currently have one. I agree it'd be useful to keep this conversation and investigation open for contribution, so going to move this to the Design System Backlog and edit it to fit better there.

[jenbutongit]

Is there anything in WCAG2.1AA spec that makes SPAs inaccessible? Most of the accessibility concerns around js frameworks usually come down to bad a11y practice in general (like using the wrong landmarks/elements etc). Another pitfall is usually the app/site does not work without javascript enabled.

Svelte/SvelteKit handles client side routing well. The first page is always server side rendered, and only if js is enabled then SvelteKit will handle the routing from there.

[joelanman]

@jenbutongit Nick mentioned some common issues in his comment

[penx]

if you do manage to announce page transitions in some assistive technologies you'll still be missing out on:

• status of load times (VoiceOver)
• overview of landmarks in the page (JAWs)

My understanding is that these are outcomes from real world testing of client side routing that often relate to current implementations of specific assistive devices or software, and as such this could change over time (e.g. when there are software updates).

This is why I'm keen for any results and code samples to be published in a way that is retestable, so that people who are planning/supporting initial application architecture can be informed of what could be raised during accessibility testing.

These issues don't, as far as I know*, relate to specific WCAG 2.1 AA guidelines - so following the guidelines alone unfortunately can still result in issues for some users.

*

in general there aren't currently requirements for user problems related to client-side routing in WCAG
gatsbyjs/gatsby#5581 (comment)

[gtvj]

Given the need for (and benefits of) progressive enhancement, I'd have thought the work required to deliver a robust approach to client-side routine would not be a good use of effort.

[penx]

Here's a few reasons:

• There are already govuk web applications that use client side routing that are not considered a service and therefore don't need to meet the UK Government Service Standard. Perhaps, seeing the updated guidance, some services are using client side routing already too. It would be a good use of effort to give guidance to those that are using client side routing (or are considering it) on how to do it well.
• To give a benchmark when assessing 3rd party libraries such as Gatsby, NextJS, govuk-react, to inform both govuk developers/architects and the developers of those libraries.
• If there are critical issues that prevent client side routing from ever being an option, to publish these so that hard to reverse architectural choices are not made assuming client side routing is ok.

[gtvj]

Is it the case that the Service Standard is considered relevant only to those things which would be considered a service? I've always understood that the principles would be applicable to all front ends. Given the purpose of the Service Standard is to ensure quality (in all its various forms) it's not clear to me why we would diverge from it because something isn't considered a 'service'.

[jenbutongit]

It would be worth talking to the people looking after https://self-referral.test-for-coronavirus.service.gov.uk/antigen/essential-worker. It's using CSR (both render and routing it looks). This is definitely a service, however I don't know what sort of accessibility audits its gone through.

I'd have thought the work required to deliver a robust approach to client-side routine would not be a good use of effort.

I don't think so. A lot of web frameworks have SSR + CSR + hybrid renders built in nowadays. It just has to be "robust", and will behave almost exactly the same SSR or CSRd.

I think in general there are just too many frameworks for GDS to keep on top of but I agree that a benchmark would be useful, or at least a list of rules/guidelines to determine whether or not a js framework'd service would be likely to pass an assessment. Things like

• Is the framework able to server side render
• Are you able to easily turn on/off client side rendering (forcing SSR) in the case that the CSR'd page is not accessible
• Is the framework easy to learn and/or the service will be easily maintainable by other gov engineers which may not know the framework specifically
• Is the framework likely to "die"

[jenbutongit]

the service standard should apply to all services/transactions, but that doesn't apply to all front ends is what I understand.

[joelanman]

this seems relevant:

https://nextjs.org/blog/next-10-2#accessibility-improvements

vercel/next.js#20428

[CharlotteDowns]

I have transferred this issue to the govuk-frontend repository as it seems to relate to an improvement that could benefit all styles, components, patterns and isn't a stand alone style, component, pattern.

[NickColley]

While we know that boring templating works fine, if clunky, frameworks like React are still very popular.

For typical citizen facing simple forms on GOV.UK, GDS could consider exploring approaches like Next.js with React server side components to recommend:

https://nextjs.org/blog/next-12#react-server-components

This could allow the use of the framework without compromising the end-users experience for these common simple form interactions.