These are the weekly notes for the 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) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Discussions of ticket #50699: Fix and improve arranging 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. boxes

We discussed Trac ticket #50699 that looks to limit the reordering of meta boxes to only when the Screen options panel is opened.

We raised a concern that removing the up/down buttons from meta boxes will likely affect users of assistive technologies, and will make it harder for someone using a keyboard to interact with this feature.

We agreed to test the patch and leave our feedback in the ticket.

Feedback con Twenty Twenty-One accessibility issues

We reviewed a couple of accessibility-related issues on the development repo of Twenty Twenty-One, the new default WordPress theme.

Consider removing the underline on the post titles to improve readability

This issue is suggesting to remove the underline on some links, particularly in post titles. Underlines can have a negative effect on the readability of text for users with dyslexia.

In light that the team behind the new default theme wants it to be as accessible as possible, we acknowledged that there is no one size fits all, and for now keeping the underlines seems to be the most widely accessible solution.

Our feedback was added to the issue.

Consider using the default focus outline style set by the browsers

Related to the previous discussion point, this issue is also related to link styles, in particular the style used for the focus state of links.

The issue suggest to remove the border style and use browser defaults instead. While we had added some alternative proposals to the issue, it seems that the default outline style is the best solution for now.

#meeting-notes

These are the weekly notes for the 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) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

It’s WordPress Accessibility Day 🎉

Today is WordPress Accessibility Day, a 24-hour global event dedicated to addressing website accessibility in WordPress. You can find out more about the schedule and sessions on wpaccessibilityday.org.

Progress report of the team’s goals for 5.6

We reviewed progress on the main team goals for WordPress 5.6:

1. Updating the WordPress Accessibility coding standards from WCAGWCAG 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/. 2.0 to WCAG 2.1 and document accessibility anti-patterns
2. Accessibility of the WordPress Twenty Twenty-One default theme
3. A feature plugin to create an “Accessibility Statement” tool with features equivalent to Privacy Policy Tools

Updating the WordPress Accessibility coding standards from WCAG 2.0 to 2.1

The team started work on the documentation but we are still pending on gathering examples of anti-patterns found across WordPress’ interface.

Please reach out if you want to help with this task.

Accessibility of the WordPress Twenty Twenty-One default theme

Folks behind the design and development of the new WordPress Twenty Twenty-One default theme have already been at work creating and addressing accessibility-related issues.

Some of these issue have proven to be complex and feedback is welcome. The team feels that we need to clarify our goal of having the theme be AA or AAA ready.

Accessibility Statement feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.

The pluginPlugin 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 is ready to be downloaded and testing help is needed.

Organize accessibility testing of the new Widgets screen

A call for testing the new Widgets Screen in Gutenberg 9.1 was posted earlier this week.

The accessibility team is planning and organizing a round of accessibility-related testing. The call for testing goes into detail on how to test and provides more details, but in summary, in order to test this screen you’ll need to:

1. Have a site using WordPress 5.5.
2. Make sure you use a theme that supports widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. areas (e.g. TwentyTwenty).
3. Go to the website’s admin.
4. Install and activate the 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/ plugin. If you already have it installed, make sure you are using at least Gutenberg 9.1.
5. Go to Appearance > Widgets.
6. Notice that it visually resembles the BlockBlock 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 now.

We welcome any help with testing the new Widgets Screen. Whether you can test for keyboard access, screen-reader support, or any other type of assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology, a few tasks you can test for are:

1. Navigate and have access to the whole interface
2. Add/remove blocks and 3rd party widgets
3. Move widgets around

If you’re specifically testing for keyboard access, please check that:

• any action can be performed easily with keyboard only
• the tab order is logical and meaningful
• there are no keyboard traps
• users are not forced to perform counterintuitive keyboard navigation to perform an action

Please open issues on the GitHub repository so these findings get addressed as soon as possible. In order to avoid duplication, we ask you to share in the #accessibility channel when an issue is created so everyone has awareness and follow along.

If you have access to add labels in the repository, the label we should be using for these issues is [Feature] Widgets Screen.

#meeting-notes

These are the weekly notes for the 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) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Accessibility review of toolbars in the blockBlock 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

We reviewed and discussed a few issues that introduce new editing functionality to the block’s toolbar. We agreed that replacing elements “on the fly” was not a recommended pattern. It unexpectedly removes elements from the DOM and can break expected interaction.

We support a solution currently being explored in this Gutenberg PR and will test it once the code is ready.

On-demand announcement to screen readers via a keyboard shortcut of the block’s contents

We also discussed this proposal on a Gutenberg issue that suggests providing a keyboard shortcut to allow screen reader users to hear the full contents of a block when triggered.

There are concerns about keyboard shortcut conflicts and of adding more shortcuts to an ever-growing list. There is one solution currently being explored on this issue in the Gutenberg repo that will allow users to customize keyboard shortcuts. We think that it might help alleviate these concerns.

We also discussed the possibility of adding a skip-link that will let keyboard users quickly jump to and find the list of available shortcuts. We think it’ll be useful to explore.

WordPress Accessibility Day

We were also reminded that WordPress Accessibility Day is next week, October 2nd, 2020 at 17:45 UTC. Make sure to add it to your agenda and the organizing team is still in need of volunteers.

#meeting-notes