Finding an Accessibility-First Culture in NPMX  🔗 **Source:** [Finding an Accessibility-First Culture in NPMX](https://piccalil.li/blog/finding-an-accessibility-first-culture-in-npmx/) > [!note]+ Document Notes > tags: #accessibility #community #culture #digital-inclusion > author: Abbey Perini > source: Piccalilli > reference: https://piccalil.li/blog/finding-an-accessibility-first-culture-in-npmx/ > date created: 2026-03-03 12:00 > > # 🏷️ Title: Finding an accessibility-first culture in npmx > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Document accessibility patterns and solutions in onboarding materials — prevent repetitive explanations #accessibility - [H2] Install accessibility linters and automated testing in development workflow — catch issues early #testing - [H3] Create dedicated accessibility channels and tag experts in relevant discussions — normalize accessibility concerns #community ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Piccalilli](https://piccalil.li/) - [npmx Alpha Release](https://npmx.org) ## 📝 Summary - Abbey Perini shares her experience joining npmx and discovering an accessibility-first development culture - The article contrasts typical experiences of being the sole accessibility advocate with finding a community that prioritizes accessibility - Key insights include practical tips for building accessibility-first cultures in development teams - The npmx community demonstrates how accessibility can be integrated from the start rather than retrofitted - Bottom line: Accessibility-first cultures are possible and transformative for both developers and users ## 📖 Main Content The article describes Perini's journey from accessibility isolation to finding a supportive community at npmx. She explains the common experience of being the only person advocating for accessibility in development teams, often having to repeatedly explain basic issues that automated tools could catch. This leads to burnout and loneliness in the role of accessibility advocate. At npmx, Perini discovered a different model: a dedicated accessibility channel, automated accessibility tests in pull requests, and team members already implementing accessibility best practices. The community treats accessibility discussions as important architectural conversations rather than afterthoughts. The article concludes with actionable advice for building accessibility-first cultures, including documentation, automated testing, early consideration in design phases, and responding with humility when mistakes occur. The emphasis is on inclusion as the ultimate goal. ## 🗒️ Notes #### Article section — [H1] Missing an accessibility-first community - Key idea: Being the sole accessibility advocate is exhausting and lonely - Evidence: "It's hard to put into words how lonely it is when you're the only person ensuring that there aren't click handlers on generic elements" #### Article section — [H2] The isolation of accessibility work - Key idea: Compliance can be built in from the start rather than fixed later - Evidence: "When you know anything about digital accessibility, you know that compliance doesn't always have to be a never-ending slog of fixes" #### Article section — [H3] Seeking deeper accessibility knowledge - Key idea: Working with accessibility experts provides validation and reduces explanation fatigue - Evidence: "It's nice not to have to explain" - response about automated captions quality #### Article section — [H1] Finding an accessibility-first community at npmx - Key idea: Discovering automated accessibility tests and dedicated channels was unexpected - Evidence: "I didn't expect to see a dedicated accessibility channel. I was delighted to see automated accessibility tests" #### Article section — [H2] Learning in an accessibility-focused environment - Key idea: Architectural accessibility conversations become possible when expertise is valued - Evidence: "I was also getting to have the big conversations about architecture and design that I missed having" #### Article section — [H3] Normalization of accessibility concerns - Key idea: Accessibility experts are proactively included in relevant discussions - Evidence: "If there's a possible accessibility issue in another conversation, accessibility experts are tagged in" #### Article section — [H1] Documentation as foundation - Key idea: Written accessibility documentation prevents repetitive explanations - Evidence: "Document the accessibility problems you've already solved, patterns for interactive controls" #### Article section — [H2] Testing and enforcement strategies - Key idea: Component design should enforce accessibility requirements - Evidence: "An <input> should always have a label, so the labelText prop for your component with an <input> should be required" #### Article section — [H3] Early integration and continuous improvement - Key idea: Accessibility auditing should be part of quality assurance processes - Evidence: "Think of accessibility concerns as early as possible, such as in the design and planning phases" #### Article section — [H2] Humility and learning from mistakes - Key idea: Responding to accessibility failures with humility creates learning opportunities - Evidence: "Respond with humility when you get it wrong, because you will get it wrong" ## 📚 References - [Piccalilli Blog](https://piccalil.li/blog/) - [npmx Project](https://npmx.org) - [Stef Walter's AxeCon talk](https://axecon.com) ## 🗣️ Paraphrase - Accessibility advocacy is often isolated work where one person repeatedly explains basic concepts that automated tools could catch, leading to burnout and loneliness in development teams - The npmx community demonstrates an alternative model where accessibility is integrated from the start, with dedicated channels, automated testing, and proactive inclusion of accessibility expertise in architectural discussions - Building accessibility-first cultures requires documentation, automated testing, early design consideration, component-level enforcement, expert involvement, and humble responses to mistakes with inclusion as the ultimate goal ## 📰 Newsletter **Discovering Accessibility-First Development Culture** Abbey Perini shares a refreshing perspective on what's possible when accessibility isn't an afterthought. Her experience joining npmx reveals how development communities can integrate accessibility from day one rather than retrofitting it later. Key takeaways for WordPress developers: - **Automate accessibility testing** in your development workflow - **Document accessibility patterns** to prevent repetitive explanations - **Enforce accessibility at the component level** - make required props actually required - **Include accessibility experts** in architectural discussions proactively The contrast between isolation and community support highlights why accessibility-first cultures matter for both developers and users. When accessibility expertise is valued and integrated early, everyone benefits. Resources: [WordPress Accessibility Handbook](https://make.wordpress.org/accessibility/handbook/), [WP Accessibility Plugin](https://wordpress.org/plugins/wp-accessibility/), [WAVE Web Accessibility Evaluator](https://wave.webaim.org/) ## ✅ Action Items #### WordPress - Accessibility: Integrate automated accessibility testing in core development workflows - Core: Document accessibility patterns for common interactive components - Community: Create dedicated accessibility channels in community spaces - Training: Develop accessibility-focused lesson plans for developers - Design: Include accessibility considerations in early design review processes #### Community - Contributors: Tag accessibility experts proactively in relevant discussions - Maintainers: Enforce accessibility requirements at the component/theme level - Sponsors: Fund accessibility auditing and expert review processes #### DevRel - Education: Create workshops on building accessibility-first development cultures - Developer experience: Improve accessibility linting and testing tool integration - Community management: Establish accessibility expertise recognition programs ## 🧪 Hypotheses - Teams with dedicated accessibility channels and automated testing produce more accessible software from initial release - Developers in accessibility-first cultures experience less burnout when advocating for inclusive design - Early accessibility integration reduces long-term technical debt compared to retrofitting approaches - Communities that proactively include accessibility experts in architectural discussions create more inclusive products ### 📊 Methodology - Survey developers in accessibility-first vs traditional cultures about advocacy experiences and burnout levels - Analyze accessibility metrics from projects with early integration vs retrofit approaches - Conduct interviews with accessibility experts about community inclusion impacts - Measure technical debt related to accessibility fixes in different development culture models ### ❓ Questions - What specific organizational structures most effectively support accessibility-first cultures in distributed teams? - How can automated accessibility testing be integrated without creating false security about manual testing needs? - What metrics best indicate whether a development community has successfully adopted accessibility-first practices? ### 🔮 Future Research - Comparative study of accessibility outcomes across different community culture models - Investigation of accessibility expertise retention in various organizational structures - Analysis of user experience improvements in accessibility-first vs retrofit development approaches ### 💡 Implications - Practice: Shift from individual accessibility advocacy to community-wide cultural integration - Policy: Establish accessibility requirements at the component and system architecture level - Education: Develop training that emphasizes community building alongside technical accessibility skills - Funding: Invest in accessibility expertise as architectural consultation rather than quality assurance afterthought ### 🧠 Learning Styles Assessment Reading level estimate: Grade 12 (accessible to professional developers) #### 👀 Visual learners - Present: Clear section breaks, examples of UI patterns - Improve: Diagrams showing accessibility-first workflow integration, before/after culture comparisons #### 🔊 Aural learners - Present: Quoted conversations and dialogue examples - Improve: Audio version highlighting community interaction examples #### 🗣️ Verbal learners - Present: Clear definitions of accessibility-first culture, practical terminology - Improve: Glossary of accessibility community terms, analogies for culture change #### 🧩 Kinesthetic learners - Present: Actionable tips list, practical implementation steps - Improve: Interactive checklist for building accessibility-first cultures, hands-on audit tools #### 🧠 Logical learners - Present: Clear progression from problem to solution with evidence - Improve: Decision tree for accessibility culture assessment, metrics for measuring culture change #### 🧑‍🤝‍🧑 Social learners - Present: Community interaction examples, collaborative problem-solving - Improve: Discussion prompts for team accessibility culture assessment, peer review templates #### 🧘‍♀️ Solitary learners - Present: Personal reflection on individual experiences, self-assessment opportunities - Improve: Individual action planning worksheet, self-evaluation rubric for accessibility advocacy #### 🌿 Naturalistic learners - Present: Organic community growth examples, cultural ecosystem analogies - Improve: Systems thinking approach to accessibility culture change, environmental factors analysis ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, descriptive section organization - Improve: ARIA landmarks for main content sections, more descriptive heading text #### Keyboard navigation - Present: Standard web navigation, logical reading order - Improve: Skip navigation for long article sections, keyboard shortcuts for section jumping #### Contrast and readability - Present: Standard text contrast ratios maintained - Improve: Verify contrast meets WCAG AA standards across all text elements #### Text resizing and reflow - Present: Responsive design supports text scaling - Improve: Test at 200% zoom to ensure no content clipping occurs #### Media and captions - Present: Text-based content with good structure - Improve: Alternative formats for key insights, audio description for any visual content #### Forms and interactions - Present: Standard link interactions with descriptive text - Improve: Ensure all interactive elements have sufficient target size #### Standards reference - Meets WCAG 2.2 AA Success Criterion 1.3.1 (Info and Relationships) through proper heading structure ### 🌍 DEIB Assessment #### Cultural breadth - Present: Individual experience from specific community context - Improve: Examples from diverse development communities, global accessibility perspective #### Inclusive language - Present: Person-first language, avoids ableist terminology - Improve: Define technical accessibility terms, provide plain language alternatives #### Neurodiversity support - Present: Well-structured content with clear sections - Improve: Consistent heading frequency, bullet point summaries for key concepts #### Representation - Present: Female developer perspective in accessibility space - Improve: Include diverse voices from accessibility community, multiple experience levels #### Psychological safety - Present: Validates common accessibility advocate experiences, supportive tone - Improve: Content warnings for burnout discussion, resources for accessibility advocates ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from isolation problem to community solution model - Inductive strength: Uses specific npmx experience to generalize about accessibility-first cultures - Causal reasoning: Clear connections between community practices and improved accessibility outcomes - Analogical strength: Effective comparison between traditional and accessibility-first development cultures #### Fallacies - No significant logical fallacies identified - Appropriate use of personal experience as evidence for broader cultural patterns #### Tone of voice - Overall tone: Personal, reflective, and hopeful with practical focus - Balances vulnerability about challenges with optimism about solutions ### 🛡️ DARVO Analysis - Deny: No denial patterns present - acknowledges accessibility challenges openly - Attack: No attacks on individuals or organizations - focuses on systemic issues - Reverse victim/offender: No victim/offender reversal - maintains focus on inclusion goals - Emotional cues and rhetoric: Positive, solution-focused language that validates shared experiences ## 🎯 Conclusion The article demonstrates that accessibility-first development cultures are both possible and transformative. Rather than treating accessibility as individual advocacy work, successful communities integrate accessibility expertise into architectural decisions, automate testing workflows, and proactively include accessibility considerations in all phases of development. The practical tips provided offer a roadmap for teams seeking to move beyond compliance-focused approaches toward truly inclusive development practices. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Accessibility-first cultures prevent developer burnout > [!quote] [Finding an accessibility-first culture in npmx](https://piccalil.li/blog/finding-an-accessibility-first-culture-in-npmx/) by [[Abbey Perini]] via [[Piccalilli]]. Published 2026-03-03. Accessed 2026-03-03. > "It's hard to put into words how lonely it is when you're the only person ensuring that there aren't click handlers on generic elements." Documents the emotional cost of isolated accessibility advocacy work in development teams. [view highlight](https://piccalil.li/blog/finding-an-accessibility-first-culture-in-npmx/#missing-an-accessibility-first-community) #xref #articleseed ID:rw_accessibility_isolation ### [H2] Documentation prevents repetitive accessibility explanations > [!quote] [Finding an accessibility-first culture in npmx](https://piccalil.li/blog/finding-an-accessibility-first-culture-in-npmx/) > "Document the accessibility problems you've already solved, patterns for interactive controls and colors that have sufficient contrast together." Practical approach to scaling accessibility knowledge across development teams. [view highlight](https://piccalil.li/blog/finding-an-accessibility-first-culture-in-npmx/#wrapping-up-with-some-tips) #xref ID:rw_accessibility_documentation --- ### 🔖 Atomic Split Pad (Zettel Candidates) Purpose: Promote reusable claims into Atomic notes. Split level: H4 #### [Z1] Automated testing reduces accessibility advocacy fatigue - Applies to development teams with basic accessibility tooling capacity - Reference to npmx pull request experience - Links: [[Accessibility-Testing]] [[Developer-Experience]] [[Community-Culture]] #### [Z2] Component-level accessibility enforcement scales better than guidelines - Most effective when integrated into design system architecture - Reference to required labelText prop example - Links: [[Design-Systems]] [[Accessibility-Architecture]] [[Developer-Tools]] --- ### ✏️ Fleeting Queue Purpose: Capture quick actions for Fleeting notes. - [F1] Research accessibility linting tools for WordPress development workflow — npmx automated testing inspiration #fleeting #inbox - [F2] Document common WordPress accessibility patterns for community reuse — prevent explanation fatigue #fleeting #inbox - [F3] Investigate creating accessibility channel in WordPress community spaces — normalize accessibility discussions #fleeting #inbox <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/Finding an Accessibility-First Culture in NPMX|Finding an Accessibility-First Culture in NPMX, piccalil.li]] ## Highlights - Recently however, I got the chance to catch up with some of my former coworkers. There was a moment when I said “I don’t know if the automated captions are better or worse.” One of them responded “Yeah, they’re really wrong - a live captioner would be a lot better.” I closed my eyes, leaned back in my chair, and sighed “It’s nice not to have to explain.” Then, I remembered how nice it was to have a live captioner in our meetings. The next week, I started looking at expensive certifications. I wanted a reason to start learning deeply about accessibility again. ([View Highlight](https://read.readwise.io/read/01kjwy9f197774wsn9ssjrt6p3)) - Tags: 👻 ai highlighted