p5.js Documentation Accessibility

Enhanced The Processing Foundation's p5.js documentation and contributed to its open-source environment.

A was a Contributor for the Processing Foundation through Google's Summer of Code program. This program lasted through the 2023 summer.

Google Summer of Code Overview

Google Summer of Code (GSoC) is an online program that provides students and entry-level coders the opportunity to contribute to an open-source software development with the assistance of mentors, advisors, and other open-source experts.

Over the 2023 summer, I assisted the Processing Foundation (@ProcessingOrg) with the navigational and visual accessibility of their p5.js documentation site. I also contributed a new learn guide for their ARIA labeling functions to assist with screen reader accessibility.

The work I completed during this GSoC program has resulted in intrigue for further research into the accessibility of the p5.js documentation site, as well as expanded knowledge and awareness of larger accessibility pursuits to endure in the future. I will continue working with the p5.js team when these research and testing pursuits are funded and approved.

GSoC Goals

During this program, I wanted to expand upon my front-end development skills and refine my git versioning workflow, while also strengthening my knowledge on web accessibility and screen reader technology. Previously, I’ve participated in accessibility projects as a designer, not a developer. I wanted to use this GSoC opportunity to try my hand at discovering the accessibility issues and solving them with my own skills and code.

Submitted Documentation and Code

During this GSoC program, I have submitted the following PRs:

p5.js and the Importance of its Accessibility

p5.js, an open-source JavaScript library managed by the Processing Foundation, has been adapted and utilized by many artists and educators worldwide due to its extraordinary visual and creative capabilities. Because this library has such a powerful and universal audience, it’s all the more important to ensure that its structure, access, and information architecture is easily accessed and interpreted by its users, regardless of their language, ability, or technology.

Stated by the United States’ Americans with Disabilities Act, ”[inaccessible] web content means that people with disabilities are denied equal access to information.” And, in this current era where most of our everyday tasks reside online, inaccessible web content is a very pressing form of discrimination. Inaccessible web practices take many forms, such as poor color contrast, missing alt text on photos, poor information hierarchy, missing video captions, and mouse-only interactions (just to name a few). Such web practices make the web hard to use not only for people with disabilities, but for everyone-- proper web accessibility benefits everyone, regardless of their disability status, for accessibility principles (such as the ones listed by the W3C) are founded on proper and “perfected,” for lack of better terms, content, design, and development practices.

Because p5 is used by a diverse global audience, it’s crucial to make the site and editor as accommodating as possible-- which is a daunting task in itself, but still highly productive, regardless of its difficulty. This project’s scope and timeline was not large enough to make p5 “perfect,” but I scheduled enough time to focus on some of the larger issues with the site and editor, especially the issues regarding keyboard accessibility.

Before this years’ GSoC program began, the Processing Foundation shared a list of project ideas for potential GSoC contributors, one of which was improving the navigational accessibility of the p5.js documentation site. Many people on the p5 team have been wanting to do an in-depth accessibility audit for a while, and I took their suggestion as a chance to assist this globally-loved nonprofit with my specialty in accessibility and UX design. After my proposal was approved and I was selected as one of the few Contributors for this year’s Google Summer of Code program, I began working with the p5.js team to conduct an accessibility audit on their documentation site.

Auditing the p5.js documentation site

During the first weeks of my GSoC project, I audited the existing p5.js documentation site and took note of any features or UI components that did not comply with WCAG AA and COGA standards. As requested by the Processing Foundation team, I took extra care to audit the keyboard and screen reader accessibility of the site. Here is an abridged list of the high-priority issues I found:

Inaccessible brand colors

The pink brand color (#ED225D) does not have enough contrast on the site’s white background (WCAG 1.4.3). The light gray applied to buttons and the search input is also inaccessible.

Inconsistent UI styling

Across the site, there are at least two different secondary button designs-- one of which has insufficient contrast against its background. When I first saw the buttons on the Reference page, I thought they were disabled with how invisible they were against the background.

Providing a consistent button design to use across the site will help with brand cohesion, predictability, and overall improved navigation. This may involve modifying, improving, or publicizing a design system for all contributors to easily access.

Keyboard navigation traps

When navigating the Reference page examples via keyboard or screen reader, the code blocks, if you edit the code, results in a keyboard trap where the user can’t exit the text box.

Annotated screenshot of p5.js page showing the tabbing sequence of the Reference section. — Tabbing sequence of a p5.js Reference page

Using the Accessibility Insights for Web plugin, I discovered that once someone "tabs" into a code block, they cannot escape (the 'tab' key is re-targeted to a different purpose in the textbox).

Keyboard navigation reorienting traps

If you select the “Skip to Main Content” button on the Reference example pages, this button redirects a user viewing a function’s Reference page back to the overarching Reference index. My theory is because all of the Reference content exists on the same HTML file, and because the display styling of the item-wrapper apidocs div is changed when the user selects a specific function’s reference, the “Skip to main content page” somehow refreshes any JS-related styling changes and redirects the user back to the Reference index. The same issue with the “lost” tabbing sequence exists on this page as well.

Annotated screenshot of p5.js Reference page

Contributing to the p5.js documentation site

After presenting my audit to the p5.js lead team, we created a list of issues that would be fixable within my GSoC project’s scope (you may view that issue list at #1372 p5.js Accessibility Audit Discussion). Below is a list of all the issues I assisted in fixing:

Please note: Some of these PRs may still require merging or changing that extends the GSoC timeline. This list of PRs is, again, subject to change and revision as I continue my work with the p5.js team.

Expanding the community’s knowledge of web accessibility

The describe() and describeElement() functions provide screen-reader accessible text that explain the p5 canvas and elements inside the p5 canvas. Since this is a fairly recent addition to the p5 library, no existing documentation (outside their References pages) about proper use of these functions is available. This has been brought up in multiple issues in the GitHub Issues page and is currently a part of the Web accessibility next steps page.

After completing the accessibility audit and submitting my code revisions, I then pivoted my attention to writing a tutorial that would help the p5.js community make their written code more accessible and accommodating for screen readers and other assistive technology.

The overall objectives of this tutorial were to:

Make people aware of these new features
Let people know how to use them
Indicate the best practices for ARIA labeling, from very simple to very complex and dynamic canvases. (There could also be a section about proper alternative text for highly-interactive and highly-animated sketches and how to best use describeElement() to explain the sketch’s changes.)

At this moment, this tutorial is still going through the process of approval, from both the p5.js lead team and Processing Foundation community. More on this tutorial to come after its approval. You may view the current status of the tutorial at #1412 How to label your p5 canvas tutorial.

Next steps

Even though the GSoC program has concluded, I will continue my work on improving the accessibility and inclusivity of p5.js. That’s the beauty of open-source, and the goal of the GSoC program itself-- to inspire students and entry-level coders to remain immersed in open-source projects, and to remain active in communities that can both benefit and expand on your development skill set.

In the future, I will help the p5.js team conduct more usability testing (specifically usability testing with screen readers) and resolve any accessibility issues within my ability.

Thank you to the whole Processing Foundation team for this wonderful opportunity, and thank you to Claire Kearney-Volpe, Paula Isabel Signo, and Caleb Foss for the great mentoring!