Inclusive engineering involves creating systems, products, and code that consider and serve diverse users, communities, and team members. This document outlines practices for building more inclusive software products and fostering an inclusive engineering culture.
- Include diverse participants in user research
- Consider different perspectives, abilities, backgrounds, and contexts
- Identify and mitigate bias in research questions and methodologies
- Validate findings with users from underrepresented groups
- Create diverse personas that represent your entire user base
- Consider contextual factors (device access, connectivity, language)
- Include edge cases related to accessibility and international use
- Document anti-personas to understand who might be excluded
- Consider impact on diverse user groups in prioritization frameworks
- Evaluate features from an equity perspective
- Avoid implementing features that only benefit the majority
- Balance business needs with inclusive design requirements
- Ensure sufficient color contrast (WCAG AA minimum, AAA preferred)
- Don't rely solely on color to convey information
- Use flexible layouts that adapt to different text sizes and screen dimensions
- Test designs with different display settings and assistive technologies
- Use plain, clear language
- Avoid idioms, colloquialisms, and culturally specific references
- Create content that respects diverse cultural perspectives
- Consider translation and localization requirements early
- Provide multiple ways to interact (mouse, keyboard, touch, voice)
- Support assistive technology standards
- Design for various input methods and abilities
- Test interactions with diverse user groups
- Build accessibility into design system components
- Document accessibility requirements for components
- Include diverse imagery in style guides
- Implement responsive design principles
- Use inclusive terminology in code
- Avoid terms with negative historical contexts
- Replace problematic terms in legacy code
- Consider cultural connotations of metaphors and naming
- Write clear comments accessible to non-native English speakers
- Document accessibility features and considerations
- Include diverse examples in code samples
- Explain why accessibility features are implemented
- Write inclusive commit messages
- Use inclusive terminology in branch naming
- Document accessibility-related changes clearly
- Include diverse voices in code reviews
- Include accessibility testing in QA processes
- Test with assistive technologies and browser extensions
- Create test cases for diverse user scenarios
- Document accessibility compliance requirements
- Follow WCAG guidelines (minimum AA compliance)
- Implement proper semantic HTML
- Use ARIA attributes appropriately
- Ensure keyboard navigability
- Implement focus management for custom components
- Separate UI text from code
- Support right-to-left languages
- Implement Unicode correctly
- Account for text expansion in translations
- Support different date, time, and number formats
- Optimize for low-end devices
- Design for unreliable or low-bandwidth connections
- Implement progressive enhancement
- Create offline capabilities where appropriate
- Implement inclusive data collection practices
- Consider privacy needs of vulnerable populations
- Provide clear control over personal data
- Design authentication with diverse needs in mind
- Build diverse engineering teams
- Create inclusive hiring processes
- Support retention of underrepresented groups
- Promote equitable advancement opportunities
- Establish inclusive meeting practices
- Create multiple channels for input and feedback
- Document decisions for asynchronous participation
- Respect different communication styles
- Make documentation accessible to team members with different experience levels
- Create mentorship opportunities for underrepresented groups
- Recognize and credit diverse contributions
- Share context and institutional knowledge widely
- Support flexible work arrangements
- Create accommodations for different needs
- Establish inclusive team events and activities
- Provide equitable access to tools and resources
- Track accessibility compliance
- Monitor internationalization coverage
- Collect feedback from diverse user groups
- Analyze usage patterns across different demographics
- Conduct regular accessibility audits
- Review code for inclusive terminology
- Audit documentation for clarity and inclusivity
- Review user journeys for different personas
- Create actionable plans based on audit results
- Prioritize inclusion-related improvements
- Track progress over time
- Celebrate inclusive design wins
- Microsoft Inclusive Design Toolkit
- Google's Inclusive Design Guide
- W3C Web Accessibility Initiative
- Inclusive Components
- Accessibility testing tools
- Axe
- WAVE
- Lighthouse
- Screen readers (NVDA, VoiceOver, JAWS)
- Language linters for inclusive terminology
- Internationalization testing frameworks
- Contrast checkers and color blindness simulators
- Accessibility training courses
- Inclusive design workshops
- Bias awareness training
- Cultural competency resources
| Avoid | Use Instead | Context |
|---|---|---|
| Master/slave | Primary/secondary, main/replica | Database and system relationships |
| Whitelist/blacklist | Allowlist/denylist, permit/block | Security and access control |
| Grandfathered | Legacy status, previously qualified | Policy exceptions |
| Sanity check | Quick check, confidence check, coherence check | Testing and verification |
| Dummy value | Placeholder, sample, example | Test data |
| Native feature | Built-in feature, standard feature | Product capabilities |
| Crippled | Limited, restricted | Feature limitations |
- Consider multiple cultural and linguistic contexts
- Avoid terms with negative historical or cultural associations
- Use descriptive, functional language
- Test terminology with diverse reviewers
- Document reasoning behind terminology choices