Accessibility Team Meeting Notes: November 27, 2020

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.

Badge assigning to team members and contributors

Badges are usually assigned twice a year and one of those days is today (Friday November 27, 2020.) One of these badges is Accessibility Contributor and the other is Accessibility Team. Accessibility Contributor is for those that contribute a few hours or attend the meetings while Accessibility Team is for the ones that put in a lot of time by commenting on tickets, testing/making patches, and attending meetings. @joedolson will be handling the badge assigning.

Working groups’ referents nomination

This agenda item was skipped until a future week due to the absence of people from the holidays.

Discussion about dedicating a bug-scrub to labelling good-first-bug tickets and issues

@sabernhardt has offered to step up and lead a special bug scrub. The first one will be held Tuesday December 2, 2020 at 16:00 UTC. A big thank you to @sabernhardt who has offered to lead! The main focus would be on Accessibility tagged tickets for Future Release.

Open Floor

Some discussion around sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. accessibility was brought up: review here

#meeting-notes

Accessibility Team Meeting Notes: November 13, 2020

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.

Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. nominations

The team accepted nominations for a new Team Rep and we’re happy to share that both @alexstine and @sarahricker have been nominated for the role.

Given that more than one person was nominated, we are going to open a voting round so folks can vote for the person they’d like to see as our new Team Rep.

Please follow this link to vote https://forms.gle/Bwv1PqGqhVQ9VuE28. The survey will be open until Friday, November 20, at 16:30 UTC.

Organization of team sub-groups

We discussed and decided to move forward with the idea of organizing our team around sub-groups. This will allow members of our small team to focus on specific areas of interest and expertise. The groups are:

  • Editor
  • Design
  • Media
  • Themes
  • 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.
  • Docs
  • General

Folks have already shown interest on the areas they’d like to participate in, so we’re going to give this new organization structure a try for the WP 5.7 release and we’ll adjust and adapt as necessary.

5.6 projects status

@sarahricker, our WP 5.6 Accessibility Release Coordinator, shared a status on the different projects the team is juggling during this release.

The Accessibility Statement 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 currently being promoted in the About page. Help is needed reviewing the content of the generated statement. You can test and give feedback here.

@joedolson and @Hauwa Abashiya have been hard at work on the new pattern library to support 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. Please refer to the #accessibility-docs 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/. channel for more info on how you can help.

The new Twenty Twenty-One theme is moving along and they need help testing the new dark mode.

#meeting-notes

Accessibility Team Meeting Notes: October 30, 2020

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.

Team meeting time change

Starting Friday, November 6 2020, our team meeting and bug scrubs times will shift one hour to accommodate the recent end of daylight savings time across the world.

The team meeting will now be held at 16:00 UTC, and the bug scrub at 15:00 UTC. Please refer to the WordPress Meetings Calendar for more info.

Upcoming Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. call for nominations

As my term as Team rep comes to an end, we’ll be holding a call for new Team rep nominations during our next meeting. Depending on the number of nominations, we’ll define if we will be holding a voting round after the meeting.

If you are interested in the role or know someone who would be a great fit, next week you’ll have the opportunity to nominate yourselves or others for the role.

Please feel free to reach out to @ryokuhi or me (@nrqsnchz) on 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/. if you have any questions about the role or the process.

Improvements to team workflows

The team held a discussion on our process around discussing issues and tickets in our team channel and during our team meetings.

The topic of working asynchronously came up, as we don’t always have the time to cover everything during our meetings, and tangentially not everyone is able to attend our weekly meetings for various reasons.

We also talked about creating sub-groups on our team that can focus on specific areas of interest and expertise. We are very mindful of the limited resources our team has, and we think being smart about how we each spend our time is something we need to improve.

We agreed to pick up this conversation during our next meeting and start organizing the team around this idea.

#meeting-notes

Accessibility Team Meeting Notes: October 16, 2020

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

Accessibility Team Meeting Notes: October 2, 2020

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

Accessibility Team Meeting Notes: September 25, 2020

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

Accessibility Team Meeting Notes: September 18, 2020

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.

Update on WordPress 5.6 goals

Updating coding standards to 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

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 W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/.;
  • 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 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/. (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 pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.

Developement of the accessibility statement 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 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 ProductMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia stage) aligns more closely with the acceptance criteria and mimics the Privacy Policy functionality currently in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

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

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/ 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 sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. 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 Notes: September 11, 2020

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.

Review the accessibility of 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/ search 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.

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 sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. 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 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 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 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.…) 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 Notes: September 4, 2020

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.

Organization of an extra meeting to discuss specific 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

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 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) 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 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. 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 sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. 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

Accessibility Team Meeting Notes: August 28, 2020

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.

WordPress 5.5 release post-mortem

The team shared and discussed what we thought went well and went wrong with our team’s projects and tasks during the release of WordPress 5.5.

The issue of not enough early involvement and feedback during design and development updates to 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 was brought up a few times and discussed at length. We all agreed that the process needs to be improved and our team is still very limited in terms of time and resources.

We agreed to explore solutions and ideas that would help us improve this cycle and follow-up in a separate document or post. @sarahricker volunteered to put all of this feedback together.

Team goals and priorities for WordPress 5.6

We reviewed the suggested projects and priorities that were added to the call posted earlier this week. After some discussion and a show of hands, the following projects gathered enough interest and participation:

  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 2021 default theme
  3. 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 “Accessibility Statement” tool with features equivalent to Privacy Policy Tools

All other items on the agenda that couldn’t be covered will be added to next week’s meeting agenda.

#meeting-notes