Wayback Machine
Aug SEP OCT »
Previous capture 30 Next capture
2019 2020 2021 »
0 captures
30 Sep 20 - 6 Nov 21
Close Minimize Help

WordPress.org

The Accessibility Team provides accessibility expertise across the project to improve the accessibility of WordPress core and resources.

The WordPress Accessibility Coding Standards state that “All new or updated code released in WordPress must conform with the Web Content Accessibility Guidelines 2.0 at level AA.

For questions or support related to WordPress & accessibility, please visit the WordPress Accessibility forum.

Learn how to design, develop, and write accessible code in our Handbook – best practices.

Make WordPress Accessible

Keyboard Shortcuts | Hide comment threads

Accessibility Team Meeting Notes: September 25, 2020

These are the weekly notes for the 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 block 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, Friday, October 2, 2020 at 05:45 PM UTC. Make sure to add it to your agenda and the organizing team is still in need of volunteers.

#meeting-notes

Accessibility Team Meeting Agenda: September 25, 2020

This is the proposed agenda for the weekly Accessibility Team meeting on Friday, September 25, 2020 at 03:00 PM UTC.

If you want to have a topic added to the agenda, please mention it in the comments of this post.

The Accessibility Team bug scrub will be held on Friday, September 25, 2020 at 02:00 PM UTC.

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

#agenda

[…] These are the weekly notes for the Accessibility Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here. […]

[…] These are the weekly notes for the 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 Team Meeting Notes: September 18, 2020

These are the weekly notes for the Accessibility Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Update on WordPress 5.6 goals

Updating coding standards to WCAG 2.1

The team quickly discussed about the formulation of the WordPress accessibility coding standards.

All new or updated code released in WordPress must conform with the Web Content Accessibility Guidelines 2.0 at level AA.

As it doesn’t imply the Community needs to revise the entire WordPress codebase before upgrading from WCAG 2.0 to WCAG 2.1, the team agreed that the first step could be to simply change the number. Such change would be matched by a post on the Make blog with a quick explanation about the implications of such a change. @joedolson opened a pull request on the WordPress Coding Standard repository to upgrade to WCAG 2.1.

The scope of accessibility related documentation will be broadened and will include:

  • an introduction about accessibility guidelines, including links to normative and informative resources by the Web Accessibility Initiative of W3C;
  • a list of authoritative resources (in line with the indications from the documentation team about the external linking policy);
  • a list of anti-patterns that should be avoided inside WordPress;
  • a list of patterns that should be followed inside WordPress;
  • (optionally) a guide to test patches for accessiblity issues before merging.

Discussion about the new accessibility coding standards can continue in the #accessibility-docs channel in the Making WordPress Slack (requires registration); feedback can be added to the new accessibility coding standards draft and to the new accessibility testing guide draft.

Twenty Twentyone

Development of the new WordPress default theme is ongoing. A discussion about the links style happened during and after the meeting in a thread on Slack, the menu hasn’t been worked on yet.

The GitHub repository for Twenty Twenty One was made public in the week after the meeting and some members of the team are working on it and looking for possible accessibility issues.

Accessibility statement feature plugin

Developement of the accessibility statement plugin is underway. As reported by @sarahricker, at the moment there are two versions of the plugin.

  • The first version generates an accessibility statement using the exact same questions from the W3C accessibility statement generator and stores answers in the WordPress database, so that the statement can be regenerated with ease every time it needs to change.
  • The second version (which is currently at a Minimum Viable Product stage) aligns more closely with the acceptance criteria and mimics the Privacy Policy functionality currently in core.

The accessibility statement plugin repository is public and all people interested can give their contribution.

Gutenberg project board

A couple of days before the weekly meeting, the WordPress 5.6 milestone in the Gutenberg repository was deleted in favor of a GitHub project to track WordPress 5.6 must haves and all issues in the milesone have been moved to the new board.

To ease the workload from the few team members with triage status in the Gutenberg repository, the team agreed to ask those permissions for @sarahricker, @joedolson and @ryokuhi, given that they are already bug-gardeners or committers to WordPress core.

Sidebars accessibility in Gutenberg

Following last week’s discussion, further considerations about sidebars in Gutenberg were made. Here is a summary of the key points.

  • A sidebar is a layout model, not an interaction one: an element can be described as a “sidebar” because of its visual aspect, but not because of how users interact with it. A direct consequence is that there is no suitable, expected, semantic pattern that can be followed to implement all sidebars: each of them should be considered case by case.
  • It might be helpful to create a document collecting all the interface sidebars, so that issues and progresses related to each of them can be tracked more easily.
  • The complementary role and the aside element define landmarks: these are navigational tools that can be used to navigate easily between fixed sections of a page. As such, the complementary role can’t be used for components that slide in and out.
  • A possible alternative to sidebars might be to add more alternative modes, like the current “Edit” and “Select” ones. For example, to reorder blocks there could be a “Reorder” mode that transforms the editor canvas in a simplified list with mover buttons.

#meeting-notes

Accessibility Team Meeting Agenda: September 18, 2020

This is the proposed agenda for the weekly Accessibility Team meeting on Friday, September 18, 2020 at 03:00 PM UTC.

  • Open floor

Checking issues and pull requests listed above before the meeting would allow us to save time and start the discussion right away, so please try and have a look at them if you can.

If you want to have a topic added to the agenda, please mention it in the comments of this post.

The Accessibility Team bug scrub will be held on Friday, September 18, 2020 at 02:00 PM UTC.

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

#agenda

[…] These are the weekly notes for the Accessibility Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here. […]

[…] These are the weekly notes for the 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 Team Meeting Notes: September 11, 2020

These are the weekly notes for the Accessibility Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Review the accessibility of the Gutenberg search block

To solve the Gutenberg issue to improve the customization of the search block, a first pull request to change some display options of the search block was merged. Unfortunately, the new implementation allows users to create search forms which are highly inaccessible. After some discussion, the Accessibility Team recommends the following:

  • every search form has to have a label, that can be visually hidden if the search form can be identified as such by other means;
  • every search form should have a submit button to identify it as such;
  • the default options for the search block should include:
    • a visible label,
    • a text button, and
    • no placeholder;
  • it’s worth doing an exploration about the possibility of throwing warnings in case a user reduces the accessibility of a search form.

Review the accessibility of new and existing sidebars in Gutenberg

In order to systematically address some problems regarding new and existing sidebars in Gutenberg, it was suggested that team members had a look at some related issues and pull requests before the meeting.

During the meeting, the discussion focused mainly on identifying why a sidebar may not be the best pattern in some situations. It’s worth having a look at full discussion on Slack about sidebars accessibility, even if it’s quite technical; following are the main takeaways of the discussion.

  • Regarding the use of a sidebar to change the settings of a specific block: it’s important to keep a logical information architecture to give assistive technology users a consistent and reliable mechanism to move between the block and the sidebar.
    • The main concern is the lack of proximity (both in the DOM and visually) that can impact especially on users with disabilities (among others: people who rely on keyboard navigation, screen reader users, low-vision users who need text enlarging).
    • Relevant controls should be placed in a meaningful sequence (both visually and in the DOM); the DOM should not be changed to match a visual design that is not helpful.
  • Sidebars should have a global context; settings for a specific item in a collection (a block, a media item, a widget…) should be inline with them.
  • Interface changes have a big impact on assistive technology users and, as such, should be carefully weighted. For example, the inserter component was changed from a popover with modal behaviour to a sidebar; this means that people used to interact in a certain way with the inserter had to re-learn how to use features they were used to.

#meeting-notes

Accessibility Team Meeting Agenda: September 11, 2020

This is the proposed agenda for the weekly Accessibility Team meeting on Friday, September 11, 2020 at 03:00 PM UTC.

Checking issues and pull requests listed above before the meeting would allow us to save time and start the discussion right away, so please try and have a look at them if you can.

If you want to have a topic added to the agenda, please mention it in the comments of this post.

The Accessibility Team bug scrub will be held on Friday, September 11, 2020 at 02:00 PM UTC.

This meeting is held in the #accessibility channel in the Making WordPress Slack (requires registration).

#agenda

Hey peeps, the project board to track editor features for inclusion in 5.6 is now available.
Feel free to add any editor issues you are particularly keen to land in 5.6!

A reminder that the cutoff for inclusion of new features is the 20th of October (the date of 5.6 Beta 1), so we need to be mindful of time and prioritise the most urgent issues.

[…] These are the weekly notes for the Accessibility Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here. […]

[…] These are the weekly notes for the Accessibility Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here. […]

Gutenberg-focused weekly meeting: call for issues

During the last Accessibility Team weekly meeting, it was decided that the meeting happening on Friday, September 11, 2020 at 03:00 PM UTC will be entirely dedicated to discussing Gutenberg issues.

If you want to suggest an issue or a pull request, you are invited to write it in the comments to this post before Thursday, September 10, 2020 at 09:00 PM UTC.

The Agenda will be published soon after and will include the issues that will be discussed during the meeting. If we won’t be able to fit all items in the agenda, we’ll consider organizing another specific meeting.

The meeting will be held, as always, in the #accessibility channel in the Making WordPress Slack (requires registration).

In the last weeks the accessibility team identified a series of broader issues that need to be prioritized but didn’t had the time to discuss in depth. Some of them are:

All the issues, PRs, and design related to the new Widgets screen

  • too many to list here

All the issues, PRs, and design related to the new Navigation screen

  • too many to list here

All the issues identified as accessibility regressions in WordPress 5.5 that still need to be addressed e.g.:

All the issues, PRs, and design related to existing and new sidebars:

All the issues, PRs, and design related to toolbars broken because an extraneous UI gets rendered “on the fly” within the toolbar, e.g.:

I’ve got a feature request for adding a link section to the Cover block, which I (and many other people) think should be a feature: http://wayback.fauppsala.se:80/wayback/20200930094950/https://github.com/WordPress/gutenberg/issues/12684

Hello Calum,
First of all, thank you for your suggestion!
I had a look at the feature request, but it’s not clear to me if the issue is accessibility-related: if you could make more clear with a comment here on or GitHub why the Accessibility Team should discuss about this issue, we’ll be happy to include this item in the meeting agenda.
I hope to see you tomorrow at the meeting, have a nice day!

I’d like to propose a couple additional things to discuss:

Search Block: Add button, label, and widthoptions
http://wayback.fauppsala.se:80/wayback/20200930094950/https://github.com/WordPress/gutenberg/pull/24666

This Gutenberg issue, in my opinion, give too much power to users as they will be able to publish a search input with no label (at all), no placeholder, no button text (only an icon). Also, this breaks the previous agreed implementation where a properly associated label element was always present, with the option to make it visually hidden.

Mid-long term task: testing again all the Gutenberg blocks
There are still many blocks that aren’t even keyboard accessible. That means keyboard users can’t use them. It would be great to plan a thorough audit of all the blocks. At first glance it seems a huge task but it could be performed by splitting the blocks in chunks to be assigned to various contributors.

Accessibility Team Meeting Notes: September 4, 2020

These are the weekly notes for the Accessibility Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Organization of an extra meeting to discuss specific Gutenberg issues

The team discussed adding an additional one-off meeting to address specific Gutenberg features for the WP 5.6 release that require special attention.

Given that there was no consensus on a date and time for this meeting, we will be using our regular meeting time next week to discuss and address these issues.

During the discussion, it was also proposed for the Accessibility and Design teams to hold office hours once a week. As suggested by @sarahricker:

It is intended a place for general feedback re: Gutenissues and to get a few eyes on big issues so they can be brought to light quicker. And to help anyone who needs help with a11y concepts.

The team thought this to be a great idea and are looking forward to hear more and participate. Be on the lookout for more information coming soon from @sarahricker and @karmatosed.

Adding a screen reader announcement to the last block in a list

We finished discussing this Gutenberg issue that proposes to add a screen reader announcement to last block in the block list by @alexstine.

The team agreed this is a good idea and should be tried and tested in a PR.

Adding a sidebar for navigating template, posts, and pages inside the block editor

We discussed this Gutenberg issue that explores a new sidebar UI for navigating between templates, posts, and pages without leaving the editor.

A concern around having too many sidebars (and sidebars in general) and how this new one being explored looks different was raised, and an argument in favor of hierarchy and information architecture was also brought up.

The feedback will be added to the issue.

The image block’s editing tools break the toolbar keyboard accessibility

We also looked at this issue that reports that the image block editing tools are triggering a focus loss, thus affecting keyboard accessibility of the toolbar.

We discussed alternatives worth exploring and will leave feedback in the issue.

#meeting-notes

s
search
c
compose new post
r
reply
e
edit
t
go to top
j
go to the next post or comment
k
go to the previous post or comment
o
toggle comment visibility
esc
cancel edit post or comment
0
:)