These are the weekly notes for the Make WordPress 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) Team meeting, that occurred Friday, 17:00 UTC. You can read the entire transcript on our Slack channel and view the Meeting Agenda here. The meeting begins after the conclusion of the bug scrub, a welcome to new attendees, and rules for a family-friendly meeting.
Update from Working Groups
As usual, we had a round of updates from the various working groups inside our Accessibility team.
Design Team news was shared by @shaunandrews, listing some tickets and issues on Trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. and GitHub 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 be the repository owner. https://github.com/ which might benefit from review from the team:
Ticket 54270 – About Page for 5.9 Release;
Ticket 54489 – Update the Dashboard Welcome Banner for 5.9;
Issue 37067 – Panel Color Gradient settings to use dropdowns; and
Issue 37075 – Load the template list in the site editor without page reloads.
@joedolson suggested that the priority should probably be the About Page for 5.9. Also, volunteers were requested to review these issues so that they’ll be handled. Joe volunteered for the Welcome screen update and possibly the About Page. @alexstine subscribed to the template selection issue to track its progress.
@azhiyadev provided the update for the Documentation Team. During the week before the meeting, she had a further look at the handbook, checking for WCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. versions referred to and updating broken links. She asked a couple questions.
Should the handbook be converted to using the block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor?
In terms of 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 recommendations, are there any concerns regarding plugins that haven’t been tested with the latest version of WordPress? An example of one that is recommended is WP Libre Forms (referred in the handbook and tested up to WordPress 4.8.17).
Regarding the use of the block editor for the handbook, @ryokuhi expressed an opinion that we should stick with the classic editor for the handbook, as Gutenberg 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/ is still difficult to use for people with disabilities (in case editing is needed by those using assistive technologies). @shaunandrews added that having more people use the block editor and report any accessibility issues is the best way to improve the experience.
Regarding recommended plugins, those that haven’t been tested at least with version 5.7 should be removed. Joe is really uncomfortable recommending anything that shows evidence of being abandoned in the repository. This section needs to be updated desperately.
Also, @azhiyadev asked if there were any recommendations for web forms plugins to be listed in the handbook. Contact Form 7 or Gravity Forms were suggested by @joedolson, but additional clarification was needed (regarding whether Gravity Forms’ WCAG 2.0 form field plugin is still needed). Finally, we should indicate that we have not conducted a full accessibility audit on these recommendations.
At the moment there aren’t any accessibility tickets milestones for 5.9. For the news, 28 tickets milestoned for 5.9 will be included in the next release.
This team has finished off quite a bit and is now planning for 6.0. Planning includes preparation for updating the search and filtering options in the Media Library.
@sabernhardt reported that Twenty Twenty-Two has an h1
related issue (Issue 233). @joedolson will comment on the issue and @ryokuhi stated we’ll probably need to discuss this issue again in the future to see if a review of the Accessibility-Ready guidelines is required.
There will only be a bug scrub on December 10th and our next team meeting will resume December 17th, our last gathering of 2021.
A reminder that WordPress Accessibility Day returns in 2022 and the first organizational meeting for this event kicks off December 16th. DM @joedolson for more details and an invitation.