--- title: "Building the Web I Needed: Stammering, Disability Studies, and Neuroinclusive UX Design" author: "Rantideb Howlader" date: "2026-04-16T00:00:00.000Z" canonical_url: "https://www.ranti.dev/blog/accessibility-stammering-academic-reflection" license: "CC-BY-4.0" --- ## Why This Is Personal I stammer. Not in the dramatic, movie-style way where every word is a visible struggle. Mine shows up in blocks. Mid-sentence pauses where my brain knows exactly what I want to say, but my mouth refuses to cooperate. Sometimes I swap words on the fly because I can feel a block coming on a specific syllable. Sometimes I just go quiet and let someone else fill the space. If you have spoken to me on a call, you have probably noticed it. If you have only read my code and my writing, you would never know. That gap between how I communicate in speech and how I communicate through a keyboard is the reason I care so deeply about digital accessibility. It is not an abstract engineering problem for me. It is my daily reality. The broader conversation around web accessibility focuses almost entirely on sensory and physical accommodations. We prioritize aria-labels for screen readers, enforce contrast ratios for visual impairments, and ensure keyboard navigability for motor accessibility. These are structural imperatives of the web, but they represent only the baseline of human computer interaction. Moving beyond the surface reveals a critical gap: the accommodation of cognitive, neurological, and communicative diversities. Among these, speech dysfluencies hold a unique and deeply personal place in my work. This article is my attempt to bridge two worlds that rarely talk to each other: the academic study of disability, communication, and neurodiversity on one side, and the practical engineering of accessible React components on the other. In Digital Humanities, we talk about building technology that centers human experience. This is what that looks like when the human experience in question is your own. ## What Stammering Actually Is Stammering, or stuttering, is a neurological condition that affects the flow of speech. It is characterized by repetitions of sounds, prolongations of syllables, and involuntary pauses or blocks where the person is unable to produce the desired sound. The World Health Organization classifies stammering under ICD-11 code 6A01.0 as a developmental speech fluency disorder, estimating that approximately 1% of the global adult population is affected, with higher prevalence rates among children (WHO, 2019). I want to be direct about the myths, because I have lived through all of them. People have assumed I stammer because I am nervous. That I lack confidence. That I did not prepare well enough. One teacher in school genuinely believed I was doing it for attention. None of that is true. Decades of peer-reviewed research (Yairi and Ambrose, 2013; Craig et al., 2002) have confirmed what people who stammer have always known: it is a complex interplay of genetics, neurophysiology, and environmental factors. It has nothing to do with intelligence, anxiety, or upbringing. When we look at the neurobiology, functional magnetic resonance imaging studies (Watkins et al., 2008) show that individuals who stammer exhibit different patterns of brain activation during speech compared to fluent speakers. Specifically, there is atypical activity in the left inferior frontal gyrus, the premotor cortex, and the supplementary motor area. These regions are responsible for coordinating the hundreds of muscle movements required to produce speech. In people who stammer, that coordination works differently. Not worse. Differently. Chang et al. (2009) further demonstrated structural differences in white matter tracts connecting speech-motor and auditory regions, providing a clear neuroanatomical basis for developmental stammering. Recognizing stammering as a physiological reality rather than a psychological failing is not just academically correct. It is the bare minimum of respect. ## The Fluency Assumption in Communication Theory From an academic perspective, communication is traditionally viewed as a linear transaction involving a sender, a message, and a receiver. Shannon and Weaver's (1949) mathematical model of communication, which dominated mid-twentieth-century thinking, assumes a clean signal path. Noise is something to be eliminated. Fluency is the default. When fluency is disrupted, the traditional model falters, placing the entire burden of the disruption on the sender. I have felt this burden in every stand-up meeting, every client call, every job interview. The model assumes that if communication breaks down, the speaker failed. Modern linguistic and sociological theories push back on this. The social model of disability (Oliver, 1990) argues that an individual is not disabled by their impairment, but by societal barriers that fail to accommodate them. A person who stammers is not broken. A society that demands instant, uninterrupted speech and lacks the patience to listen is what creates the barrier. Habermas's theory of communicative action (1984) offers another useful lens. He argued that valid communication depends on mutual understanding and the willingness of all participants to engage in good faith. When a listener interrupts, finishes sentences, or disengages during a speech block, they are violating the communicative contract. The failure is not in the speaker's dysfluency. The failure is in the listener's refusal to participate equitably. That distinction changed how I think about everything I build. ## Respecting Someone Who Stammers Respecting someone who stammers means dismantling the expectation of immediate fluency. It involves shifting the focus from how a message is delivered to the substance of what is being said. Communication is not a race. I can tell you exactly what respect looks like because I know what its absence feels like. It looks like maintaining natural eye contact when I hit a block, rather than looking away uncomfortably. It looks like waiting for me to finish my thought without jumping in to complete my sentence. When someone finishes my sentence for me, even with good intentions, it sends a clear signal: your voice is not worth waiting for. Creating a safe space for communication requires intentionality. In meetings, it means establishing norms where everyone has the opportunity to speak without interruption. It means recognizing that silence or pauses in speech are not failures. They are just speech. In my personal life and professional practice, I strive to embody this patience. I listen to understand, not just to reply. I know what it costs when someone does not extend that same courtesy. ## The Sociology of Stigma The sociology of stigma plays a significant role in the lived experience of people who stammer. Erving Goffman defined stigma as an attribute that is deeply discrediting (Goffman, 1963). For many who stammer, the anticipation of speaking can provoke intense anxiety rooted in real, accumulated experience. Not hypothetical fear. I am talking about the memory of a specific classroom where someone laughed mid-sentence. The memory of a phone call where the other person hung up because they thought the line was dead during a block. Boyle (2013) found that adults who stutter reported significantly higher levels of self-stigma compared to typical speakers, and that this internalized stigma was a stronger predictor of negative psychosocial outcomes than stuttering severity itself. In other words, the social environment does more damage than the dysfluency. This is where the intersection of academic analysis and personal reality becomes inseparable. Understanding the sociological weight of stigma is not just an intellectual exercise. It is the reason I think twice before requiring a phone number on a contact form. It is the reason I always build a text-based support channel alongside any voice interface. ## Why I Build What I Build I did not get into accessibility engineering because it looked good on a resume. I got into it because I needed the web to work for people like me. Building accessible applications requires moving far beyond basic WCAG compliance checklists. It demands practical empathy translated into structural code. When I engineer accessibility controls, the underlying goal is rooted in something I understand viscerally: the experience of a digital environment that was not built with you in mind. On my portfolio, I built a comprehensive accessibility controls panel from scratch. It is a 1,700-line React component that provides eight distinct user profiles, granular content adjustments, color customization, orientation tools, and communication support features. The panel is not a third-party plugin bolted on as an afterthought. It is handwritten, integrated into the component tree from the ground up, and it persists user preferences in localStorage across sessions. Here is how the accessibility preference state is structured in TypeScript: ```typescript interface A11yPrefs { // Profiles speechComfort: boolean; seizureSafe: boolean; visionImpaired: boolean; adhd: boolean; cognitive: boolean; keyboardNav: boolean; blindMode: boolean; olderAdults: boolean; // Content fontSize: number; lineHeight: number; letterSpacing: number; contentScale: number; readableFont: boolean; highlightTitles: boolean; highlightLinks: boolean; // Color darkContrast: boolean; lightContrast: boolean; highContrast: boolean; highSaturation: boolean; lowSaturation: boolean; monochrome: boolean; // Orientation muteSounds: boolean; muteAnimations: boolean; hideImages: boolean; readingMode: boolean; readingGuide: boolean; readingMask: boolean; highlightHover: boolean; highlightFocus: boolean; bigBlackCursor: boolean; bigWhiteCursor: boolean; textMagnifier: boolean; noRushMode: boolean; // Custom colors customTextColor: string; customTitleColor: string; customBackgroundColor: string; } ``` Every single one of these fields maps to a real CSS class that gets toggled on the document root element. This is deliberate. By applying accessibility state at the root level through class toggling rather than inline styles on individual components, the entire page responds to user preferences without requiring prop drilling, context providers, or component-level awareness of accessibility state. The architecture is flat and deterministic. ```typescript function applyPrefs(prefs: A11yPrefs) { const root = document.documentElement; // Font size: computed from base + content scale multiplier const fontSizes = [100, 115, 130, 145, 160]; const scales = [1, 1.15, 1.3, 1.45, 1.6]; const effectiveFontSize = Math.round(fontSizes[prefs.fontSize] * scales[prefs.contentScale]); root.style.setProperty("--a11y-font-size", `${effectiveFontSize}%`); // Line height and letter spacing via CSS custom properties const lineHeights = [1.5, 1.8, 2.1, 2.4]; root.style.setProperty("--a11y-line-height", `${lineHeights[prefs.lineHeight]}`); const letterSpacings = [0, 0.8, 1.6, 2.4]; root.style.setProperty("--a11y-letter-spacing", `${letterSpacings[prefs.letterSpacing]}px`); // Toggle CSS classes on the document root const classes: Record = { "a11y-speech-comfort": prefs.speechComfort, "a11y-seizure-safe": prefs.seizureSafe, "a11y-vision": prefs.visionImpaired, "a11y-adhd": prefs.adhd, "a11y-reading-mask": prefs.readingMask, "a11y-no-rush": prefs.noRushMode, // ... all other preference mappings }; Object.entries(classes).forEach(([cls, active]) => { root.classList.toggle(cls, active); }); } ``` The CSS variables are consumed by global style rules that target content containers while explicitly excluding the accessibility settings panel itself. This isolation is critical. Without it, a user who scales font size to 160% would also scale the settings panel, making it unusable. ```css /* Content containers respond to user preferences */ main, article, .prose { font-size: var(--a11y-font-size, 100%) !important; } /* The settings panel remains stable regardless of user adjustments */ .a11y-controls-panel { font-size: 16px !important; line-height: 1.4 !important; letter-spacing: 0 !important; word-spacing: normal !important; } ``` This pattern of scoping accessibility transformations to content while shielding control surfaces is something I have not seen discussed in most accessibility tutorials. It emerged from real testing. When I scaled font size during development and watched my own settings panel become illegible, I realized that accessibility infrastructure must be immune to its own effects. ## The Speech Comfort Profile: Building for My Own Needs The Speech Comfort Profile is the feature I am most personally invested in. It is the first profile listed in the accessibility panel, and it exists because I built it for myself. When activated, the Speech Comfort Profile applies a coordinated set of adjustments designed to reduce the cognitive and sensory pressure that can compound speech anxiety in digital environments. The preset configuration looks like this: ```typescript const PROFILE_PRESETS: Record> = { speechComfort: { muteSounds: true, muteAnimations: true, readableFont: true, fontSize: 2, // 130% base size lineHeight: 2, // 2.1 line height letterSpacing: 1, // 0.8px spacing highlightFocus: true, alignLeft: true, lowSaturation: true, }, // ... other profiles }; ``` Each of these values targets a specific cognitive or sensory factor documented in accessibility research: **Muting sounds and animations.** For someone who stammers, unexpected audio cues or rapid visual movement can spike anxiety by introducing competing sensory stimuli during moments that already demand high cognitive effort. Sweller's cognitive load theory (1988) establishes that working memory has finite capacity. When a user is simultaneously processing screen content, managing speech-related anxiety, and being bombarded by motion or sound, the total cognitive load can exceed capacity. Muting these channels removes one entire layer of demand. The CSS implementation is aggressive by design: ```css .a11y-seizure-safe *, .a11y-mute-animations * { animation: none !important; transition: none !important; } ``` The `!important` flag is intentional here. Third-party scripts, embedded widgets, and CSS frameworks all inject their own animations. A soft override would be ignored by half the page. When someone activates this profile, every animation must stop. No exceptions. **Readable font and typography scaling.** The profile switches the entire body to Arial/Helvetica, increases font size to 130%, sets line height to 2.1, and applies 0.8px letter spacing. Research by Rello and Baeza-Yates (2013) on reading performance in neurodivergent users showed that sans-serif fonts with increased spacing significantly improved reading speed and comprehension for users with dyslexia. The same principles apply to cognitive accessibility broadly. Wider spacing reduces visual crowding, and taller line heights prevent the eye from losing its place, which matters when someone is dividing attention between reading and managing speech production. **Left text alignment.** The profile forces left alignment across all content. Justified text creates uneven word spacing that disrupts reading rhythm. Dyslexia research (British Dyslexia Association, 2018) has long recommended left-aligned text for accessibility. For someone managing a speech block while trying to read a prompt aloud, ragged right edges provide consistent word spacing that reduces one more variable the brain has to process. **Low saturation.** The profile reduces color saturation to 30% across the entire page: ```css .a11y-low-saturation { filter: saturate(0.3); } ``` High-saturation colors are visually stimulating. In contexts where a user is already under cognitive stress, a calmer visual environment reduces the total sensory load. This is not about aesthetics. It is about creating conditions where the brain can allocate more resources to communication and less to environmental processing. **Focus highlighting.** When the Speech Comfort Profile is active, every focusable element gets a visible red outline on focus: ```css .a11y-highlight-focus *:focus-visible { outline: 2px solid #ff5a5f !important; outline-offset: 0 !important; box-shadow: 0 0 0 2px rgba(255, 90, 95, 0.2) !important; } ``` This serves both keyboard navigation and cognitive orientation. When someone is mid-block and trying to find where they were on a form, a visible focus indicator answers the question instantly without requiring the user to visually scan the entire page. **Word spacing.** A subtle but deliberate addition. The Speech Comfort profile applies slightly increased word spacing to the body: ```css .a11y-speech-comfort body, .a11y-no-rush body { word-spacing: 0.05em; } ``` This is a small intervention, but for someone who reads aloud or subvocalizes while processing text, wider word boundaries make it easier to parse individual words without running them together mentally. When I am reading something while preparing to speak about it, that tiny bit of breathing room in the text genuinely helps. ## Communication Support: Beyond Visual Adjustments The Speech Comfort Profile is part of a broader Communication Support section in the accessibility panel that goes beyond visual adjustments into practical tools for people who stammer. **Quick Communication Phrases.** The panel includes pre-written phrases that a user can copy to their clipboard with one click: ```typescript const phrases = [ "I have a stammer, so I may pause while speaking.", "Please give me a few extra seconds to respond.", "Text communication works best for me when available.", ]; ``` These exist because I know how exhausting it is to explain your stammer in every new interaction. In professional settings, disclosing a speech difference takes courage, and having a ready-made phrase eliminates the cognitive overhead of composing that disclosure on the spot. The user clicks the phrase, it copies to their clipboard, and they can paste it into a chat, email, or meeting notes. It is a small feature. It took maybe thirty lines of code. But the human cost it addresses is significant. **Typing Support Badge (No-Rush Mode).** When enabled, all form inputs, textareas, and contenteditable elements get enhanced visual focus styling: ```css .a11y-no-rush input, .a11y-no-rush textarea, .a11y-no-rush [contenteditable="true"] { outline-width: 3px !important; outline-offset: 3px; caret-color: #ff5a5f; } ``` The thicker outline and colored caret provide a visual "you are here" anchor. The description in the panel reads: "Speech dysfluency is usually verbal, so typing stays default unless you enable this." That phrasing is intentional. Stammering is primarily a verbal phenomenon. Most people who stammer type fluently. But in situations involving voice recognition, dictation, or screen sharing where someone might be typing while also speaking, the no-rush styling signals to the interface that this user benefits from patience indicators. ## The ADHD Profile and Reading Mask: Applying Cognitive Psychology to the DOM The ADHD Friendly Profile demonstrates another intersection of research and implementation. When activated, it enables a reading mask built with CSS backdrop-blur: ```typescript adhd: { muteSounds: true, muteAnimations: true, readingGuide: true, readingMask: true, readingMode: true, contentScale: 1, lineHeight: 1, letterSpacing: 1, highlightFocus: true, }, ``` The reading mask is a full-viewport overlay that blurs everything except a narrow horizontal band around the user's cursor position. The implementation tracks pointer movement and renders five layers: ```tsx { prefs.readingMask && (
{/* Top blur zone */}
{/* Top gradient fade */}
{/* Clear reading band */}
{/* Bottom gradient fade */}
{/* Bottom blur zone */}
); } ``` The overlay uses `pointer-events-none` so it does not interfere with clicking or scrolling. The 88px clear band provides roughly 4-5 lines of readable text. Everything above and below is darkened to 28% opacity and blurred by 2 pixels. Gradient edges prevent a harsh visual cutoff. This directly applies Lavie's (1995) perceptual load theory to interface design. Lavie demonstrated that under high perceptual load, the processing of task-irrelevant stimuli is reduced. The reading mask artificially increases the perceptual load on the focused region while eliminating distractors. For users with ADHD who struggle with sustained focus on long-form text, this effectively creates a reading tunnel that constrains attention to the relevant paragraph. The text magnifier follows a similar philosophy. It tracks pointer position and renders a floating 220px circular lens that displays the text content under the cursor at 1.45rem: ```typescript function getMagnifierText(x: number, y: number, ignoreElement?: HTMLElement | null): string { const hitTarget = document.elementFromPoint(x, y); if (hitTarget instanceof HTMLElement) { const readable = hitTarget.closest( "p, li, blockquote, h1, h2, h3, h4, h5, h6, a, button, label" ); const readableText = readable?.textContent?.replace(/\s+/g, " ").trim(); if (readableText) return readableText.slice(0, 80); } // Fallback: use caret position APIs if (typeof document.caretRangeFromPoint === "function") { const range = document.caretRangeFromPoint(x, y); const nodeText = range?.startContainer?.textContent?.replace(/\s+/g, " ").trim(); if (nodeText) return nodeText.slice(0, 80); } return "Move over text"; } ``` The magnifier uses `document.elementFromPoint` for semantic element detection and falls back to `document.caretRangeFromPoint` for character-level precision. It explicitly ignores the accessibility panel itself via the `ignoreElement` parameter, so hovering over the settings does not produce magnified text from the controls. ## Algorithmic Bias in Voice User Interfaces This is where my frustration runs deepest. Voice user interfaces and speech recognition systems have become ubiquitous. Siri, Alexa, Google Assistant. They are trained overwhelmingly on fluent speech data. I have tried using voice assistants. The experience ranges from humiliating to useless. Mid-block, the system times out. It interprets a prolongation as a different word entirely. It asks me to "try again" as though fluency is something I can just switch on. Rudzicz et al. (2012) quantified this problem by testing automatic speech recognition systems on speakers with dysarthria and speech differences. Error rates increased by 200-400% compared to typical speakers. More recently, Mani et al. (2020) demonstrated that commercial voice assistants fail disproportionately for users with atypical speech patterns. This is algorithmic bias baked into the product. When engineers train speech models exclusively on fluent data, they build systems that exclude millions of people by design. Not by intention, but by omission, which in engineering amounts to the same thing. The fix is technically straightforward but organizationally difficult: diverse training data. If speech recognition models include data from speakers who stammer, who have accents, who speak slowly, who have motor speech disorders, the models become more robust for everyone. They handle background noise better. They handle varying speech rates better. Google's Project Euphonia and Apple's accessibility speech recognition improvements show that some teams are beginning to address this. But the default state of the industry remains exclusionary. ## Designing Multi-Channel Communication Here is a question every product team should ask: does our customer support rely entirely on phone calls? Are there alternative channels like text-based chat or email that do not penalize someone who finds speaking over the phone anxiety-inducing? I can tell you from personal experience that very few things are more stressful than mandatory phone verification. A system that only accepts voice input is, for me, a system that was not built with my existence in mind. Providing multiple avenues for interaction is a fundamental principle of inclusive design. W3C's Web Content Accessibility Guidelines (WCAG 2.1, Guideline 3.1) state that content should be "readable and understandable," but the spirit of the guideline extends to all interaction modalities. A platform that forces voice interaction as the only path is failing the same principle as a platform that forces mouse interaction as the only path. This connects directly to the concept of "time out" limits on web forms or automated phone systems. If a form expires after three minutes, it assumes a specific rate of cognitive processing and physical typing or speaking speed. WCAG 2.1 Success Criterion 2.2.1 requires that users be able to turn off, adjust, or extend time limits. For someone utilizing assistive technology, or someone who stammers through a voice recognition prompt, arbitrary time limits are not just inconvenient. They are insurmountable obstacles. ## The Medical Model vs. the Social Model The historical context of disability studies offers a powerful lens for understanding stammering. Early in the twentieth century, the medical model dominated. This paradigm treated any deviation from typical functioning as a defect requiring correction. Individuals who stammered were subjected to rigorous, sometimes punitive therapies aimed at forcing fluency. Van Riper's (1973) influential therapeutic framework, while more humane than earlier approaches, still centered fluency as the goal rather than communication confidence or self-acceptance. The late twentieth century saw the rise of the social model of disability. Pioneered by disability rights activists like Mike Oliver (1990) and Vic Finkelstein (1980), this model argued that people are disabled not by their neurological differences, but by societal structures that fail to accommodate them. A person using a wheelchair is disabled by stairs, not by their paralysis. A person who stammers is disabled by a society that demands instantaneous communication and penalizes thoughtful pauses. This distinction is crucial. It moves the responsibility from the individual to the collective. Translating the social model into production-ready React code forces developers to re-evaluate their entire component tree. A website that relies exclusively on rapid voice commands is inaccessible to someone with dysfluent speech. The barrier is not the user's speech pattern. The barrier is the design choice. ## The Cost of Passing "Passing" in a sociological context refers to the effort an individual expends to conceal a stigmatized identity and appear "normal" to avoid discrimination. I know this concept intimately because I have spent years doing it. Word substitution is my primary strategy. When I feel a block forming on a specific consonant, I reroute the sentence in real-time and pick a synonym that starts with a different sound. It happens so fast that most people never notice. What they do not see is the cognitive overhead. Every conversation becomes a simultaneous exercise in communication and self-editing. Every word choice is filtered through the question: can I say this without blocking? Boyle (2018) studied the relationship between stuttering self-stigma and psychological well-being, finding that concealment behaviors were significantly associated with anxiety, depression, and reduced quality of life. The energy spent on passing is energy that could be directed toward the actual content of the conversation. Constantino et al. (2017) further argued that treatment paradigms should shift from fluency-focused interventions toward acceptance-based approaches, recognizing that the social demand for "normal" speech causes more harm than the dysfluency itself. When I build accessibility features, part of what drives me is the desire to create digital environments where passing is unnecessary. Where people do not have to perform normalcy to use a product. When an individual feels safe to stammer openly, or to interact with technology at their own pace without penalty, they can redirect all that cognitive energy toward the thing that actually matters: the work, the idea, the connection. ## Neurodiversity as a Framework The concept of neurodiversity proposes that neurological differences are natural variations of the human genome (Singer, 1999). Just as biodiversity is necessary for a healthy ecosystem, neurodiversity is essential for a vibrant, innovative society. People who stammer, like those with dyslexia, autism, or ADHD, bring unique perspectives and problem-solving skills. I will say this plainly: managing a communication difference has made me a better engineer. It has given me a level of empathy for edge cases that I would not trade. When I test an interface, I do not just test the happy path. I think about the user who processes information differently. The user who needs more time. The user whose input pattern does not match the assumed default. I think about them because I am them. Armstrong (2010) in "Neurodiversity: Discovering the Extraordinary Gifts of Autism, ADHD, Dyslexia, and Other Brain Differences" documented how neurodiverse individuals often develop compensatory strengths. People who stammer frequently develop strong written communication skills, heightened emotional intelligence from years of reading social reactions, and exceptional planning ability from constantly anticipating conversational challenges. These are not consolation prizes. They are genuine cognitive adaptations shaped by lived experience. ## Universal Design: From Architecture to the DOM This understanding has driven my approach to universal UI design. Originally an architectural concept developed by Ronald Mace at North Carolina State University, universal design aims to create environments accessible to everyone without the need for specialized adaptation. The seven principles (equitable use, flexibility, simple and intuitive, perceptible information, tolerance for error, low physical effort, and size/space for approach) translate directly to interface engineering. My accessibility panel embodies several of these principles. The profile system provides flexibility through pre-configured presets (equitable use and simplicity) while allowing granular adjustment of individual settings (flexibility). The reading mask and focus highlighting provide perceptible information. The no-rush mode demonstrates tolerance for error by removing time pressure. The panel's own CSS isolation ensures that users can adjust content without losing access to the settings UI (low physical/cognitive effort). Consider closed captioning as a case study. Originally designed for the deaf and hard of hearing community, closed captions have proven universally beneficial. People use them in noisy airports, language learners use them to improve comprehension, and neurodivergent individuals use them to aid information processing. Curb cuts in sidewalks tell the same story: designed for wheelchair users, used by everyone with strollers, luggage, or bicycles. By designing for the margins, we improve the experience for everyone. The same principle applies to accommodating stammering. If speech recognition models are trained on diverse datasets that include dysfluent speech, they become more accurate for all users. The Speech Comfort Profile's typography adjustments improve readability for everyone, not just people who stammer. This is the essence of inclusive engineering. It builds resilience into our systems. ## Intersectionality and Stammering Stammering does not occur in a vacuum. It interacts with race, gender, socioeconomic status, and cultural background. St. Pierre (2012) examined how stammering intersects with masculinity norms, noting that men who stammer often face compounded pressure because fluent speech is conflated with authority and competence in patriarchal communication cultures. The pressure to conform to specific communication standards varies widely across different professional and social contexts. A person who stammers might navigate complex layers of stigma, compounded by other marginalized identities. This intersectional reality demands that accessibility solutions be culturally aware, not just technically correct. A text-based support alternative that only works in English still excludes non-English speakers who stammer. Language-specific speech recognition bias compounds the problem. ## Reforming Education and Hiring Practices Academic institutions must prioritize diverse communication styles. Group projects, oral presentations, and participation grades often inherently penalize students who stammer. I know because my grades were affected by participation scores that equated speaking fluently with understanding the material. Educators must be trained to assess the content of a student's knowledge rather than the fluency of its delivery. Offering alternative evaluation methods ensures that academic rigor is maintained without sacrificing equity. In the corporate world, hiring practices often emphasize "excellent communication skills," a phrase that frequently operates as a coded demand for fluent, extroverted speech. This excludes highly qualified candidates who stammer or process information differently. Excellent communication should encompass clarity of thought, the ability to listen actively, written proficiency, and empathetic interaction. Not just the ability to speak quickly without pausing. Butler (2013) surveyed employers and found that negative perceptions of stammering persisted even when interviewers were informed about the nature of the condition. This suggests that awareness alone is insufficient. Structural changes to hiring processes, such as offering written interviews, asynchronous video submissions, or skills-based assessments, are necessary to create genuinely equitable evaluation. ## Media Representation Historically, popular media has relegated characters who stammer to the roles of comic relief, villains, or helpless victims. Think of how stammering is used as a marker of weakness, cowardice, or dishonesty in film and television. These portrayals reinforce harmful stereotypes and societal biases. Authentic representation matters. When media showcases complex, capable individuals who happen to stammer, it normalizes dysfluent speech and challenges prevailing prejudices. The 2010 film "The King's Speech" was a watershed moment for stammering representation, but even that narrative centered on overcoming the stammer rather than accepting it. The message was still: you must fix this to lead. A truly progressive representation would show a character who stammers leading effectively without the stammer being the story. ## Language and the Power of Labels In my daily workflow, I treat linguistic structure with the same strictness as strict types in TypeScript. The words we use shape reality. Using person-first language, such as "a person who stammers" rather than "a stutterer," emphasizes the individual's humanity over their condition. Academic writing has long recognized the power dynamics inherent in labels. Getting the terminology right is not political correctness. It is precision. It is worth noting that the stammering community itself has diverse preferences. Some individuals embrace identity-first language ("I am a stutterer") as a form of reclamation, similar to how many autistic adults prefer "autistic person" over "person with autism." The key is respecting individual preference rather than imposing a universal standard. In my own writing and in the interface copy of the accessibility panel, I use "Speech Comfort" because it describes the function without labeling the user. ## Moving Beyond WCAG Compliance Toward Digital Empathy In web accessibility, the WCAG guidelines provide a foundational framework. Yet compliance is merely the starting point. Compliance ensures a site is technically usable. Empathy ensures it is welcoming. Providing clear instructions, avoiding sensory overload, and ensuring that critical functions work across diverse user interaction methods are steps toward digital empathy. For someone who stammers, knowing a platform offers a robust text-based support option instead of demanding a phone call is not a convenience. It is access. WCAG 2.1 introduced cognitive accessibility success criteria under Guideline 3.3 (Input Assistance) and the supplementary Cognitive and Learning Disabilities Accessibility Task Force continues to develop additional guidance. But the guidelines will always lag behind lived experience. The people who know what is needed are the people who need it. That is why I build these features. Not because a spec told me to. Because I know what is missing when they are not there. ## The Architecture of Inclusion: Lessons from 1,700 Lines of Accessibility Code Looking back at what the accessibility controls component has become, a few architectural patterns are worth highlighting for other developers who want to do similar work. **Profile presets as composed preferences.** Each profile is not a monolithic mode. It is a set of individual preferences that get merged on top of the current state. When a user activates the Speech Comfort Profile, it does not wipe their previous customizations. It applies its preset values and leaves everything else untouched. When they deactivate it, only the preset values reset: ```typescript function resetProfilePresetValues(base: A11yPrefs): A11yPrefs { const next = { ...base }; PROFILE_CONTROLLED_KEYS.forEach((key) => { next[key] = DEFAULT_PREFS[key] as never; }); return next; } ``` **Muting media elements across the DOM.** The Mute Sounds feature does not just prevent new audio. It actively pauses and mutes all existing `