Test: Test for Accessibility

Function: Test
Type: Task
Level: Beginner

You’ll find accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) tickets, test them using your keyboard, browser tools, and optionally a screen reader, then report your findings. Every test result helps the Accessibility team identify and fix barriers that prevent people with disabilities from using WordPress.

Before you start

Complete the common setup first, then:

Setup: Install the axe DevTools browser extension. Your keyboard and axe DevTools are enough to start — screen reader testing is covered in step 4.
Read: Read through the Test for Web Accessibility handbook page. The goal is familiarity, not mastery.
Connect: Join #accessibility on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ and introduce yourself.

Steps

Find a ticket to test from the Tickets, Tasks, and Reports page — start with good first bugs or tickets with patches on Core Trac, or Needs Accessibility Feedback issues on GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. If the lists feel overwhelming, ask in #accessibility.
Keyboard test. Put your mouse aside. Use Tab/Shift+Tab to navigate, Enter/Space to activate, arrow keys inside menus. Check that you can reach every interactive element, see where focus is, operate everything without a mouse, and escape modals. See the Keyboard navigation testing guide.
Automated scan. Open DevTools (F12), go to the axe DevTools tab, and click “Scan All of My Page.” Note issues relevant to your ticket. Automated tools catch ~30% of issues — they’re a starting point, not a complete test.
Screen reader test (optional, but where the team most needs help). Navigate the page with NVDA (Windows) or VoiceOver (built into Mac) and check roles, reading order, alt text, and form labels. See the Screen reader testing guide.
Report your findings. Add a comment on the ticket with what you tested, how you tested (tools, browser, OS), and what you found. Include steps to reproduce and screenshots where possible. See the Reporting Issues handbook page. For new issues, file on Core Trac (Focus: “accessibility”, Type: “defect (bug)”), Gutenberg GitHub, or Meta Trac depending on where the issue lives.

Contribution checklist

Tested against a specific ticket or issue using at least one testing method
Report includes what you tested, how you tested (tools, browser, OS), and steps to reproduce
Report posted in the right place (CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/., Gutenberg GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/, or MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. Trac)
New tickets filed with correct Focus and Type

What happens next

Watch the ticket for responses from the team. Address any questions and verify the fix once it’s applied. If you don’t hear back within 2–3 weeks, post in #accessibility.

As you gain confidence, expand your testing methods and check the Current Release Progress page for active work. Joining accessibility bug scrubs in #accessibility is a good way to learn and find tickets. Contributing can earn you a profile badge.