Think about Universal Design for FOSS community experiences, not just products.
If I asked a random FOSS community member whether they'd like more people to use the software (or content, or hardware, or whatever) they work on, I'm pretty sure most people would squint at me funny and say some variant of "yes" or (if they're blunter) "duh." And also I think most of us acknowledge accessibility is a Good Thing That Can Help With That -- possibly a good thing we don't have resources to implement, but a good thing nonetheless -- and applaud efforts like GNOME's that are directly working on making "FOSS things" more accessible to the less-privileged (most commonly thought of as "the disabled," but really extensible to just about everyone). This is called Universal Design, and it is...
"...the design of products and environments usable by all people, to the greatest extent possible, without the need for adaptation or specialized design." --Robert Mace (emphasis mine)
Now, we create things, but we also create experiences -- and one of those experiences is the experience of becoming one of us, a contributing member of the project community (which I believe most FOSS contributors would also like more of in their projects). Our communities are an environments. What would it look like to expand our thinking from "accessibility of product is good!" to "accessibility to contribution process is good!"? I've been reading about Universal Design for Learning, an adaptation of Universal Design geared towards the design of learning experiences, and it's got some heuristics that might be useful to consider. I've adapted the list below is from Sheryl Burgstahler's Universal Design: Principles, Process, and Applications.
- Equitable. The community is useful and marketable to people with diverse abilities. For example, a project that specifically calls for help with documentation, art, testing, etc. and other things beyond code and system administration. It's made clear that interest and willingness to learn are the most important things, not a PhD in CS -- come in and we'll teach you much of what you need to know to get started helping out.
- Flexibility. The community accommodates a wide range of individual preferences and abilities. Mailing lists where language minorities can converse in their native tongue. Holding in-person getting-started events to bootstrap folks who are nervous about getting the etiquette of online communication wrong.
- Simple and Intuitive. How to start participating in the community is easy to understand, regardless of the newcomer’s experience, knowledge, language skills, or current domain of expertise. Having suggested default settings in "how to join this team" instructions, the same way most installers nowdays have a recommended default setup that advanced or adventurous folks can change.
- Perceptible Information. The community communicates necessary information effectively to the contributor, regardless of ambient conditions or the user’s sensory abilities. A common example in most communities is "if it's not on public mailing list X, it didn't happen" -- phone calls, hallway conversations, and even (in some cases) IRC meetings should be captured somewhere everyone can look at them.
- Tolerance for Error. The community culture minimizes hazards and the adverse consequences of accidental or unintended actions. A safe place for newcomers to ask even the "silliest" questions -- a place that's actually maintained and responded-to by respected, established community figures instead of becoming a ghetto of ignorance. A cultural habit of encouraging and applauding genuinely curious attempts that go wrong instead of responding with a "how could you be so stupid as to try X?" tone. The practice of teaching newcomers how their actions can be made reversible -- the notion that you can revert wiki pages, roll back code in a version control system, etc. and that this is No Big Deal. Being bold often requires the confidence that you won't irreversibly screw anything up.
- Minimal Activation Energy (originally "Low Physical Effort" for things like automatic door openers). The community's processes can be used efficiently and comfortably, and with a minimum of fatigue. Integrated logins across a project's infrastructure. Not making people sign into 4 different accounts and make 20 mouse-clicks in order to vote for a board. The option to subscribe to notifications of one's choosing.
- Space for in-person participation. At in-person gatherings, size and space is provided for approach, reach, manipulation, and participation by community members of many sizes, postures, and mobility considerations -- including the ability to be there in person at all. Live collaborative notetaking during meetings, childcare at conferences, choosing wheelchair-accessible buildings for events whenever possible, projecting IRC channels into a live space so remote members can have a visible voice.