Making RedwoodJS Accessible

The roadmap currently has Accessibility in the “Figuring it out” category. Ben Myers is a wonderful, accessibility-focused developer who I’ve had the pleasure of getting to know over the last few months, and right now we’re talking about doing basically an accessibility audit of the documentation and the tutorial.

My goal with this is to try to get the overall ecosystem of Redwood starter projects to have better accessibility baked in from the start, including:

  • Semantic HTML
  • Screen reader considerations
  • Color contrast
  • Anything else that jumps out to Ben or others with experience in this area who would like to contribute

We’re also going to be doing a live stream talking about these different considerations on Jan 26 at 12pm CST. I’ll have a specific link as we get closer to the date.

I wanted to open this up to anyone else who has thoughts here because I know this is a very, very deep topic.

3 Likes

I’d much like to know – apart from accessibility topics in developing and providing a web application – what does it mean for an organization to be accessible?

What would RedwoodJS as a community to do to make its “products” accessible?

For example:

  • RedwoodJS main website - I imagine will fall into the more traditional UI aspects of accessibility
  • Meetups and Live Streams - Should these have live captioning? After, should all posted videos have captions (not just auto-generated ones). I have noticed that Learn with Jason has captions provided by sponsors: https://www.learnwithjason.dev/
  • Documentation and diagrams - If a figure is in docs, how might that need to be described in words?
  • Documentation writing style - Are there considerations needed when writing or organizing docs that RW should know?
  • Tweets and social media - I am seeing more and more cases where images and short videos need descriptions as well. I remember watching this last summer:

Then I think the other topic is, what can RW add to the framework to have opinionated and pragmatic Accessibility defaults – and encourage that developers to implement it.

  • What does that mean for forms and scaffolds?
  • Should the diagnostics checks warn if missing screen reader tags?

Looking forward to learning more about this topic that often gets lost.

For sure! @mojombo and I have had several, recent conversations on this and have attempted some (admittedly false) starts to get the ball rolling. Priority 1 --> is the Router.

Anything I could do to accelerate + help make a Router audit happen in the near term? I know how I’d like to setup/structure a project like this to make it actionable.

What I’m thinking of doing with Ben shouldn’t overlap too much with the router or really anything happening in the internals of the framework.

We’ll be looking at more of the meta-level of how to build accessible apps with Redwood and whether someone following along with the tutorial will have an accessible app at the end.

I don’t know if there’s anything Ben could do to help with the router but I’d be happy to ask him.

1 Like

Ah, roger that and understood.

Here is the Twitch link for Some Antics, we will be going live in 30 minutes!

Here’s the video for the first stream I did with Ben going over the docs, and then our recent stream with Dom showing the new router accessibility improvements for v0.28. :rocket:

Dom has been on a tear with his demo of new accessibility features at the recent Redwood meetup and an RFC for better skip links.

2 Likes

Hey, not sure where this is at but this is a topic that I am really invested in and been working with at work for months now.

Hey @aguscha333! @dom will be able to give a better summary of the current state of accessibility in RedwoodJS but I know that it’s something we’re always looking to improve. You can check out the docs here and see open issues related to accessibility here.

thanks, I’ll take a look

1 Like