If you’re coming here from a link I’ve shared, WordCamps are conferences for WordPress. I’m very involved in the WordPress events community, so I wanted to highlight some ways for our events to be more accessible for people with disabilities.
In the past year or so, web accessibility has finally been getting the attention it needs. Last year, afercia was granted commit to WordPress core based on his accessibility work. The WordPress Accessibility team has put together standards for core development to ensure future features are accessible. Almost every WordCamp had at least one presentation on why accessibility (or a11y) is important and how to get started.
I would love to see this same attention paid to accessibility at our WordCamps and meetups.
A quick story: At WordCamp US, I took refuge in the quiet area for a while one afternoon. While I was sitting there, a few other people came through and sat on the other side of the space. I never got their names, and for the most part didn’t pay any attention to them. As I was leaving, I caught a little of their conversation. They were talking about the event so far, and one woman mentioned that she was new to WordPress (or maybe new to development), but was hoping to learn a lot more here; that our industry would provide her new job opportunities, because she couldn’t move around very well, and with WordPress, she could get a job working from home.
Considering that the unemployment rate for people with disabilities is twice that for non-disabled people, the fact that our community can provide employment opportunities that work where “traditional” jobs fall short is great. However – if our events are inaccessible, how will new people learn about all the things they can do?
The other week I started playing with a React-based theme using the REST API. The idea is a very simple recipe blog – no comments, no widgets, just a list of post titles on the home page and a pop-up card with the recipe content. Designed by Mel Choyce (of course), the inspiration was vintage recipe cards/books. It seemed like a great candidate for a single-page-app style theme.
The theme is called Anadama, and it’s definitely still a work-in-progress. Here’s how it looks so far:
A single recipe page shows the recipe meta from the (Jetpack) shortcode in the left column.
A list of all posts by category.
The single page view (inheriting the sidebar gap from posts, will probably be updated)
Want to check it out?The Anadama-React github repo has instructions to set it up yourself, you’ll just need a few plugins: The REST API for the content API, WP-API Menus for the menus endpoint, and (optionally) Jetpack, if you want to see the recipe shortcode in action. The theme will work with any content, but only recipes will populate the sidebar.
Look for me at WCUS if you want to chat about React/API-driven themes, using Jetpack for themes, or themes in general! 🙂
Edited 12/9: If you’re interested in a more traditional blog example, I’ve also added Foxhound to github. I’m working on both, and will write an update in a week or so about the progress on both.
If we tell people that they don’t need to be expert developers to review themes, and that this is a good way to learn better coding practices, why don’t we do the same with design? Good design is just as subjective as code standards (in that the basics aren’t, but people like to argue about it anyway).
The quality of code in the theme repo is improved by the review process, so we should encourage design reviews to increase the quality of design, too.
Some suggestions: fill out the design guidelines in the theme review handbook (maybe with a “how to give feedback” section), then encourage designers to review themes, without worrying about doing the full code review – not all designers are or want to be developers. Publicize that this is something people can do, and it’s still contributing. Encourage people who might not be comfortable with giving design feedback to “self-report” a usability test- write out what they were thinking while activating & setting up a theme.