Mockup derived from image by rawpixel.com on Freepik
Jupyter Accessibility Workshops
The Jupyter Accessibility Workshops were a series of public virtual events aimed at increasing accessibility awareness within the Project Jupyter ecosystem and making Jupyter projects more usable for disabled people. Lead primarily by myself, Tony Fast, and Tania Allard, we built upon existing accessibility efforts across the many Jupyter projects. For these events we emphasized on discussions around the Web Content Accessibility Guidelines and how to apply them in open source, scientific spaces where this work has historically been neglected.
With a small team and big dreams, we took the time to create reusable systems for the workshop structure, content, visuals, and communication.
Skills: Visual design, Experience design, Slide design, Writing, Public speaking
Results
All in all, these workshops supported
• 3 recorded talks, including expert accessibility talks from Frank Elavsky and Eric Bailey
• First-time contributors to Jupyter projects
• 88 image descriptions written (contributed between Juptyer documentation and Jupyter.org)
• A Jupyter-centered image description style guide.
• Blog posts
• Social media posts
• Email campaigns
• Feedback forms
• Social media posts
• Email campaigns
• Feedback forms
Motivation
At the core, we focused on creating inclusive event experiences for and international and mixed-skill audience. We connected accessibility experts and Jupyter experts, increased accessibility awareness in the Jupyter community, practiced accessibility techniques, fixed issues within Jupyter projects, and created resources for asynchronous use.
Accessibility efforts in the Jupyter ecosystem have been ongoing, but they are frequently on the sidelines. With the opportunity of Jupyter Community Workshops at hand, our team took the time to compare how accessibility work was currently distributed with how we wished the community was engaging. The difference between these two became the events’ cornerstones.
Strategy
Many aspects of the workshops came from the open source spaces from which they spawned. These events were financially free, planned and shared in public, and created something which could be enjoyed whether engaged with in real-time or asynchronously. Additionally, we wanted to make lasting resources and documentation to help people engage long term.
To create a set of workshops that responded to community requests, the resources of a small team, and centered on actively improving the ecosystem and software for disabled people, we designed the workshops around multiple strategies. They are
• Balance learning and action.
• Give the spotlight to different people with different knowledge.
• Make something and contribute it to the community as a group.
• Build new connections within Jupyter and outside it.
• Balance learning and action.
• Give the spotlight to different people with different knowledge.
• Make something and contribute it to the community as a group.
• Build new connections within Jupyter and outside it.
Structure and Content
Jupyter accessibility workshops were structured around a two event cycle: the first event is informative and led by a non-Jupyter expert, the second event is for practicing these new learnings on real problems in the Juptyter ecosystem and contributing the practices as fixes to the software.
Events in a cycle were one week apart, while a repeated cycle had a month between its installments. Alternating between learning and action was key in responding to a community catch-22 while ensuring that we committed to leaving our space and software better than we found it.
Events covered topics like accessible data experiences, writing image descriptions, inclusive design, and a review toolkit for digital accessibility. Before the event, these topics prompted new resources like an image description/alt text guide and checklist for review. These resources have since been used in projects outside the workshops and outside Jupyter.
During the events, participants collaboratively created resources like group notes, list of links/resources shared, and recordings of the event. This helped create new public documentation for these accessibility practices on top of encouraging community engagement.
Visuals
Combining the existing Jupyter brand with a unique and instantly recognizable set of visuals specific to the events, the Jupyter accessibility workshop visual design system is simple and modular. The visuals for this event were used throughout, from social media, blog posts, slide decks, video thumbnails, virtual hosting platform banners, and more.
Color: use a bright palette rooted in the Jupyter brand. Extending the color palette also gave us many more options to combine colors and achieve accessible amounts of contrast, an issue the Jupyter brand struggles with.
Type: use san serifs. With a range of contributors on a range of platforms, determining a single typeface wasn’t helpful to our team. For stylistic reasons, we also used lower case characters with exceptions for proper nouns.
Illustration: Geometric shapes, flat colors, and imagery that relates to topic for that specific event. Use outlines and shadows to ensure strong contrast and legibility.
Application: wherever visuals are needed for the event, these basic principles need to be followed. Aspects can be rearranged and reconfigured as needed for different formats and situations. All visuals require image descriptions that summarize text within the image and the imagery used. Do not use the Project Jupyter logo or any trademarked brand elements.
Methods
• Extending Jupyter brand and creating unique visuals for the event from promotion to wrap up.
• Documentation of event design, templates, and resources.
• Regular community feedback on current accessibility efforts, what they wanted to learn, and on events themselves.
• Slide content and visual design.
• Collaborative event hosting with guests, speaking hosts, off-the-mic moderators,
• Writing. From promotional materials, to event-running templates, to the talks and activities in every event, this process heavily leaned on writing for asynchronous collaboration in an asynchronous community.
• Documentation of event design, templates, and resources.
• Regular community feedback on current accessibility efforts, what they wanted to learn, and on events themselves.
• Slide content and visual design.
• Collaborative event hosting with guests, speaking hosts, off-the-mic moderators,
• Writing. From promotional materials, to event-running templates, to the talks and activities in every event, this process heavily leaned on writing for asynchronous collaboration in an asynchronous community.
Additional Slides
