Accessible Knitting

 To say, "I like to knit" may be an understatement.

Recently, a primary online knitting community site (Ravelry.com) that I've been an active member of for years released a brand refresh that updated the visual design of their site, as well as some functionality.

While they posted about the design choices were intended to be gender neutral, start fresh, and bring a more fun and colorful tone to their site; what it actually did was trigger users with photo-sensitivity to have seizures. Additionally, it caused others to experience severe eye strain and trigger migraines.

This has caused serious ripples through online knitting communities, and brought accessibility to the forefront of those discussions.

Outside of the complete PR nightmare for Ravelry because of how they're handling it, an explosion of users came forward to advocate for accessibility whose voices may not have been heard as loudly otherwise.

This topic now combines my two biggest passions. Knitting and accessibility.

As a case study, it's a perfect example for the color contrast ratio not being the rule for design, but more of a guideline. You can choose horribly clashing colors that hurt your eyes to look at, but have them still meet the contrast ratio. In a response to the backlash from its users, Ravelry mentioned specifically that the new colors met contrast ratio requirements, and therefore they felt it was accessible. 

Example from UXMovement.com

The colors they chose were intense cyan and harsh black "drop shadow" on buttons that looked more like a duplicated box behind the button but far enough away to create a very intense layering effect. They said they chose this as a way to distinguish themselves from their old style, and stand out.

Black and white screen shot from ravelry showing the intense button style
Button style shown in black and white to avoid issues for photo-sensitive readers


What they really did was choose colors that caused eye strain, and a button style that disoriented the user because of the layering effect the black "drop shadow" effect made. The style applied to the buttons were also so drastically different from a standard button styling, in my opinion, it made it harder to scan the page and recognize what elements were what on the page.

They also applied this "drop shadow" effect to any floating container, so it was very hard to focus on the content of the page as you were distracted by the "heavy" feel that was applied to floating objects around the main content of the page.

Around the same time this was all happening, I had written a pattern for a knit sweater (Stand Together Sweater) and published it. I included a "low-vision" accessible tag in the pattern page because I believed I met contrast requirements for the PDF, and included alt text on images.

I was contacted by a member of an accessible patterns community on Ravelry, and they helped me update the pattern to include the specific requirements for making the pattern meet their low-vision criteria. This was eye-opening because of how knitters need to incorporate and interpret web accessibility standards as well as specific criteria in order to be able to knit from a published electronic pattern.

Screen shot of the first page of the Stand Together sweater pattern featuring the low-vision title

Things needed for publishing low-vision accessible patterns:

  • Font size needs to be a minimum of 22- 24 point
  • Black text throughout the pattern
  • Sans-serif font
  • No italics
  • All directions in written form
  • If it includes a chart, it needs to also include a written out version of the chart
These things are all in addition to being screen reader friendly, etc. With their help I created a low-vision version of the pattern and made sure to use headings as well in the appropriate way to call out all the sections. It made the low-vision PDF about 10 times longer, but would be useful for anyone who either used a screen reader to knit, or printed out patterns that needed it more legible.

I plan to explore and research additional ways to ensure accessible patterns are created, and plan to create low-vision versions of any future pattern I may publish.

If anything good came out of the pain caused to it's users from the Ravelry re-brand, it would have to be that it's now a common topic of conversation to ask "is it accessible?" and people are getting on board with making sure experiences are inclusive for all. 

Popular posts from this blog

Practice Site: Keyboard Accessible Tooltip Fail

Image
While reading about keyboard input methods and learning about the success criteria requiring custom keyboard instructions for any custom key commands, one method of accomplishing this was using a tool tip to present the instructions. It mentioned that the tooltip would have to be accessible via keyboard navigation and be able to be read by a screen reader. That reminded me that on my practice site, I spent a significant amount of time creating an example of success criteria for 3.1.3 to provide a definition of an unusual word when the user hovers over the text "affordance" displaying in a tooltip. I did not, however, make this accessible to keyboard-only users or screen readers. Turns out it wasn't even focusable until I gave it a tab index. More investigation into ARIA Practices for 3.24 Tooltip Widget call out specifically that the tooltip container requires role="tooltip" (which I did not have), and the element triggering the tooltip references the tooltip ...
Read more

Pointer Cancellation: Real-World Examples

Image
 While reading through the Operable Principles, I admit that I was confused about the success criteria around pointer cancellation . The success criteria states, For functionality that can be operated using a single pointer, at least one of the following is true: No Down-Event: The down-event of the pointer is not used to execute any part of the function Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion Up Reversal: The up-event reverses any outcome of the preceding down-event Essential: Completing the function on the down-event is essential Some of my initial questions when reading this are: It mentions functionality using a single pointer, but what are the other options? Is there a double pointer? Do they mean that when they release the down-click the user is prompted to abort the action or undo?  Are they holding down a mouse button reading something tha...
Read more

Practice Site: Accessible Forms

Image
Today I finally bit the bullet and focused on creating a page on the practice site that would allow me to practice with form components, and live events based on actions. I have the basics down thanks to a friend of mine who walked me through the tools and resources that would be best for this very specific scenario and wrote the skeleton of the page that I could edit to make more accessible. She recommended using JQuery and JavaScript to avoid requiring a database or AJAX. Thanks to w3school.com for their amazing resources. My goal is to make the form fields clear on each submit, and post the data in a styled way on the page. I'd also like to make each submit speak a "success" message to alert the user of the new content, and of course, add labels to everything. Since this took the entire day, it will have to do for now. Luckily there are built-in focus states for the input and button elements by default. This was a productive day, but I may need to take a walk after ...
Read more