Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

2024 Participants: Hannah Ackermans * Sara Alsherif * Leonardo Aranda * Brian Arechiga * Jonathan Armoza * Stephanie E. August * Martin Bartelmus * Patsy Baudoin * Liat Berdugo * David Berry * Jason Boyd * Kevin Brock * Evan Buswell * Claire Carroll * John Cayley * Slavica Ceperkovic * Edmond Chang * Sarah Ciston * Lyr Colin * Daniel Cox * Christina Cuneo * Orla Delaney * Pierre Depaz * Ranjodh Singh Dhaliwal * Koundinya Dhulipalla * Samuel DiBella * Craig Dietrich * Quinn Dombrowski * Kevin Driscoll * Lai-Tze Fan * Max Feinstein * Meredith Finkelstein * Leonardo Flores * Cyril Focht * Gwen Foo * Federica Frabetti * Jordan Freitas * Erika FülöP * Sam Goree * Gulsen Guler * Anthony Hay * SHAWNÉ MICHAELAIN HOLLOWAY * Brendan Howell * Minh Hua * Amira Jarmakani * Dennis Jerz * Joey Jones * Ted Kafala * Titaÿna Kauffmann-Will * Darius Kazemi * andrea kim * Joey King * Ryan Leach * cynthia li * Judy Malloy * Zachary Mann * Marian Mazzone * Chris McGuinness * Yasemin Melek * Pablo Miranda Carranza * Jarah Moesch * Matt Nish-Lapidus * Yoehan Oh * Steven Oscherwitz * Stefano Penge * Marta Pérez-Campos * Jan-Christian Petersen * gripp prime * Rita Raley * Nicholas Raphael * Arpita Rathod * Amit Ray * Thorsten Ries * Abby Rinaldi * Mark Sample * Valérie Schafer * Carly Schnitzler * Arthur Schwarz * Lyle Skains * Rory Solomon * Winnie Soon * Harlin/Hayley Steele * Marylyn Tan * Daniel Temkin * Murielle Sandra Tiako Djomatchoua * Anna Tito * Introna Tommie * Fereshteh Toosi * Paige Treebridge * Lee Tusman * Joris J.van Zundert * Annette Vee * Dan Verständig * Yohanna Waliya * Shu Wan * Peggy WEIL * Jacque Wernimont * Katherine Yang * Zach Whalen * Elea Zhong * TengChao Zhou
CCSWG 2024 is coordinated by Lyr Colin (USC), Andrea Kim (USC), Elea Zhong (USC), Zachary Mann (USC), Jeremy Douglass (UCSB), and Mark C. Marino (USC) . Sponsored by the Humanities and Critical Code Studies Lab (USC), and the Digital Arts and Humanities Commons (UCSB).

Week 3: p5.js and Access - Discussion Starter

Discussion leaders

Qianqian Ye (they/she), p5.js co-lead
evelyn masso (she/they), p5.js co-lead


Open source toolkits for the arts such as p5.js play a critical role in promoting software literacy and arts literacy; they are fixtures in educational spaces, having supported millions of students to get started in arts, open-source, and technology fields. Among these tools, p5.js is at the forefront of making concepts and tools accessible and available to people who are historically and systemically excluded from technology and the arts.

p5.js aims to model what it means to be a more accessibility-aware open source community. In 2019, we made the decision that “p5.js will not add any new features except those that increase access.” The p5.js community has made strides toward making learning how to code more inclusive, through the development of accessible creative-coding tools and learning resources, and a more accessibility-aware open source community. Our aim as a community is not only to promote and incorporate established best practices, but push the bounds of accessibility and creative practice.

The p5.js community published a statement about its focus on access in mid-2020 as a guiding document. Access can take many forms. It can mean providing accessible tools for creating accessible works on the web, investing in robust documentation offered in many languages, staying free of cost for non-commercial use, highlighting the work of marginalized people in the project, and more.

Access here means making p5.js better for:

  • People with disabilities or illness
  • People who speak languages other than English
  • Black people, Indigenous peoples, and People of Color
  • People who are lesbian, gay, bisexual, trans, or queer
  • People with marginalized genders
  • People who lack opportunities and/or resources to engage with creative coding due to class or income
  • People with little or no prior experience in open source and creative coding
  • and other people who are systemically excluded and historically underrepresented

Our group discusses access in Open-Source Software Toolkits for the Arts (OSSTA), like p5.js, Processing, openFrameworks, Cinder, three.js, and more. This discussion will provide space for contributors and users of p5.js and practitioners from outside OSSTA projects to share their knowledge, perspective, and dreams for building greater access to technical and arts spaces with the public.


We invite you to join us in exploring these and other issues in accessibility, with these questions in mind:

  • What are barriers you’ve experienced in using, working in, or contributing to open source software? What resources or strategies were helpful in navigating these barriers?
  • How can access in open source software for the arts/creative expression be radically expanded?
  • How can accessibility in open source software contribute to web accessibility in large?
  • What successful (or promising) practices have you seen used to increase access to open source software?
  • What can we learn from some of the good practices for increasing access outside of OSSTA projects?
  • At what social levels (e.g. individuals, projects, organizations, industry, etc) do you think change would be most transformative to these issues?


  • edited January 2022

    thank you @QianqianYe and Evelyn for this week's thread starter. I am indeed a fan of p5.js, using it for my own artistic works and teaching purposes. I like the values behind the community, pushing the boundary on accessibility, open source and creative practice. When we speak about access, it is more about social collectivity to involving [underrepresented and marginaised] people. What happens when we explicitly prioritise accessibility in software development? How would this change the field of software development? How would this cultivate a different way of doing programming? The works, including the software p5.js, web editor, and many other events, from p5.js community, are very important and highly impactful to our society.

    One of the more urgent issues, perhaps, is how could we extend this notion of accessibility into other software system, so that more voices can be heard in the tech industry and other organizations. This would potentially open up what might a contributor means to the software development cycle and processes, extending beyond art/design communities. I think p5.js has set up a really good case to unfold the challenges and to open up what might be possible. Currently, I am emphasising the aspects of community and contributors in my teaching (coding) course - especially the starting and ending in order to develop the sensitivity towards a more collective expression for world-building.

    One of the challenges I have (which has been also mentioned in OSSTA) is financial support for contributors (especially the starting one with a small collective/community) and open source projects often rely on volunteer labour. I don't have the best solution for this, just doing something similar to many others, such as identifying and applying funding grants, as well as speculating the possibilities of crowd-funding. But I feel there are more research and case studies that can be done to develop reports and knowledge (as to build a stronger base) to potentially influence policymaking and decisions in private and public organizations/sectors. On the other note, I think Mozilla is also a good case study in this regard, in terms of how they create fellowships that support projects concerning web accessibility, technology and civil society beyond art/design communities. Additionally, I think Lin Clark's code cartoons series ( act as a good resource too.

  • p5.js is definitely cool and I like to use it also for teaching because it is quite nice to teach through visuality ("pixels on screen ASAP") and interactivity.

    One super cool, important and inspiring project around p5.js is/was the p5.js Friendly Error System (FES), see also this writetup Friendly Error System for p5.js by Mira Chung.

    Accessibility in action, working directly with one of the hardest, anxiety-causing and also most misunderstood part of the real life in programming: error messages :)

  • In terms of barriers initially I didn’t contribute to open source projects because of my experiences with those developers who were very involved with those communities. Particularly, how they reacted to my non-masculine gender identity and my non-technical background. I found that in that community there was a hostility to those people who didn’t come from the same experiential background as the others in the community. For example, in my brief period attempting to use open source operating systems I would ask how does X or Y work and someone would say oh that is simple just use Z tool, but they failed to mention the 52steps to get tool Z to work and the fact that it is incompatible with these 32 other things. So, after spending days trying to sort it out and then going back saying these were the issues they would then put me down because of course everyone knows that it doesn’t work with these 32things. In the end I just didn’t have the mental or emotional energy to be constantly fighting. Now I tend not to contribute to open source projects because I am not sure of the etiquette or the processes, if it is a small thing I usually just fork and create my adjustments in that if I want to make the adjustments available to others. I have also made an effort to be overtly feminine in my username etc on things like git which has been shown to mean that my submits are less likely to be accepted even if they are fine. It is just another battle that I don’t need. There are some specifically niche open source projects that I am interested in so I may get up the energy to help with those but I am still hesitant.

    One of the things that I do when teaching programming is try to highlight the issues we have with assumed knowledge, often in first year first semester programming classes they assume a lot of prerequisite exposure to technical problem solving, command line/terminal literacy. In any of my instructions I tend to have things as major steps then under each major step is all the sub steps and any gotcha’s or possible errors. This allows those that are literate in this space to stick to the high level instructions while those who are less literate can follow the detailed ones. I also highlight mistakes just as much as successes rather than hide them it is important for people who are new to programming to see people making mistakes, if they think everything works first time they will think they are not good enough and give up.

    I think that p5.js does a great job at making the contribution process less daunting in its documentation, but I do think that people’s past experiences do mean that it might take a bit of work to get them to get past some of their, possibly, less than positive past experiences with open source communities.

  • I would second the comments from @annatito. I have never made a pull request to a project that I don't own! It feels too intimidating not knowing the unspoken etiquette for a particular project, or even sometimes the technical gotchas of github, and the things that changed that feeling for me were getting to know folks in the community personally. maybe this connects to what @siusoon offers here, that if we can expand the idea of contributor to pieces beyond code (as p5.js is doing), we can acknowledge those contributions more and also we can provide in-roads through community to creating new code contributors too (e.g. spaces where people feel more comfortable to ask questions.

  • edited February 2022

    Thank you so much for the recommendations, thoughts, and observations @siusoon @Mace.Ojala @annatito and @SarahCiston :) There is so much here to respond to, but I will answer one of the questions posed by @QianqianYe and Evelyn, "What are barriers you’ve experienced in using, working in, or contributing to open source software? What resources or strategies were helpful in navigating these barriers?"

    The barriers I've experienced are other peoples' assumptions about my experience in open source software. It has been a tremendous learning experience for me working for the Processing Foundation and making art in the past few years (with p5.js!). But people oftentimes assume I studied computer science, engineering, and/or I'm an advanced programmer. When they find out that my experience is in the art criticism (specifically new media and digital art), academia, and biotech, I get asked the question(s), "How and/or why do you work for Processing Foundation? How did you get there if you don't know how to code? I assumed you knew how to code!" :(

    For the record, and as an aside, I am a novice coder and constantly learning (always happy when I learn something new or my code runs smoothly). Circling back, I usually tell people (b/c I've been asked this many times) that I never believed I needed to be a coder/programmer/engineer to contribute to the open source software community and tech, broadly. I mean, one doesn't learn physics to ride a bike or drive a car. You just...learn, then practice, learn more, and repeat. Sure, it's helpful and wonderful to learn physics (although I was quite bad at it, surprisingly good at learning circuitry and electronics, but that's such a tangent :D), but there are so many different ways to be a part of work that speaks to you and to break barriers.

    In terms of navigating the barriers, I revisit Dan's tutorials from the Coding Train or watch xin xin's tutorial videos. I also create "recipes" for myself (read: creative prompts) that allow me to explore code as a new medium for writing poetry and experimental prose. At the end of the day, breaking those barriers is breaking those barriers within my own practice and what has stopped me from making due to shame or guilt for not having a specific type of knowledge. There is so so much and community members that have posted thus far have shared some incredible resources. I'll stop for now, but looking forward to continuing this dialogue.

    Thanks again, Q and evelyn, for this conversation. <3

  • My experience teaching p5.js and Processing with students at CIID, an international post-graduate design school, might be interesting for this discussion.

    Most of the students have never done any programming before, including website building foundations (html, css, et al). So before I dive into teaching p5.js I start with a tutorial on the basics of thinking through websites. How to structure a document, how to add basic styles, how to open and view a html file locally (both directly and via simple local servers). This is definitely a barrier to entry for getting into p5.js as a first programming experience, but not a big one.

    Students pick up the overall structure and approach in Processing-like frameworks pretty quickly. The setup->draw concept seems to make sense to them.

    In the international, but still english based, context of a school like CIID language quickly becomes the biggest barrier. To enrol in the program the student has to be English fluent, it is the main language of instruction and the only common language among the students. However, many of them come into the program without the technical English assumed by most programming languages, including html/css let alone Javascript or the libraries built on top of it. When we get into things like logic flows, mathematics terminology, etc the english-centric-ness of it all presents a real issue. We have always overcome it with some translation, searching around, or digging into the concept with different language.

    This is a problem that goes all the way down in programming languages, not specifically about p5 or similar... but it might be something that can be eased through helper function, documentation aimed at people who don't come from english-speaking places... or something??

    It's never been such a high barrier in this context that we can't get through it, but these are post-secondary educated and english speaking people in general in order to even get into the school... for people in different situations it might be an even bigger barrier.

    I'm sure you all know this already, but thought my experience might add something to the discourse here.

  • @drsantos I am so struck by your comment:

    I also create "recipes" for myself (read: creative prompts) that allow me to explore code as a new medium for writing poetry and experimental prose. At the end of the day, breaking those barriers is breaking those barriers within my own practice and what has stopped me from making due to shame or guilt for not having a specific type of knowledge. There is so so much and community members that have posted thus far have shared some incredible resources. I'll stop for now, but looking forward to continuing this dialogue.

    I think we do not talk enough about the culture of shame and chauvinism that is serves to puff up some members of the programming communities at the expense of others. Academia can be no better, of course, which is why forum moderators are so important or those who do the hard necessary work of building safe spaces -- and here I'm thinking of @SarahCiston at USC who has built such a nurturing creative Code Collective. I want to hear more about the "recipes," which I like because it draws upon a communal practice of sharing. Would you be willing to share any?

Sign In or Register to comment.