As outlined in a recent post on the accessibility team blog, enhancing the Settings API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. is currently a high priority for the team. We have been working on this project for a couple months now, discussing goals and approach in a biweekly meeting on Mondays at 16:00 UTC. The main objectives have been to improve accessibility 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) of the pages generated with the Settings API as well as making it easier to use and more flexible for developers. Over the time we have identified the following list of areas to work on:
- The HTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. table layout that has been present for most admin (and super admin) pages should be replaced with a modern, semantically more accurate markup. As the entire table markup is created by the Settings API, we should be able to change it without major backward-compatibility concerns.
- We’d like to investigate moving from the current two-column layout to a one-column layout, as we agreed on that it would provide a more streamlined experience and overview. Furthermore the two-column layout makes it hard if not impossible to use
fieldset (and legend) to group elements properly.
- For common fields used in Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and plugins, such as a simple text field, textarea, dropdown, radio or checkbox, default callbacks should be provided so that developers do not need to write every callback for such simple UI User interface components themselves. These callbacks should be flexible and accept a standardized set of arguments that can be passed to
add_settings_field(). Furthermore each callback should provide accessible markup out-of-the-box, so that even plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party settings pages can be made accessible easily.
- Eventually all settings pages that Core creates should be using the enhanced Settings API instead of rendering their markup manually. This ensures a more structured output and allows developers to modify the Core fields as well.
- It should be a high priority to create a set of standardized patterns for class names, markup and design. Elements that need to be targeted in JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. must have classes used explicitly for that purpose only.
- All markup we create should be generalized enough to not be specific to only the Settings API pages. Several other pages in the admin, for example the user profile or term editing pages could benefit from the improvements as well once they are polished.
This list may possibly be extended at some point, as there were some discussions about further developer-centric improvements, but for now we would like to focus on producing a clean and accessible markup with a better DUX being a side product of these efforts.
Prototype for WCEU
After starting development through patches on #39441, we soon realized that this project would be better off as a separate plugin. Therefore we created a GitHub repository for the project, where all development happens now. The plugin uses prefixed functions to not interfere with Core’s own Settings API, so it can safely be tested. While working on the layout, we identified the need for thorough user tests of the changes, and we set the upcoming WordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe as our target to get a first testable version of the plugin ready. While we still need more time to get to the point where we can propose it as an actual feature plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., we would like to get feedback sooner than later to uncover eventual pain points.
We will be starting next week to discuss what needs to happen to get that prototype finished in time. If you’re interested, please attend the meeting, which will take place on Monday 16:00 UTC on Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. in the #core channel, or leave a comment on this post if you cannot make it.
cc @afercia, @rianrietveld, @joedolson, @karmatosed, @johnbillion, @sc0ttkclark
#accessibility, #settings
