WordPress uses several systems for tracking issues. Issues in WordPress itself are tracked in core ticket tracking. Issues with the network of sites at WordPress.org are tracked in the meta ticket tracker or in various independent repositories in the WordPress Github organization. Issues in the development of the block and site editors are tracked in the Gutenberg repository at GitHub.
Core Accessibility Tickets
- All open tickets
- All open tickets, grouped by workflow and sorted by component, type, summary
- Good first bugs
- Tickets with patches to test
Gutenberg Accessibility Issues
Gutenberg issues have two different labels.
- The
accessibilityfocus, representing issues that directly impact accessibility, and - The Needs Accessibility Feedback label, representing UX changes seeking feedback on accessibility.
Accessibility tasks
Tickets that are ongoing tasks because there’s the need to find instances, touch several parts of the code base, etc. They need to be split into separate tickets for each instance. Any help welcome!
These include general, broad, issues that either require substantial refactoring or exist broadly across many aspects of the admin. All tasks use the a11y-task keyword, so they can be located easily.
Contribute to a task
Accessibility tasks are long-term projects, and may be completed by one or several people. A task can be in many different stages. Usually, there’s a research phase, then a development phase. This may be repeated multiple times, depending on the scope of the task. In a research phase, you identify examples of the problem in core, document those problems, and open new tickets for each individual problem or small group of problems.
- Find a specific instance of a problem.
- Open a ticket for that instance.
- Add a comment to the tracking ticket with a link to the new ticket.
During the development phase, the open tickets are resolved. The ticket can be closed when you are unable to locate examples of that problem in core.
Accessibility keywords
Accessibility tickets grouped by topics. We use custom keywords to keep track of some main accessibility issues. To give some background about the progress so far, these reports show all the tickets, even the closed ones. Append &status=!closed to the URL to filter out the closed tickets.
- Color contrast
- Best practices for required fields in forms
- Use buttons for buttons, links for links
- Review usage of target=”_blank”
- Standardize the types of search in the core admin
- Use aria-current where appropriate
- Settings API improvements
- Proximity of related information and user interface controls
- Form controls improvements
If you find an accessibility issue in WordPress core, or in one of the core themes, please create a new ticket and give it the focus “accessibility”.