I used to teach technical writing the traditional way that focused on clarity, conciseness, and correctness. Documents were neutral containers for information. Accessibility was a checklist item, something you added at the end if you remembered. Then I watched a student create a beautiful user manual that no screen reader could parse. Another created a video tutorial with no captions. They had followed my instructions perfectly.
The problem wasn’t their work. It was mine.
Now my classes start with a different premise. Before we discuss audience analysis or document design, we examine who gets excluded and why. I ask students to find technical documentation they use regularly and try to break it. Use it without a mouse. Try it with your eyes closed. Translate it and back again. What falls apart? Who was forgotten? One student discovered her favorite recipe app was unusable with a screen reader. Another realized his desk assembly instructions assumed users could distinguish red from green parts. These aren’t abstract accessibility violations. They’re design choices that exclude real people from everyday tasks. These opening exercises are also the pedagogical groundwork for the community-based projects described below: they give students a felt sense of exclusion before they begin designing against it. Walton, Moore, and Jones (2019) argue that technical communication is never neutral. Every document either reproduces existing power structures or works against them.
When we treat accessibility as an afterthought, we teach students that some users matter more than others. When we design for a mythical “average user,” we’re really designing for users who match our own abilities and assumptions. I’ve rebuilt my curriculum around access as a design responsibility from the first draft. Students don’t add accessibility features after creating content. They begin every project by mapping potential barriers and exclusions.
Three questions guide this work. First, who will use this? Not “general audience” but specific users with specific needs, abilities, technologies, languages, and contexts. Second, who might be excluded? Screen reader users? Non-native speakers? Users with cognitive disabilities or without high-speed internet? Third, what barriers does this design create? Color-only information? Jargon? Platform limitations? Cultural assumptions? These questions aren’t answered once. They’re habits of mind that reshape how students approach any communication task.
Multimodality isn’t just about using different tools. It’s about understanding that different modes offer different affordances for different users in different contexts (Shipka, 2011). A video tutorial might work beautifully for someone learning to tie knots but fail completely for a blind user. A text-heavy manual might be perfect for someone who needs to reference specific steps but overwhelming for someone with certain cognitive disabilities. The solution isn’t to pick one mode and make it accessible enough. It’s to design across modes strategically. One semester, students worked with a campus multicultural center to create orientation materials. They quickly realized that international students needed information in multiple formats: a quick-reference PDF they could download before arriving, short videos explaining confusing processes, and an interactive map they could use offline. No single mode served all needs. The combination did.
This approach aligns with Gonzales’s (2018) work on translation and rhetorical remix. She demonstrates that multilingual communicators don’t just swap words between languages. They remix content across cultural and modal boundaries, adapting messages to fit new contexts. My students learn to see this kind of flexibility as professional strength rather than extra work.
Working with real communities and groups produces the most meaningful learning. Actual documentation projects—with real stakes, real audiences, and real feedback—transform access from a concept students can discuss into a practice they can enact. I partner with community organizations, campus groups, and local nonprofits who need actual documentation. Students have created health information guides for refugee services centers, usability reports for food bank websites, and instructional videos for youth literacy programs. These are not service projects where students design “for” a community from the outside. Community members participate throughout: they review drafts, identify gaps, push back on assumptions, and help define what “useful” means for them. Students negotiate revisions directly in response to that feedback, which makes these partnerships genuinely collaborative rather than extractive. Working with real clients changes everything. Students can’t dismiss accessibility as theoretical nicety when they’re creating content for a specific person who uses a screen reader. They can’t ignore language barriers when their document will serve multilingual families. One group created a guide to campus resources for undocumented students. They had to think carefully about who might access the document, under what circumstances, and what risks it might pose. These questions have no easy answers, but grappling with them teaches more about user-centered design than any textbook explanation could.
Every project begins with an access audit. I provide a shared framework to start, but students adapt and extend it: by mid-semester they are building their own audit criteria tailored to their specific audience and project context, rather than applying a fixed checklist. Before writing a single word, students identify their audience, then systematically consider potential barriers: sensory, cognitive, linguistic, technological, cultural. They research how specific users might interact with their content. What assistive technologies might they use? What language preferences? What prior knowledge can we assume? Then comes strategic mode and format selection. Students learn Web Content Accessibility Guidelines (WCAG) not as compliance requirements but as design principles. They practice writing alt text that conveys meaning, understand why color contrast matters, and learn to structure headings for navigation. This is also where I introduce the scholarly debate around plain language itself. TPC scholars like Jones and Williams (2017) have challenged the assumption that “plain language” is a neutral or universal good, arguing that clarity standards can encode cultural biases that privilege some users while marginalizing others. Students sit with that tension: accessibility principles can open doors, but they are not immune to the power dynamics they aim to disrupt. That said, students consistently find that careful attention to structure and clarity tends to serve a wide range of users, not just users with cognitive disabilities.
Assessment focuses on process and rationale. Students document their design choices and explain how those choices address specific barriers. A beautifully designed infographic earns no credit if the student can’t articulate how color-blind users will access the information. Clear instructions fail if the student hasn’t considered users with different literacy levels. Following Jones, Moore, and Walton (2016), I treat technical communication as a social justice practice rather than neutral skill acquisition. When we teach students to document without questioning who benefits and who gets excluded, we’re teaching them to maintain systems that harm people.
Some students resist. They want formulas and templates, clear rights and wrongs. Designing for access requires ambiguity and iteration. For example, one student told me she couldn’t begin an assignment without a rubric—that having a checklist helped her feel confident she’d met the expectations. Rather than dismissing that need, I turned it back to her: “What does your audience need this document to do? Let’s use that as the rubric.” We built her criteria together from the audience analysis she had already done. By the end of the semester, she was designing her own access audits from scratch and articulating her reasoning without prompting. The resistance, when I take it seriously rather than overriding it, often produces the most careful thinking in the room. Most students, once they start seeing exclusion as design failure rather than user limitation, become fierce advocates for accessible practice. The call for social justice in technical communication is not new. Haas (2012) and Agboka (2021) have long argued that our field must reckon with race, power, and whose knowledge systems get centered in technical practice. What is changing—unevenly, but meaningfully—is how those theoretical commitments are being translated into everyday classroom work. My pedagogy is a response to that longer tradition: an attempt to treat documents not as neutral artifacts but as interventions with material consequences. My classroom is one small space where students practice designing communication that includes rather than excludes, that reduces harm rather than reproduces it. It’s manageable work that doesn’t require expensive tools or specialized training. It requires believing that access matters from the beginning, that our design choices have ethical weight, and that teaching technical writing means teaching students to build a more accessible world, one document at a time.
References
Agboka, G. Y. (2021). “Subjects” in and of Research: Decolonizing Oppressive Rhetorical Practices in Technical Communication Research. Journal of Technical Writing and Communication, 51(2), 159-174.
Haas, A. M. (2012). Race, rhetoric, and technology: A case study of decolonial technical communication theory, methodology, and pedagogy. Journal of Business and Technical Communication, 26(3), 277–310.
Jones, N. N., & Williams, M. F. (2017). The social justice impact of plain language: A critical approach to plain-language analysis. IEEE Transactions on Professional Communication, 60(4), 386–404.
Gonzales, L. (2018). Sites of translation: What multilinguals can teach us about digital writing and rhetoric. University of Michigan Press.
Jones, N. N., Moore, K. R., & Walton, R. (2016). Disrupting the past to disrupt the future: An antenarrative of technical communication. Technical Communication Quarterly, 25(4), 211-229.
Shipka, J. (2011). Toward a composition made whole. University of Pittsburgh Press.
Walton, R., Moore, K. R., & Jones, N. N. (2019). Technical communication after the social justice turn: Building coalitions for action. Routledge.
