These are slides and notes from Amber Hinds’ 2023 WordCamp Phoenix presentation, Accessibility for Plugin and Theme Developers. Below you’ll find embedded Google slides and also the content from the slides.
If you have questions about this presentation, tag @HeyAmberHinds on Twitter, or you can find Amber on Mastodon.
If you enjoyed this talk please consider attending a WordPress Accessibility Meetup. Join our email list to get notified of upcoming events.
How many people use your products?
Screenshot of a post in the WordPress Accessibility Facebook Group where Anita Carter asks:
Since the WordPress themes market is huge (inside WordPress themes directory and out in the wild), there are probably 100s of thousands of themes (new and old) that are not accessible out the box. Most people who buy these are not developers. They are just the average end-user. They build their sites and use those templates “as-is”. Color, fonts, font sizes, etc. Or there may be missing skip links, structure issues. Once they have their sites built, they may decide to check for accessibility and there in lies the issue – they may not score well which means they need to resolve it right? Question: Whose responsibility is it to “fix” these? I can see where maybe moving forward theme designers would run their own products through accessibility tools so that they meet a certain level of the standards, but how much responsibility lies on the theme designer for making their products accessible-friendly. And since accessibility is a huge talking point now, should theme designers offer tools to help customers get to the “rest of the way” after they’ve added their own content.Anita Carter
You have the power to make the web more accessible.
Getting Started with Accessibility
- Learn HTML deeply and commit to only using semantic HTML.
- Look for training resources and webinars.
- Turn off your mouse and use your products with only a keyboard.
Most Common Problems
- Low contrast text or UI elements
- Empty links or buttons
- Elements that should be a <button> but are coded as something else (<div>, <span>, <a>), etc.
- Missing form labels
- Headings used out of order or improperly for styling purposes
- Ambiguous links or buttons (“read more”, “add to cart”)
- Run an automated bulk scanning tool to check
for obvious accessibility problems.
- Manually test:
- With keyboard only
- With the website zoomed 200% and 400%
- With a screen reader
- Resolve all issues from scan and manual testing.
- Bonus: bring in screen reader users or other users with disabilities for user testing to confirm accessibility.
Automated Testing Tools
- Tiny Helpers
- WordPress Plugins
- Single Page Scanners
- VoiceOver – built into Mac and Apple devices
- NVDA – open source, free, Windows only
- Jaws – paid screen reader
Don’t forget accessibility in the WordPress admin and on your settings screens.
- Functionality defects/critical failures that make it extremely difficult or impossible for users with disabilities to use the tool.
- Should be considered a blocker to the deployment of code.
- Have a significant impact on useability but may exist in a less business-critical part of the website or can be navigated with a workaround in the user’s assistive technology.
- Doesn’t block users from using the tool or website but would improve the user experience overall.
- Best practices rather than WCAG failures.
Referencing Web Content Accessibility Guidelines is ideal, but don’t let it overwhelm you.
Even small fixes can make a big difference.
Confront your fear of breaking changes – semantic HTML is always better than hacking in accessibility.
But… there are options:
- Accessible Rich Internet Applications (ARIA)
See example of making span a button.
Make it User Proof
Add instructions and guidance in the admin for your users.
Shout out to Gravity Forms.
WordPress Accessibility Meetup
Live Captioned on Zoom
- 1st Thursday at 10 AM CDT
- 3rd Monday at 7 PM CDT