Router: Accessibility Issues and Ongoing Maintenance

[blainekasten]

Accessibility Issues and Ongoing Maintenance

I want to first thank you, Ryan and Michael, for consistently innovating in the router space. I love @reach/router and believe it has an important place in the router ecosystem. It is also clear that your focus is now on react-router v6, and this library and it's users are desperate for maintenance (52 issues, 14 PRs at this time). At Gatsby, we have a vested interest in seeing this library both maintained, and successful in tackling accessibility problems. Gatsby v2 has many users and is dependent on @reach/router. Additionally we have some unique accessibility issues with routing, Michael asked me to detail them in this Twitter thread. From my understanding, Marcy has spoken to Ryan about these in the past so he might have additional context with it.

Below are some in depth resources and related issues that highlight unique accessibility issues Gatsby faces with client side routing.

• User Testing Accessible Client Routing by @marcysutton - This resource is fantastic
• Gatsby issue where we misuse reach/router
• Feature request from Marcy

tl;dr

• Accessibility is complex, sometimes focusing a child h1 is more appropriate for readers. Exposing lower level primitives can help developers give our accessible-needing users the proper context to use an application.
• When using wildcard route matching, voice announcements are not consistently triggered for content change.

I'd also like to cc some important people who have worked closely to the issues here: @marcysutton @piedh @madalynrose

Maintenance

As mentioned, Gatsby has a vested interest in the success of this library and see it having an ongoing importance despite continued improvements to react-router. Competition is complementary, and as I see it right now, reach/router and react-router have slightly different goals. So I'd like to propose that this library receives ongoing maintenance and I/Gatsby are more than happy to step in. We have a proven track record of taking care of communities and OSS. A benefit for you all is that you can focus on react-router with a clear conscious that the users who decide to stay on reach/router will be taken care of.

[dericgw]

I would love to see this as well. I would also like to see some type of preloading mechanism to support Suspense (although there is a way to work around this right now, I believe, with some effort). With that said, I would be more than happy to contribute as well to make sure that Reach Router is continually being pushed forward.

[mjackson]

Thanks for reaching out here @blainekasten. We've been doing a lot of thinking over the past few months about that article you linked to by @marcysutton. Managing focus is something we've always wanted to have better support for, and feedback like that is critical for the work we're doing.

For now, it sounds like exporting the match function (per #263) could probably help with your use case, so I'd be happy to consider a PR that does that. But it really isn't ideal for us to be exporting internal methods like that because it increases our API surface area, which probably means that there's a problem with our original API. So if we do end up exporting match, I would probably consider it just a workaround until we can figure out what the right API actually is.

As for ongoing maintenance, one thing in particular that you said stood out to me:

as I see it right now, reach/router and react-router have slightly different goals

We don't see it this way at all. The goal is the same in both projects: to build a great routing library for React. In fact, one goal we have is to eventually rebuild reach/router on top of react-router v6.

reach/router was a "green field" experiment that Ryan did when he had some ideas about how to handle suspense and focus management better in the context of a router. Some ideas, like automatic path ranking and relative routing turned out to be solid and are going to make their way back into react-router. Some ideas, like the accessibility concerns you mentioned need further refinement. And some ideas in reach/router are not actually going to make it back into react-router. For example, eliminating <Route> components creates more work for people using TypeScript.

We'd love to have some more help on this repo, but it feels like we should probably make sure our goals and vision are aligned so we aren't wasting your time.

[dericgw]

@mjackson Question on one of your comments:

...eliminating <Route> components creates more work for people using TypeScript.

From my use with TS and Reach Router, making a component a route component was as easy as adding this:

interface SomeComponentProps extends RouteComponentProps {
  ...
}

// or...

type SomeComponentProps = RouteComponentProps & {
  ...
};

Are there other things that I am missing that make TS integration with a route component vs the <Route> component tough?

[mjackson]

Are there other things that I am missing that make TS integration with a route component vs the <Route> component tough?

Nope, that's it @dericgw. We've had a lot of feedback from TS users that this extra work for every route component in their app is unwanted.

[mjackson]

@dericgw I should probably add though that since the router will technically recognize any element with a path prop as a "route" that the current reach/router method of omitting the <Route> component entirely will still work in react-router v6. It's just not going to be documented. ;)

[blainekasten]

@mjackson Really appreciate the thorough response here! ❤️ I'll try to respond inline here.

Managing focus is something we've always wanted to have better support for, and feedback like that is critical for the work we're doing.

Very exciting to hear. It's a hard thing to solve. It's great to also see Dominic trying to solve this at the framework level in React. Might open up more possibilities for everyone.

For now, it sounds like exporting the match function (per #263) could probably help with your use case, so I'd be happy to consider a PR that does that. But it really isn't ideal for us to be exporting internal methods like that because it increases our API surface area, which probably means that there's a problem with our original API. So if we do end up exporting match, I would probably consider it just a workaround until we can figure out what the right API actually is.

I absolutely agree about not exposing internals and more than 100% agree about maintaining a useful API surface area. I think about that in everything I do, even when designing props for a component. I'm not sure if exposing that is a good move or not, but at least being able to experiment with lower level abstractions would be helpful.

As for ongoing maintenance, one thing in particular that you said stood out to me:

as I see it right now, reach/router and react-router have slightly different goals

We don't see it this way at all. The goal is the same in both projects: to build a great routing library for React. In fact, one goal we have is to eventually rebuild reach/router on top of react-router v6.

That's good to know! I'll fully admit that I haven't looked at react-router v6 yet and did not have the full context. I probably shouldn't have made that statement sound concrete when I had a limited perspective.

We'd love to have some more help on this repo, but it feels like we should probably make sure our goals and vision are aligned so we aren't wasting your time.

That sounds good. The way I see it, gatsby needs the library to survive (and many others). So at least seeing it maintained well is first priority. Messing around with accessibilities primitives on top of that might be a mutually beneficial second priority. At the end of the day, we all want to provide better out-of-the-box support for accessibility.

[mjackson]

Just added @blainekasten as a collaborator on this repo, so he'll be helping us identify stuff Gatsby needs in reach. I think we can go ahead and close this.