Accessibility for Plugin and Theme Developers

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.

Embeded Slides

Open on Google Slides

Slide Content

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”)

Testing Process

1. Run an automated bulk scanning tool to check
   for obvious accessibility problems. 
2. Manually test:
   1. With keyboard only
   2. With the website zoomed 200% and 400%
   3. With a screen reader
3. Resolve all issues from scan and manual testing.
4. Bonus: bring in screen reader users or other users with disabilities for user testing to confirm accessibility.

Automated Testing Tools

• Tiny Helpers
  • HeadingsMap Chrome, HeadingsMap Firefox
  • taba11y Chrome Extension
  • Colorblindly Chrome Extension
• WordPress Plugins
  • Equalize Digital Accessibility Checker
  • WP ADA Compliance Check Basic
• Single Page Scanners
  • WAVE
  • Deque’s Axe Free/Pro
  • IBM Equal Access Accessibility Checker

Screen Readers

• VoiceOver – built into Mac and Apple devices
  • Keyboard shortcuts for VoiceOver
• NVDA – open source, free, Windows only
  • Keyboard shortcuts for NVDA
• Jaws – paid screen reader

Important

Don’t forget accessibility in the WordPress admin and on your settings screens. 

Prioritizing Problems

1. “High”
   • 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.
2. “Medium”
   • 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.
3. “Low”
   • 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.

Backward Compatibility

Confront your fear of breaking changes – semantic HTML is always better than hacking in accessibility.

But… there are options:

• Accessible Rich Internet Applications (ARIA)
• JavaScript event handlers

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