Ravelry: Accessibility Settings
If you’re even slightly into fiber arts (knitting, crochet, etc.), I bet you’ve heard of Ravelry. It’s a one-stop shop for browsing and buying patterns, reading yarn reviews, and connecting with other craft enthusiasts.
It’s also HUGE. Like, 9 millions users huge. So I guess it shouldn’t be surprising that there was a lot of backlash when they rolled out a massive redesign in 2020. After all, no one likes it when a website they use almost daily is suddenly different.
But there’s a big difference between “people don’t like this because it’s different” and “this site caused 10 people to have seizures and countless others to have migraines and severe eye strain.”
At the time, I didn’t know anything about design or web accessibility. But now that I’m a UX designer, I’m fascinated. What went wrong? How did a website for finding craft patterns cause seizures? Did the issues ever get fixed?
What went wrong?
It’s kind of tough to figure out the specifics, partly because this all happened a few years ago and partly because a lot of discussion about the redesign was shut down. I tried to find as many blog posts, Twitter threads, and Reddit discussions as I could, and here’s what seem to be the main culprits:
In the original redesign, all the background elements were animated. Talk about overwhelming!
Where things stand now
As of February 2023, there are some accessibility settings you can adjust once you’re logged into an account on the site. The diagram below shows the screens you need to navigate through to change these settings. Note: you have to be logged into the site!
Inescapable, full-screen animations
No screen reader compatibility
Harsh color choices
Poor visual hierarchy
From what I can tell, most of the big animations (like on the login screen) have been removed, so that’s good! But there’s one really big problem:
To change your accessibility settings, you first have to navigate through an inaccessible site.
This is bad in several ways:
Massively impractical: If you can’t use the site, how are you supposed to get to the screen to change these settings?!
Puts the onus on the user: many people who were affected by the redesign had never experienced issues like this before and so didn’t know how to tell what was causing problems. This solution means that each individual user has to figure out what to change to solve their problem, and the site provides no guidance or information for how to do so!
Treats accessibility as an afterthought: I feel like it should go without saying that a design should be accessible by default, instead of treating disabled people like they’re an inconvenient anomaly
Definition: what can I learn from this?
My goals with this side project are to learn more about accessible design past the basics of WCAG Color Contrast that my bootcamp covered and put some of what I learn into practice. I’m a big believer that constraints lead to creativity and learning, so here are my assumed limitations:
Overall design has to stay the same
The accessibility settings themselves have to stay the same
Problem
Ravelry’s current accessibility settings aren’t useful because they require users to navigate through an inaccessible site and have a detailed understanding of what features may cause problems.
Goal
Make Ravelry’s accessibility settings easier to find, use, and understand.
Discovery: what are the problems?
Development: how can I address this?
Accessible by default
First things first: the default version of the site cannot include elements that may lead to seizures. That’s just too high a risk. I’m assuming that the default settings are animations and gifs turned off and Herdwick mode (the lower saturation color palette).
Ideating with crazy eights
Some of the ideas I explored were:
Tying accessibility settings into the log in flow
Having a modal appear where users can select accessibility settings
A dropdown select in the main navigation
Floating action button to change settings
When evaluating these ideas, I needed to keep in mind how different use cases would work (e.g. a new user vs someone who uses the site all the time vs someone who enters the site not from the homepage, etc.)
Choosing the right button placement
Someone might not know that they need to change a setting until they encounter a part of the site that isn’t working for them, like an animation. It’s really disruptive to them have to go to your profile and then settings and then back to wherever you were.
Users should be able to adjust their settings from anywhere without needing to go to a different page. It makes sense for the button to be in the main navigation so that it’s available (and in the same place!) on every page.
The navigation is currently split into two parts:
On the left: actions related to finding content
On the right: menus and actions related to settings and community
I tried to balance visual hierarchy, consistency, and being able to get there quickly using keyboard navigation.
Why a modal?
Modals can be super disruptive if they’re used too frequently or in the wrong context. But here, I think a modal make sense. It filters out all the background information and allows the user to just focus on the task at hand: selecting their accessibility settings. Any parts of the site that are causing issues will quickly be obscured with the overlay.
A big problem with the current settings is that they don’t give any explanation. Someone might not know that it’s the animations that are causing problems for them. Using an accordion gives the option to read more info but it doesn’t overwhelm users with information they don’t need. This can be particularly beneficial for users who are neurodiverse and may be negatively affected by too much information!
Delivery: does this solution work?
Seeing as this project was more of a learning-opportunity-turned-design-challenge, I wasn’t able to test my design with actual users. If I could, these are the things I’d want to test first:
Placement of accessibility settings button
Validating assumptions about users’ mental models (do they think of this more as display settings, accessibility, something else?)
Accordion vs plain text
Explanation of settings and their use cases
And it goes without saying that I’d want to test this feature with people who use screen readers, keyboard navigation, and other assistive technologies!
Next Steps
Implementation
Obviously I wasn’t working with any engineers on implementing this, but here are some of the things I’d keep in mind if I were:
Properly managing keyboard focus: making sure that the keyboard focus switches from the main page to the modal and ensuring that navigation within the modal works properly
Accordion accessibility: make sure that people using screen readers or keyboard navigation can easily use the accordions
Next steps
I purposefully kept the scope of this design challenge pretty narrow. Here are some of the next steps I’d take if I were actually working on this:
Ensuring full responsiveness across devices
Voice navigation
Customizable accessibility profiles - saving a combination of accessibility settings in a profile that users can easily toggle between
Incorporating accessibility settings into new user onboarding
Exploring if the placement of the accessibility settings buttons should change when the site is displayed in languages that don’t read from left to right
Next up: dark mode?
Some of the blog posts I read while looking into the controversy around the redesign mentioned that Ravelry’s dark mode doesn’t align with best practices. I don’t have much experience designing in dark mode, so maybe I’ll tackle this in my next design challenge!
What Did I Learn?
Reflections
This design challenge was a great way to learn about different aspects of accessibility that my bootcamp didn’t cover. It was helpful to have so many limitations because I could really narrow in on one area, but in the future I’d like to take a shot at a full redesign of the site.
Some of my main takeaways were:
Animations can cause serious issues when you don’t take accessibility into account
Easy keyboard navigation relies on both designers and engineers
This was my first time working on a project within such a short timeframe and not being able to do user research and testing. And it didn’t help that the redesign in question happened several years ago! I had to get creative about finding places where users were talking about their experiences, like Reddit and Twitter threads. Even though this obviously isn’t ideal, I can see how it could be useful either alongside user interviews or when recruiting users just isn’t possible.
I don’t think this is a perfect solution by any means, and I still have a ton left to learn about accessible design. But I definitely know more than when I started!
Sources