Stefano Minoia 3:00 pm on August 25, 2020
Tags: 5.6 ( 2 ), goals ( 3 )

Accessibility Team’s goals for WordPress 5.6 and beyond

Following a pattern established during the last WordPress releases, it has become common for the WordPress 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 to set targets for each release during the final stages of the previous one.

Given the heavy involvement of the Team between 5.5 RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1 and the 5.5 release, it was impossible to discuss possible goals before. Also, given that the kickoff meeting for WordPress 5.6 took place on Wednesday, 19th August, this discussion can’t be delayed anymore.

As such, the Accessibility Team is going to discuss possible targets for WordPress 5.6 during the next weekly meeting, which will take place on Friday, 28th August, 2020 at 15:00 UTC.

If you have an accessibility goal you would like to see the team pursue on WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., you are more than invited to add it in the comment section below and let us know. You are then invited to attend to the next weekly meeting, when possible goals will be discussed and prioritized.

If a certain goal won’t be selected for the 5.6 release, it can always be included in the list that will be created for the 5.7 release.

While a strict timeline can’t be set too many months in advance, the next Call for Accessibility Team’s goals will likely be published around Friday, 13th November, 2020, that is, the Friday before WordPress 5.6 RC 1. Possible goals will then be discussed during the weekly meeting on Friday, 20th November, 2020. Around the same time, an extra bug-scrub to identify possible good-first-bug Core tickets and 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/ issues will take place.

All the above dates are flexible and can be changed according to specific needs, in particular in case they run the risk of detract from bug fixing during Release CandidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge..

Such an early planning will probably become even more useful with next releases, given that four major WordPress releases are already planned for 2021 and each release cycle will be shorter. Planning in advance possible goals during Release Candidate will also allow contributors to have a break in between releases, reducing possible sources of burnout.

#5-6, #goals

sarahricker 3:40 pm on August 25, 2020

Hey everyone! In case you haven’t heard, I will be acting as the 5.6 a11yAccessibility 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) Release LeadRelease Lead The community member ultimately responsible for the Release. along with cohort Hauwa Abashiya (@azhiyadev). I am SO EXCITED to help make this the best, most #a11y focused release ever! If there is anything I can do to help along the way, please don’t hesitate to reach out!

On that note, I’ll kick off our goal planning list with a few ideas I’ve been collecting from recent 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/. Conversations, posted individually below. Please add your support to any you would like to see included in 5.6, or, add your own! All ideas are welcome here!
sarahricker 3:56 pm on August 25, 2020

Project: 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

As the first few drafts of WCAG 2.2 have already been published, and there is still some support left to accomplish to meet 100% of WCAG 2.0, the goal here is to move towards supporting all of 2.0 and as much of 2.1 as possible to avoid falling too far behind.

For reference: What’s new in WCAG 2.1

Per @joedolson, the following is an outline of proposed first steps for this project:
1. Simplified explanations of the new WCAG 2.1 AA criteria
2. Examples of either existing bugs that violate said criteria or external examples, if none found from within project.
3. General update of existing code standards documentation to incorporate new standards.
4. Review of existing 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)-related documentation to incorporate references as relevant.
5. Update Accessibility team handbook to add WCAG 2.1 criteria.

So far, the following a11yAccessibility 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) folks have already pledged their support. Join us!
@joedolson, @nrqsnchz, @azhiyadev, @williampatton and @sarahricker
- Jb Audras 4:03 pm on August 25, 2020
  
  Support pledged as well 🙂
  - sarahricker 4:14 pm on August 25, 2020
    
    Nice! 🙂
- Enrique Sánchez 10:40 pm on August 25, 2020
  
  +1 that this should be one of our priorities for this release
Jb Audras 4:02 pm on August 25, 2020

Hey team!

On my side, I’d like to extend the first pass we made on Alternate views for WP list tables during WP 5.5. My goal is to add more extensibility to the current implementation, and more useful stuff for users as a result of the “extended” option.

And, of course, fix all the bugs 🐛 😎
sarahricker 4:06 pm on August 25, 2020

Project: Mechanism for Accessible Tooltips in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
The need for a11yAccessibility 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) tooltips is a concept that comes up a lot in 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/.. The goal here is identifying all of the tooltip needs, resolving existing issues, and determining a mechanism to keep our tooltips accessible going forward as new features are developed across the editor.

Some existing tickets already exist re: a11y tooltips, for example: https://core.trac.wordpress.org/ticket/51006

@joedolson for more info.
sarahricker 4:11 pm on August 25, 2020

Project: WP 2021 theme – the most a11yAccessibility 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) theme ever released!

It sounds like a new theme may be on the roadmap. The goal here is to aid the themes team as much as possible to create the most accessible theme ever released by our amazing community.

Hoping to shoot for the stars on this one. Dare I say, “A theme that passes 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.1 AAA“?

@williampatton, @poena for more info
- Mel Choyce-Dwan 6:23 pm on August 25, 2020
  
  Would love to chat more about this!
Zebulan Stanphill 6:02 pm on August 25, 2020
I’d like to see a solution found to the current dilemma of 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. toolbar space issue. So much of 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) issues are a result of trying to cram multiple things into a small space:
- The block switcher doesn’t use an appropriate “switcher”/”transform” icon, but rather the block icon. This also means there’s no place to put the current block title in a tooltip, so to find out what block you’re editing, you have to look in the inspector. This is not good, if you ask me. Ideally, the block icon would be a separate thing with a tooltip/aria-label stating the block title. (I think the title is already announced to screen readers, so this would mainly benefit sighted users.)
- The movers are stacked, causing their buttons to be half the standard size, and appearing at first glance as if they were a single button. This is not ideal for touch usability, and it’s also somewhat confusing.
- There is no visible drag handle. Instead, dragging the mover buttons initiates a drag action. This is perhaps the most problematic issue, as many users have assumed that drag-and-drop has simply been removed.
All of these issues can’t be solved via current methods unless the toolbar gets longer. So there’s a lack of available space, and no immediately apparent solution in sight.

The only thing I’ve been able to come up with is a possible “toolbar-replacement” idea, where clicking a button in the toolbar replaces the contents with a sort of “sub-toolbar” containing controls specific to a certain type of action, e.g. block movement. (And of course, there would be a button to get back to the main toolbar.)

This idea could be used to have a dedicated sub-toolbar for things like:
- block movement (up, down, move to top, move to bottom, drag handle, “move to…” (currently in the ellipsis menu))
- standardized block-level styling (text alignment, background color, text color, block “alignment”, item/content alignment, maybe even the style variations could be moved here); this could provide a standardized place for all the various block-level styling controls, without having to put them in the inspector for some blocks but not others
If such a thing could be done in an accessible way, it may be able to solve this growing toolbar space issue. But if not… well, I have no other ideas. But this is a critical point of friction between the accessibility and design teams, and I think it ought to be resolved sooner rather than later.
- sarahricker 6:29 pm on August 25, 2020
  
  I’m 100% behind finding a good solution for this!
  
  A lot of different ideas have been discussed over the past few weeks. Perhaps some high fidelity / interactive design mock ups for each idea paired with details regarding the pros/cons of each would help visualize each solution proposal. As a joint team, we could then vote on a path forward and commit to having that solution be part of the 5.6 release.
  
  I can also help facilitate an extra weekly design + a11yAccessibility 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) check-in where we discuss progress on this very important topic if that helps! 🙂
  - Zebulan Stanphill 7:29 pm on August 25, 2020
    
    I’ve opened an issue to discuss this problem. Please do share it during the meetings.
    
    https://github.com/WordPress/gutenberg/issues/24805
DDeacon 11:51 am on August 26, 2020

I’d like to see the removal of the title attribute from nav walker menus. Creates repetitive screen reader announcements for some screen reader/browser combinations. From what I hear, this has been on the docket for some time now.
- Hareesh Pillai 7:52 am on September 13, 2020
  
  A ticket has been created to track this change: https://core.trac.wordpress.org/ticket/51300
sarahricker 9:45 pm on August 26, 2020

Project: A feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. to create an “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) Statement” tool with features equivalent to Privacy Policy Tools

Goal here is to help educate and spread awareness on Web Accessibility through an open ended and optional feature similar to the the existing Privacy Statement feature. Early ideas for the tool are to provide the W3C “minimal example”, and to encourage the site owner to use the W3C Generator for a more custom statement.

Ideally this would start as a feature plugin, and if it gained traction, could be merged into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in a future release.

See the original proposal from @mrwweb and a summary of #a11yAccessibility 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) meeting notes here: https://core.trac.wordpress.org/ticket/50673
Andrea Fercia 11:22 am on August 27, 2020

From a practical perspective (as in: not “higher level goals”) worth reminding there are a few important tickets from the previous release cycle that didn’t make it for 5.5 and need to be prioritized for 5.6. First of all:

Remove infinite scrolling behavior from the Media grid
https://core.trac.wordpress.org/ticket/50105
together with the related tickets:
https://core.trac.wordpress.org/ticket/50410
https://core.trac.wordpress.org/ticket/50025
https://core.trac.wordpress.org/ticket/46127
https://core.trac.wordpress.org/ticket/47215

Secondly: the Trac tickets we asked help from other teams:

For the Editor team:

Allow Ctrl+Y redo in post editor
https://core.trac.wordpress.org/ticket/49459
Featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. is missing ‘Alt Attribute’ value on the edit window
https://core.trac.wordpress.org/ticket/49651 also reported on 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/ GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/: https://github.com/WordPress/gutenberg/issues/14416

For the Media team:

Fix crop image functionality within edit flow
https://core.trac.wordpress.org/ticket/30155
Media modals: Upload errors and field information are not associated with their control
https://core.trac.wordpress.org/ticket/47120
PDF uploads are treated like images: empty alt attribute and PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. notices
https://core.trac.wordpress.org/ticket/48710

Lastly, there are at least three important Gutenberg issues the team identified as regressions in 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) level in WordPress 5.5 that still need to be addressed:

Accessibility regression: The selected 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. isn’t outlined any longer
https://github.com/WordPress/gutenberg/issues/23892

New buttons design: buttons can’t be visually identified as user interface controls
https://github.com/WordPress/gutenberg/issues/23890

Accessibility regression: Firefox and NVDA don’t announce the blocks in navigation mode any longer
https://github.com/WordPress/gutenberg/issues/24121
where a temporary, not ideal, fix was implemented for WordPress 5.5 but this issue needs a better solution.
Andrea Fercia 3:29 pm on August 27, 2020
Some more “high level” goals 🙂

Recruiting campaign
One of 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 historical problems is that it’s a small team 🙂 The team has always been struggling with the lack of time and contributors. Also, 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/ development pace creates new challenges. In the past, the team made some efforts in involving new contributors but recently the focus went a bit lost.

On one hand, Gutenberg poses complex challenges and there’s the need for high level specialists with advanced accessibility expertise. On the other hand, there are many pending tasks that the team isn’t able to complete and that would need new contributors willing to bring in new energies.

It would be greatly beneficial for the team and for accessibility in WordPress to make this a constant effort from now on.

Document accessibility anti-patterns
I don’t think the accessibility team should ever produce documentation on how to code accessible components and accessibility best practices. Plenty of documentation out there. It’s 2020 and I’d expect designers and developers to be able to get trained and learn HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. and accessibility deeply.

Instead, I’d tend to think it would be beneficial for WordPress that the accessibility team documents and explains what are the most common accessibility anti-patterns identified in the last years, especially thinking at the Gutenberg project.

Some examples:
- parts of the user interface that continuously appear and disappear
- visual/reading order and DOM order mismatch
- lack of good information architecture (linearization of content)
- icon-only controls
- lack of good focus indication
Make keyboard testing a required step of the development process
Start a conversation with the other teams to make basic keyboard accessibility testing a required step for any change and new feature in Gutenberg and in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

Especially thinking at Gutenberg: most of the accessibility regressions identified right before the 5.5 release could have been caught way in advance if the related features were tested _a few minutes_ using a keyboard. Looking at those specific issues, it’s pretty clear to me that most of them were very visible when using a keyboard. The fact they haven’t been caught timely makes me think that most of them haven’t been tested for keyboard accessibility at all.

I don’t think this is an efficient process. In order to fix as many of those regressions as possible, the involved teams had been forced to a final rush that implied creating new issues, new PRs, testing, etc. and that has been stressful for all the ones involved. Not to mention the amount of time spent to fix all that.

Testing keyboard accessibility while developing and making it a required step to merge PRs would save a lot of time and make everybody happier.

I’d like to strongly recommend to make an effort to come to a consensus and make keyboard testing a required step for all the Gutenberg and core changes that touch the user interface.

Dogfood the Gutenberg 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
As said above, the Gutenberg development pace is challenging and for many team members following closely the development is not sustainable. The accessibility team has their own responsibilities though. I often noticed that, while discussing accessibility issues related to Gutenberg, not all the team members had a clear picture of the issue being discussed.

Far from pretending to ask anyone to follow the Gutenberg development on a daily basis, but I’d tend to think the team members should make an effort and at the very least always use the Gutenberg plugin (the development one, cloned from the GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/ repo). This way, all the team members would be able to test new features as soon as they’re introduced in Gutenberg and provide feedback in a more efficient and timely way.

We’re not going to make a great progress if only one or two persons from the team dedicate their time to monitor and contribute to Gutenberg 🙂 Making this a team effort would certainly speed things up and contribute to make Gutenberg a better, more accessible, product.
Pingback: Accessibility Team Meeting Agenda: August 28, 2020 - Xiphos Web Marketing
Stefano Minoia 3:00 pm on August 28, 2020
To keep track of them, I’d like to add for consideration projects that were considered or worked on during the 5.5 release cycle and that didn’t land.
- Accessible color schemes: provide new accessible color schemes for wp-admin (worked on during 5.5)
- “Howdy fly-out menu”: refine/replace the upper-right WP-Admin fly-out menu (worked on during 5.5)
- Uniform search: redesign of the search for wp-admin (already milestoned for 5.6)
- wp-admin colors: reviewing wp-admin default color scheme for 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) (not milestoned)
Pingback: News – The Month in WordPress: August 2020 – WordPress.org
Pingback: News – The Month in WordPress: August 2020 – WordPress.org - Rojak WP
Pingback: News – The Month In WordPress: August 2020 – WordPress.org | PlanYour.Website
Pingback: The Month in WordPress: August 2020 | Make Chico
Pingback: The Month in WordPress: August 2020 - I'MyBoss
Pingback: The Month in WordPress: August 2020 – 지락문화예술공작단
Pingback: The Month in WordPress: August 2020 – WPHelp
Pingback: The Month in WordPress: August 2020 - WP Epitome
Pingback: The Month in WordPress: August 2020
Pingback: The Month in WordPress: August 2020 - I am a Website Builder
Pingback: The Month in WordPress: August 2020 | wp-includes
Pingback: The Month in WordPress: August 2020 - Sai Chand's Portfolio
Pingback: The Month in WordPress: August 2020 | HackFence Manages WordPress Security Service
Pingback: Ike.ninja » The Month in WordPress: August 2020
Pingback: Presentamos Twenty Twenty One | WordPress.org Venezuela

Comments are closed.

WordPress.org

Share this: