When Scaling Isn’t Enough: Toward Durable Accessibility
A reflection on my time researching/teaching/doing accessibility for large computing courses
This idea jokingly came up as a “post-mortem” for “Systems for Scaling Accessibility in Large Computing Courses” — a SIGCSE experience report I co-wrote with the amazing Miya Natsuhara and Matt Wang. In the experience report, we discuss how we developed four systems to scale accessibility efforts in a large introductory programming course sequence, with over 3500 enrolled students and 100 teaching assistants (TAs) per year.
If you want to learn more about those systems and what we did, you can read the paper. This post is more about the aftermath, and how these systems fared.
But it’s also about my reflection on our accessibility efforts as a teaching assistant/research scientist at the University of Washington (UW) — and how I feel a year later, with this work persisting (in one way or another.)
This post is extremely inspired by a talk I gave at the AccessComputing SIGCSE TS 2026 Affiliated Event. In fact, at least 80% of it is from that presentation!
In this post, I hope to reflect on a few things:
- Accessibility as an ecosystem of labor in large computing courses
- The fragility that emerges when scaling systems for accessibility efforts
- Reflections and tensions as a student practitioner
- Durable accessibility as a vision for accessible computing education infrastructure
I find that caring about accessibility, especially in education, requires both honesty and humility in knowing what breaks; but moreso, learning to know what one can do to “unbreak” it.
Ecosystems of labor
CSE 12X is the UW’s introductory programming sequence, made up of three courses: CSE 121 (for students with no programming experience), CSE 122 (for students with some programming experience), and CSE 123 (for students with substantial programming experience.) For those on the semester system, think of CSE 121 + 122 = CS1, and CSE 122 + 123 = CS2.
As mentioned, we have 3500+ enrolled UW students taking these courses yearly, and employ 100+ undergrad TAs to help manage the large course sizes. We can represent the students, TAs, as well as the instructor, as existing within an ecosystem of labor:
Each of these actors: Instructors, TAs, and Students, all perform some amount of labor in a course. Instructors exert labor in leading the course, giving lectures, and course minutiae. TAs exert labor in teaching recitation section, hosting office hours, and grading (much to their dismay.) And students exert labor in attending lecture and recitation section, doing assignments and projects, and just being students of the course!
So while this is the ecosystem of labor in a large computing course, when we think about accessibility, it’s naive to think they remain the only actors.
Accessibility in large computing courses reveals a larger ecosystem of labor:
Among the original actors, their labors have expanded; it takes both time and labor for students to advocate for their disabilities. It takes further labor from the course staff to learn about accessibility, create accessible materials, and teach accessibly.
But we also expand the actors in the labor ecosystem: Institutional Staff, comprised of administration and institution-level offices; Experts, both on- and off-campus who can provide expertise and guidance; and Student Supports, which I define as student-facing groups focused on support and advocacy, such as Disability Services Offices (which also fall under Institutional Staff, in a non-student-facing capacity) and Assistive Technology Centers.
Interactions of accessibility labor
It’s worth discussing the interactions of this ecosystem, as actors of ecosystems are often in multiple, chained interactions across other actors.
Some of these interactions include:
- Accommodation Coordination (Instructors ↔ Student Supports ↔ Students)
- Infrastructure & Policy Guidance (Institutional Staff ↔ Experts ↔ Student Supports ↔ Instructors)
- Knowledge Transfer & Training (Experts ↔ TAs ↔ Instructors)
- Curricular Integration & Iteration (Instructors ↔ TAs ↔ Students)
- Everyday Accessibility Practices (TAs ↔ Students)
Accessibility lives in these interactions. But scaling cannot rely on these interactions alone.
The dimensions of infrastructure
Scaling systems is not the same as building infrastructure. Susan Leigh Star, a renowned American sociologist, wrote on The Ethnography of Infrastructure, where she and her colleagues defined dimensions of infrastructure.
Of these dimensions, I find that our systems for scaling accessibility don’t actually classify as a proper infrastructure:
- ❌ Embeddedness — the labor of accessibility is built upon interactions and systems, each meshing into the other; our systems don’t consider this deeply
- ❌ Transparency — our systems were often being reinvented and reintroduced
- ✅ Reach or Scope — our systems had both wide and narrow reaches/scopes
- ❌ Learned as a part of membership — students encounter accessibility inconsistently, and course staff don’t learn it easily in our systems
- ❌ Links with conventions of practice—since we lack a focused community of practice, our systems are unable to both shape and be shaped by the community’s conventions
- ❌ Embodiment of standards — our systems lack transparency by not connecting into other infrastructures in a standardized way
- ✅ Built on an installed base — our systems wrestle with the inertia of the existing courses and inherits strengths and limitations from the courses
- ✅ Is fixed in modular increments, not all at once or globally — our systems are designed to be adopted through smaller changes and interventions
- ✅ Becomes visible upon breakdown — our systems, when broken, are extremely visible
It’s especially easy to develop more systems, or expand our systems to symptomatically address these unmet dimensions; but what we lacked wasn’t more tools or processes. Without a proper consideration of infrastructure, scaled systems become fragile.
System fragility
In the time since leaving UW, I’ve been in the unique position to still be apart of their accessibility efforts (albeit, on the opposite coast.) And it’s with this position that I’ve been able to isolate several dimensions of system fragility. In the following fragilities, I’ll use CSE 12X as a case study.
Turnover over time
One of the major fragilities is the turnover of faculty, TAs, and students. For CSE 12X, it’s often the case that a different faculty member will teach each quarter. If we’re lucky, the same faculty member will stay for two, or even three quarters in a row. This is also exacerbated by the fact that there are summer instructors, who are often not faculty members and teach significantly smaller courses.
Furthermore, the TA and student bodies are everchanging. Students and TAs come, go, and graduate. What’s important to notice here, however, is that a subset of students eventually become TAs. So their experience of being a student in CSE 12X is vital to their perspective and actions as a TA.
From an accessibility perspective, what does this mean? Well, there are several implications of this turnover:
- Accessibility often needs to be reintroduced as new TAs are onboarded
- Faculty priorities may change from quarter-to-quarter
- Practices resurface, and then fade
- Efforts are restarted, or deprioritized
In a nutshell, accessibility is deeply coupled to individual efforts — and lack persistence.
Finite capacity and bandwidth
As we’ve seen with the earlier labor ecosystems, these groups are already stretched thin, which makes it difficult to always make meaningful progress on accessibility.
It’s important to acknowledge these capacities:
- TAs — Students who also teach, grade, and support the course
- Instructors — Lead course direction while balancing teaching,
research, service, and other responsibilities - Institutional Staff, Student Supports, and Experts — Provide shared infrastructure and periodic support institution-wide
It can feel hard to consistently practice accessibility, especially as courses ebb and flow throughout a term. A similar tension is that accessibility can’t be the only priority of a course either: new assignments, quizzes, and exams are constantly needed, among other variations every quarter.
We also noticed similar capacity constraints in the trainings we conducted; often time-bound, forcing us to prioritize practices, which directly influenced the types of accessibility efforts TAs conducted.
Fragmented and localized knowledge systems
Finally, I’ve noticed frictions in how individuals learn and practice accessibility.
- Tacit & Informal Knowledge — as a research scientist, a lot of my own knowledge around accessible CS was built up through practice and experiences I personally had; informal conversations, visits to groups/people across campus, and experimentation. Policies and guides are great, but only detail rules, not necessarily actions — which are harder to strictly define.
- Fragmented Information — Notion, Google Docs, Slack, Discord, White Boards, and Sticky Notes; information is deeply fragmented across platforms and modalities. Furthermore, individuals don’t know how to sort through it when they are trying to learn or practice accessibility.
- Locally Developed — accessibility improvements emerge where dedicated effort exists, and often stay where they emerged. Even though CSE 12X is a sequence, courses operate in some level of autonomy. For example, I developed accessible resource pipelines in Spring 2024 for CSE 121. Eight quarters later, CSE 122 and 123 do not have the system integrated, even though it would be relatively easy to do so.
- Context Dependence — similar to the prior friction, efforts don’t always translate, as not all courses share the same accessibility challenges. For example, teaching
HelloWorld.javaaccessibly is a very different challenge than making a binary tree with a height of 10 accessible.
These are a subset of the total fragilities, but what I identify to be the most significant fragilities facing our systems.
A vision of Durable Accessibility
We often discuss the sustainability of systems, but what good is sustainability if it is of variable and fragile effort, practice, and execution? Durability is the infrastructural capacity that allows scaled systems to persist.
Surviving turnover through integration
We can’t stop turnover; it’s a natural fragility. Accessibility must persist beyond individuals and be embedded in the course itself. It’s only with this consideration that accessibility does not need to be reintroduced from scratch each term, but can be a deep consideration into the course itself — all the way to the students.
Obviously, we will need to still introduce accessibility; but it can come in the curricula, but also part of continuations of the previous quarter’s efforts. There’s flexibility in how it’s presented and introduced, as long as the practices themselves are embedded into the course itself.
Designing for accessibility within finite capacities
Durable accessibility must operate within existing instructional roles and workflows — not as additional labor. It’s when accessibility is seen as additional labor that it becomes easily neglected, awaiting symptomatic improvements. Some suggestions I propose include:
- Embed accessibility into TA onboarding
- Make accessible practice the default expectation
- Integrate accessibility into required workflows
These are difficult to do, but over time, will become, simply, part of the process of running large computing courses. Establishing more consistent training efforts is another consideration — accessible teaching often equals good teaching. This removes the forced time constraint upon trainings, and decrease the previous prioritization of practices shown.
Developing legible and transferable practice
To describe how we can make knowledge systems durable, I will use an iceberg. Above the water are knowledge systems such as: Templates, Documentation, Policies, and Trainings. All great!
Templates are misapplied. Documentation goes unread. Policies are misunderstood. Trainings don’t stick.
Under the water exists the real knowledge we should be sharing. What it means to design accessible slides with the templates. How we might develop curriculum that integrates accessibility. Why testing content with a screen reader matters. Knowledge systems must be made legible and transferable, in ways that are both meaningful and ways that stick. It’s when content doesn’t stick or is difficult to uncover where mistakes, misinterpretations, and a lack of action occur.
Accessibility in large computing courses is not only about scaling efforts — it is about building durable infrastructure that allows those efforts to persist.
So what now?
In the short term, I hope to revisit our systems with Durable Accessibility in mind — not to build more tools and processes, but to build stronger infrastructure and develop intentional scaffolding. Durability means ensuring that accessibility efforts can survive turnover, capacity constraints, and fragmented knowledge. Without it, even well-designed systems become fragile.
With ADA Title II compliance on the horizon — and accessibility increasingly central to how we teach — we cannot afford to treat accessibility symptomatically. We need infrastructures that allow accessibility practice to persist beyond individuals, beyond terms, and beyond moments of urgency.
I’ve often felt that accessible education practices must be both visible (available and usable) and transparent (honest about what works and what breaks.) Now more than ever, we need to share not only resources, but processes and infrastructures that enable accessibility work to last.
