Effortless Accessibility: @reach/router and beyond

Recently, I had the opportunity and privilege of giving a talk at the ReactJS meetup in Chicago.

While I spoke about the accessibility features that come baked into the @reach/router client-side routing package, my talk was also about accessibility in general, which I was grateful for because it looks like the founders of react-router and @reach/router are working this summer of a new release of react-router that will essentially merge the two libraries together - which is awesome and a great direction for the community to be headed.

Accessibility does not need to be paramount only when we we are personally impacted by an impairment or someone close who is impacted directly. It should be of paramount concern all of the time.

As for the talk, I used a controlling metaphor throughout the talk to emphasize how accessibility concerns are only top-of-mind to us when we are, in fact, impaired in some way or the organization where we work has dedicated themselves internally to adhering to accessibility standards (e.g. as a matter of mitigating risk from lawsuits). Either way, we typically think about accessibility features after the fact.

To demonstrate this, I used the availability and design of a water fountain. We don't really care about or put much thought at all into water fountains, where they are, etc. until we are thirsty.

Once we are thirsty, we search the world around us for potential signs of a water fountain. The link between thirst, a need, and an impairment that might require the need for a screen reader or keyboard controls in a web app, is so compelling to me because, as far as a water fountain goes - it was put there for everyone to use. Many people in many situations thought about us and our needs without ever knowing who we are.

Let's look at a water fountain placed along Chicago's lakeshore trail as a demonstrative example.

An industrial designer designed it.

A manufacturer produced it.

A salesperson sold it and a buyer bought it.

An urban planner planned for it.

A politician allocated funds for it.

City workers installed it.

Plumbers integrated it with the city's plumbing system.

All of it - all of it was done for us. That's amazing.

The same goes for an access ramp to a school, or theater, or doctor's office.

We, as engineers of web experiences, create destinations. Those destinations need to be just as accessible.

Doing so is not just about thinking about and engineering for folks who are marginalized. It means engineering those destinations for able-bodied and impaired folks at the same time because we actually make the experience better and more accessible for all users.

How many times have you used a wheelchair ramp instead of the stairs?

How many times have you hit the wheelchair button - ♿ - on the automated door at the airport to open the doors as you fumble for your luggage?

It means engineering those destinations for able-bodied and impaired folks at the same time because we actually make the experience better and more accessible for all users.

These alternate means of using and interacting with our world - including the web - make it a better place for everyone. 📈

Feel free to peruse slides from my talk below.