Category Archives: Meetings

Stefano Minoia 3:00 pm on June 27, 2020
Tags:   

Accessibility Team Meeting Notes: June 26, 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.

At the beginning of the meeting, we welcomed three new contributors: @squarebraket, @sarahricker and @azhiyadev; the last two of them had volunteered to join the Accessibility Team in view of the WordPress 5.6 special release, when they will be in charge of the accessibility focus.

Discussion about the new 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/ inserter

The first discussed item was the design difference between the preview of blocks and patterns in the Gutenberg editor and its impact on usability/accessibility.

@afercia pointed out in a comment to the umbrella issue about the inserter that two regression were introduced by recent pull requests: one is already closed, but the other issue (about the Block Inserter not constraining tabbing) is still open and should be solved in time to ship with 5.5. On the same topic, @joedolson underlined the fact that all panels should always constrain tabbing and that this should become a general pattern.

A lively debate about various aspects of usability/accessibility followed; topics discussed included:

  • consistency between the blocks panel and the patterns panel;
  • solving the double tab stop problem in the patterns preview;
  • removal of the expandable blocks groups;
  • limiting the number of patterns displayed in their panel.

Full discussion about the new Gutenberg inserter is available in Slack and a comment to the issue about accessibility improvements to the inserter will summarize the different points of view.

Discussion about alternate views for list tables

Ticket #49715 is one of the focus topic of the Accessibility Team for WordPress 5.5 release. With betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. release approaching, the Team agreed to refresh the latest patch according to the suggestions in the last comment to the ticket, so that we can ship a sort of working “framework” to support alternate table view and iterate during next release. @audrasjb will take care of the refresh.

Related to the same topic, the Team decided to move ticket #48751 to the 5.6 milestone.

Discussion about the ‘Howdy menu’

Ticket #48894 is also one of the Team priorities for 5.5 release. Discussion had already taken place during the bug scrub: the Team decided to ship the feature as is and iterate during next release, unless there will be objections from the Design Team.

Open floor

A number of items were suggested for the open floor, but we didn’t have time to discuss all of them.

Accessibility improvements to the new ‘Plugins & Themes Auto-Update’ feature

After WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/., no extra steps have been made to solve accessibility issues discussed during May 29, 2020 weekly team meeting. @ryokuhi will open a ticket to address them before or during beta. (Edit: ticket #50512 is now open)

Update on prefixes to admin notices

Following last week discussion, the commit to remove of the ‘Error:’ prefix from the admin notices (discussed in ticket #47656) was reverted. Ticket #50442 to add prefixes to all admin notices was also created.

It was noted that notices in Gutenberg don’t have any prefix, so, for consistency, prefixes should also be added to Gutenberg notices. @audrasjb offered to open an issue on the Gutenberg repository.

Also, a few options to improve the accessibility of notices where added to the original ticket: @afercia volunteered to open ticket #50486 to better address them.

Open topics

There was no time to tackle other topics: they will be addressed during next meetings. Future points to discuss are all related to the Gutenberg editor:

#meeting-notes

Jb Audras 11:20 pm on March 27, 2020  

Accessibility Team meeting notes – March 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.

Feedback on the CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. audit being performed by the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-css team

Context: the Core CSS team proposed to launch a CSS audit of WP-Admin in the #core-css channel. They recently asked the design team for input on what they would like to see covered in the audit, and it would be great to also have some input from the accessibility team. They have a bunch of tickets to track everything audit-related:

  • Determine methodology recommendations for CSS audit – #49638
  • Create a report outline for CSS audit – #49637
  • Add visual regression testing to core – #49606

Everyone is welcome to comment on the above tickets.

@afercia shared some general considerations: while an admin CSS audit is extremely necessary, there’s also the risk to overdo and enter the “refactor for the sake of refactoring” territory. He would definitely recommend the css-team to start with baby steps and avoid bigger changes, at least at the beginning.
There are also some CSS properties that are a no-go. For example, all the ones that change the visual order e.g. flex order, flex-direction row-reverse, column-reverse and so on. Also simple things like list-style: none may significantly impact assistive technologies or the way some browsers expose information to assistive technologies.

@joedolson also wanted to ensure we are all on the same page concerning browsers support. @audrasjb answered WP-Admin doesn’t officially supports less than IE11 and @afercia added that it is safe to assume we can remove all CSS related to old IE and prepended with .ie7 – .ie8. See also this Trac ticket for reference.

5.4 post-mortem on Make/Core blog

The WordPress Accessibility team published their position concerning default fullscreen mode on the block editor.

As this change is going to land in WordPress 5.4 –it was announced during the last dev chat– @audrasjb pointed out that the content of the Accessibility Team’post could be used to write a 5.4 post-mortem, and he is going to coordinate with @francina to write this post on Make/Core. It will be a team effort to ensure that all the Accessibility Team viewpoints are captured. @ryokuhi is also available to help on this.

@mapk added he is also organizing some people from Automattic to help wrangle support forums for this release. They will probably have some feedback there.

Accessibility team’s work kick-off for 5.5

The team defined the main projects to focus on for WordPress 5.5:

  • Accessible color schemes: Provide some accessible color schemes for WP-Admin. Lead: @joedolson. @ryokuhi also proposed to help on this project.
  • Alternative WP List Tables views: Propose an alternative way to display List Tables in WP-Admin – ticket #49715
  • “Howdy fly-out menu”: Refine/replace the upper-right WP-Admin fly-out menu.

There are also 29 other TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets milestoned for 5.5.

WP Accessibility Day update

Next meeting scheduled on Tuesday March 31, 2020 at 16:30 UTC.

Jb Audras 11:17 pm on March 4, 2020  

Accessibility Team meeting notes – February 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.

Improve the Handbook recommendation for abbreviations and acronyms

@afercia raised that in TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket #46980, the accessibility team set some new practices for abbreviations (and acronyms). That would be relevant to add them to the Core Handbook section about abbreviations as well.

Basically:

  • Evaluate which abbreviations can be removed in favor of full text
  • For the other cases: provide an expansion of the abbreviation/acronym/neuronym in plain text on first use
  • Use an <abbr> to mark up the abbreviation (which provides a hint to user agents on how to announce/display the content)
  • Do not use title attributes

@audrasjb to touch base with the Docs team on Monday, to see how the handbook page could be improved.

Edit from Monday: the Docs team doesn’t manage the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. handbook, it’s under Core team responsibility.

Accessibility team goals for WP 5.5

All the accessibility tickets in the 5.5 milestone can be found using this Trac query.

@joedolson noted that it would make sense to have as a goal is more aggressive work during alpha, so that we can dedicate more attention to the final product during betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. & RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge..

@afercia added that apart from bugfixes, it would be nice to have at least a couple user-facing accessibility improvements for 5.5.

@audrasjb noted that milestone 5.5 will be open for commit right after WP 5.4 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. 1 is out.

The team tried to summarize the main current projects of the team for Core and to get somebody to take point on each project:

  • Accessible color schemes: Provide some accessible color schemes for WP-Admin. Milestoned to WP 5.5. Lead: @joedolson
  • Alternative WP List Tables views: Propose an alternative way to display List Tables in WP-Admin. Milestoned to WP 5.5.
  • “Howdy fly-out menu”: Refine/replace the upper-right WP-Admin fly-out menu. Milestoned to WP 5.5. Needs someone to take the lead on this task.
  • Uniform Search: Redesign of the search in WP-Admin. Milestoned to WP 5.6 as it will need a lot of work ahead of the release development cycle.
  • WP-Admin Colors: Not milestoned for the moment.

Update on WP Accessibility Day

Quick update from @joedolson: It’s moving forward. Goal is to announce on March 25th; there’s a design in the works, so we’re on target. The website is currently under construction, thanks to @xkon. Regular meetings are hosted on #accessibility-events 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 (requires registration).

Not much else to report right now. There is a budget mostly worked out, looking for sponsors to cover the captioning & transcription costs, etc.

Open floor

@joedolson: Ticket #49517 needs some discussion with the editor team, although it’s a very clear cut issue from the accessibility side.

@ellatrix is going to revert the related pull request on 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/.

Jb Audras 5:41 pm on January 3, 2020  

Accessibility Team Meeting Notes: 3 January 2020

Meeting transcript on Slack

Update on 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) Day

The project kickoff meeting took place on Tuesday, December 17th. The meeting summary is available.

Proposed date for the next WordPress Accessibility Day meeting is Tuesday 14 January 2020 at 16:00 UTC in the #accessibility-events 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. If you would like to propose another meeting date, please comment in the meeting summary post.

Update 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/ focus handling research work

Last month, the accessibility team made some testing on how Gutenberg handles focus on the various blocks. Thanks @enrique, @markdubois, @vicent, @gziolo, @audrasjb and @joedolson for their contribution.

@joedolson completed the focus handling tests & written up observations on it in a document.

Next steps:

  • Publish the summary on Make/Accessibility
  • Open related issues on 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/ repository

WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia – contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.

WordCamp Asia will host a contributor day and plan to set up an Accessibility table. All accessibility team members who plan to attend the WordCamp are welcome to volunteer to lead the table. Please comment below if you are interested.

Accessibility team goals for WordPress 5.4

@audrasjb: It would be great to define a primary focus for the team, for the next major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality., WordPress 5.4. It’s not mandatory to have a main focus, but with 5.3 the primary goal of the team was the Admin CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. changes and it was quite effective.

@sabernhardt added one goal would be fixing more issues from the Gutenberg audit (maybe not primary focus though).

@nataliemac asked if it’s possible for accessible color schemes to be a focus for 5.4.

Accessible color schemes is a very nice project but it will probably have to wait for 5.5 in August, as 5.4 development must to be almost completed in 4 week. The idea is to plan major goals for 5.5 in the next few weeks and to focus on smaller tasks (TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets and Gutenberg issues) for 5.4.

This Trac report can be used to pick up small focuses for 5.4. On Gutenberg side, that would be nice to address a couple of issues from the audit.

Enrique Sánchez 4:59 pm on November 26, 2019  

Accessibility Team meeting notes for 22 November 2019

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.

Initial focus on 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/ blocks

The team continued the discussion about where initial focus should land on the different types of blocks available 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. For example, some blocks such as text-based blocks have a clearly defined editable area, which makes it obvious where focus should land. This however is not the case with a variety of blocks where text is not the primary element.

The team agreed to investigate and document initial focus on all the available blocks in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and post findings on a newly created spreadsheet that contains a list of all the blocks. We’ll revisit the list during the next meeting and evaluate our progress.

5.3.1 scope

The team’s goal for 5.3.1 is to address any immediate regressions introduced on 5.3. The tickets that need special attention are #48585, #48598, #47142, #47069 and #48420. Help with testing, patches and providing feedback is welcome.

Accessible color schemes

The team continued the discussion from the previous meeting about having color schemes in wp-admin that address specific accessibility needs. We think this could be a great feature proposal for 5.4 or 5.5.

The team agreed that we should start with a 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 that will reside in the accessibility team’s GitHub repository.

Jb Audras 8:59 am on November 20, 2019  

WordPress Accessibility team Meeting notes for 15 November 2019

Meeting transcript on Slack

Elect New Team Representatives for 2019-2020

@nrqsnchz and @audrasjb were nominated and elected to represent 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 for 2019-2020.

Thank you to @joedolson who represented the team during 2018-2019 term and congratulations for his nomination as WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committer ⭐️

Assign new team and contributor badges

As a reminder, Team badge is reserved for people who have a high level of activity and contribution; Contributor badge is given to people who have helped occasionally or are new to the team. Each badge is permanent; there’s no requirement of continued activity.

Badges assignment were publicly discussed during the meeting.

WordPress 5.3 release

@afercia and @audrasjb are currently addressing concerns raised by some users in the Admin CSS changes dev note’s comments. Team members are welcome to help to answer these comments. The majority is not very constructive comments but as a team, there is a need to properly answer them.

For the moment, the complaints don’t seem to be statistically significant (a dozen of individual commenters).

@afercia seen at least 3 major plugins releasing new versions with minor adjustments for the admin CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. changes so it seems communication worked well.

Twenty Twenty submenus

@poena raised a concern about Twenty Twenty horizontal navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site.: “On desktop you hover over the parent menu item to show the (first) submenu. But on tablets you have to click the parent menu item link to show the submenus, and then click the same link again to access that menu item. There is no button to toggle the submenus, it is an icon which is part of the link.”

@afercia noted the issue was addressed in Twenty Seventeen by adding a separate, dedicated button to toggle submenus.

Given WP 5.3 is already released and Twenty Twenty already used in a large amount of websites, it is a pretty big change that would need some communication. It is not necessarily a top priority, as it’s not that the current pattern is inaccessible, it just may not be the best possible option.

WordPress CSS changes and color schemes

The color contrast changes are pretty solid in core, but cause problems with the core-provided alternate color schemes. This is not directly an accessibility issue, as the color schemes were not accessibility features, but it was caused by the accessibility team work, so the team should probably owns it to some degree.

The immediate issues will be fixed in the next minor releases.

However, the meeting attendees agreed that the entire purpose of color schemes should be reconsidered as it doesn’t make much sense to have only cosmetic changes in alternate color schemes. They should rather address specific purpose, like:

  • a dark theme to complement operating systems dark themes
  • a low contrast theme to help users who struggle with strong contrast
  • a theme with a good typeface to help users with dyslexia, preferably with options to adjust letter spacing and line-height

Current color schemes could be deprecated to a 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 design-only tweaks are plugin territory, and new alternate color schemes could be more focused on specific, relevant and useful features. The idea is not to remove existing alternate color schemes completely, since some users are using them, but rather to deprecate them and to stop maintaining them in WordPress core. @melchoyce also proposed having an auto-install of an eventual plugin with all the existing color scheme to support them if users had them enabled. There is already an existing plugin that could be used for this purpose.

Admin Color Schemes
Jb Audras 8:00 pm on September 1, 2019
Tags: , , core-media,   

Accessibility Team Meeting Notes: 30 August 2019

Meeting transcript on Slack

Progress report on WordPress 5.3 TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets

There is 66 accessibility focused tickets in milestone 5.3:

  • 10 are fixed
  • 56 still need to be fixed

To help them moving forward, two additional bug scrubs are scheduled, on Tuesday 3 September 2019 at 15:00 UTC and Tuesday 10 September 2019 at 15:00 UTC.

@afercia noted that some of those tickets are close to commit. Andrea will try to commit some of them in the next days.

@joedolson won’t be able to address his own tickets until 14 September.

@anevins is going to update the #core-media tickets spreadsheet to highlight media tickets that still need some work.

Assign owners for tickets slated into WordPress 5.3 milestone

@abrightclearweb asked what ticket owners are supposed to do exactly.

@anevins: “They make sure the work gets done by either assigning the work to a practitioner (comes with pretty pleases) or by doing it themselves. They just drive the work forward.”

@joedolson: “it can including writing the patch, but doesn’t need to.”

@abrightclearweb took ownership on #47477. @kjellr will also help on that ticket if needed.

For further informations about testing a patch, see the related core handbook page. However, that assumes contributors have a working development environment. Patch can also be tested directly by applying the patch manually. @joedolson also shared a generic document on creating and applying patches (not about WordPress, but it would work).

At the moment this summary is written, there is still 10 tickets without owner in milestone 5.3. Any contributors are welcome to ask for ownership in 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) 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.

Open floor

The accessibility team discussed ticket #47149. Some comments were added in the ticket.

@afercia noted aria-controls shouldn’t be used anymore and quoted a tweet by Steve Faulkner:

In short, JAWS was the only 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 to actually use aria-controls and the implementation was just confusing. An other post was also quoted for further informations about aria-controls.

@audrasjb changed the initial 5.3 additional bug scrubs time from 14:00 UTC to 15:00 UTC to make it easier for US contributors.

#5-3, #bug-scrub, #tickets

Jb Audras 5:17 pm on August 2, 2019
Tags: , ,   

Accessibility Team Meeting Notes: 2 August 2019

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/: Support Navigation and Edit Mode

For reference, see the related pull request on Gutenberg GitHub repository.

The idea is to use tabs key to provide a way to navigate between blocks with the keyboard (navigation mode). Hitting enter switch to edit mode (you can edit 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. you navigated to). Hitting escape switch back to navigation mode.

All meeting attendees agree that this is a good improvement. It would be necessary to be extensively tested by as many persons as possible, including users of assistive technologies.

The next 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 release is planned for August 12th. 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 will publish a call for testers with some testing scenarios to test this big improvement.

Improving the Accessibility Team feedback on Gutenberg issues and pull requests

There is a need to follow Gutenberg development on both 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/ and 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/. (in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor channel), and @afercia is currently spending a lot of time to follow it’s development, sending issues and reviewing pull requests.

As @afercia said: As of today there are 37 Gutenberg issues and pull requests with the “Needs Accessibility Feedback” label. The Accessibility Team need more persons able to follow that closely.

@nataliemac volunteered to help monitoring the “Needs Accessibility Feedback” label on Gutenberg GitHub Repository.

The Accessibility Team will discuss the possibility to find ways to have sponsored contributors (even a couple hours a week would be a great sponsorship!) during the next weekly meeting.

WP Accessibility Day – organizing team & next steps

Reminder: it was previously decided to evaluate the possibility to organize a dedicated WordPress global accessibility event, like polyglots do with WordPress Translation Day (WPTD).

The idea is to organize a 24-hour virtual event all around the world with some video conferences and focused on contributing to WordPress accessibility.

A couple of weeks ago, a spreadsheet was shared so Accessibility team contributors could sign up to be involved in this organizing team.

A dozen people signed up to the organizing team: @audrasjb, @joedolson, @nataliemac, @SergeyBiryukov, @bamadesigner, @gianwild, @bdeconinck, @jaymanpandya, @kevinbazira, @robin2go, @foucciano and @ryokuhi 🎉🎉🎉

The next step is to discuss the main focuses of the event and to divide the roles between the organizing team.

Feedback on Theme Review Team’s post about supporting keyboard navigation

For reference, see the related post drafted by @poena.

@audrasjb raised a missing item: focus order that should match visual order.

If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)

Source: Web Content Accessibility Guidelines 2.0

@nataliemac added the post should include a warning about not relying on overuse of tabindex to accomplish this.

@afercia raised another item: there is a need to clarify that the native browsers outline can be removed but only if an alternative, like an accessible focus style, is provided.

@anevins: Theme authors should also be encouraged to use the Accessibility support forum if they get stuck.

Openfloor

During the next weekly meeting, the Accessibility Team will assign owners for the 53 tickets in the 5.3 milestone.

#5-3, #gutenberg, #wordpress-accessibility-day

Jb Audras 5:54 am on July 29, 2019
Tags: , ,   

Accessibility Team Meeting Notes: 26 July 2019

Meeting transcript on Slack

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. Directory in WordPress Admin

During WCEU’s Summer Update, @matt presented a new wp-admin section for Blocks.

For reference, see Make/Design blog post about Block Directory in WP-Admin Concepts and related GitHub Issues.

WordPress Design Team confirmed this design is meant to become the default for any future admin page.

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 raised some initial feedback for these early design:

  • The main h1 is not the first element within the main content area.
    “Add new”, search, help, and “mystery” menu are all above the h1. It’s important to get the heading before getting whatever tools are related to it. As these tools do change contextually, they are context-sensitive tools and headings are here to provide that context.
    When users land in a WP-Admin content area, they need an answer to the following questions: 1) What is this about? 2) What can I do here?
  • Center aligned multi-line text is problematic for low vision users. Given how little use of it there is, it’s not a huge concern: it’s only a problem in the text under the h1, as it causes low-vision users to have to hunt for the start of the next line. It’s not great, but it’s probably not a deal breaker, as it’s not primary content.
  • Icon-only controls:
    • The “more” button icon (three vertical dots) purpose is not very clear.
    • The current headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. implies that the user need to toggle the search to enable it, which is a new UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. interaction for search.

The summary here is that the Accessibility Team have concerns about the header of these screens, which needs to be reconsidered in light of:

  • Proximity of controls
  • Giving context before tools
  • Use of icon-only controls

Note: @melchoyce shared an alternative design for the header of those screens after the meeting.

WordPress Accessibility Day – next steps

Reminder: it was previously decided to evaluate the possibility to organize a dedicated WordPress global accessibility event, like polyglots do with WordPress Translation Day (WPTD).

The idea is to organize a 24-hour virtual event all around the world with some video conferences and focused on contributing to WordPress accessibility.

First, we need an organizing team: about 10 people to evaluate deeply the feasibility and the scope of the project.

Contributors are welcome to add their name in this spreadsheet to signup to the organizing team. Then we can start organizing details and time frames. The group that plans what the event will be doesn’t necessarily have to be identical to the group that runs the event.

Usage of .screen-reader-text class in accessibility documentation

Theme Review Team contributors raised some concerns about the current screen-reader-text class documentation.

First, the way .screen-reader-text is documented is inconsistent – it’s a mix of saying “this is the CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. for .screen-reader-text” and “.screen-reader-text doesn’t need to be hidden”, and that’s contradictory. Accessibility people understand what it mean by that, but people being introduced to the concept don’t.

Instead of indicating that .screen-reader-text doesn’t need to be hidden, it would be better to say that this specific CSS is the required CSS for that class, and provide documentation on how to change the 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.. The documentation should highlight the point of difference between visually hiding an element versus actually hiding it from the browser and accessible technology.

This will increase consistency with usage of .screen-reader-text – if somebody wants that text visible in a theme, then they can change the HTML; and it won’t be overridden by other plugins, etc.

Additionally, there’s some clarification required for the .screen-reader-text:focus CSS. The provided CSS will always set the focused objects into the skip-link position, but that may not be appropriate if the theme author is not styling skip-links. The document should indicate clearly that if focused screen reader text is not a skip-link, the positional elements of this need to be changed.

@joedolson is going to take care of rewriting the related docs and will work with @joyously to ensure the new documentation is clear enough for theme authors and WordPress developers.

Open floor

@nataliemac is looking for volunteers who will be at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US to be teaching assistants in a 2-hour accessibility workshop. They will be leading up to 100 attendees through some general accessibility concepts and testing and fixing accessibility issues on their own websites.

@poena: in only a few weeks time theme authors will be required to support keyboard navigation. The Theme Review Team is going to publish a post to help them prepare.Accessibility Team contributors are welcome to read the public draft and to share any concerns by pinging @poena on accessibility 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 or by commenting this Make/Accessibility post.

#documentation, #gutenberg, #wordpress-accessibility-day

Jb Audras 12:55 pm on July 25, 2019
Tags: ,   

Accessibility Team Meeting Notes: 19 July 2019

Meeting transcript on Slack

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/ experiments settings page

The feedback needed is on the settings page: has it been implemented as recommended? See related Gutenberg GitHub pull request for reference. That page is going to appear under the Gutenberg admin menu.

@karmatosed gave some backstory:
Today, if you wanted to try or test these features you would have to add code in the console. This is not a great way forward. It excludes and it makes testing really problematic. That’s what the pull request looks like, in release this doesn’t exist yet. What feedback is needed, is if the pull request implements the settings page as expected 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).

@afercia: one problem of the Settings APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. with regards to checkboxes is that the checkbox labels needs to be placed on the right of the checkbox. I also think it’ll help to have a short description under each option that explains a little more about what each option is. Of course, that leads to duplication of the bold text on the left and real elements, but that’s a historical problem.

Couple years ago we experimented improved Settings API, proposing to not use the two columns layout. That would solve a lot of problems but needs design. And it’s a bit out of the current scope. An improved WordPress Settings API with default render callbacks and a new accessible layout.

@nrqsnchz: In terms 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), I’m thinking this each group should be marked up as a fieldset? What does everyone else think?

@afercia gave a code example: Discussion settings:

<tr>
    <th scope="row">Email me whenever</th>
    <td>
        <fieldset>
            <legend class="screen-reader-text"><span>Email me whenever</span></legend>
            <label for="comments_notify">
                <input name="comments_notify" type="checkbox" id="comments_notify" value="1" checked="checked">
                 Anyone posts a comment
             </label><br>

            <label for="moderation_notify">
                <input name="moderation_notify" type="checkbox" id="moderation_notify" value="1" checked="checked">
                A comment is held for moderation
            </label>
        </fieldset>
    </td>
</tr>

@karmatosed: If that’s going to be the recommend way let’s ship it.

WordPress Accessibility Day

Context: last week, it was decided to evaluate the possibility to organize a dedicated WordPress Global Accessibility Event, like polyglots did with WordPress Translation Day (WPTD). The idea is to organize a 24-hour virtual event all around the world with some video conferences and focused on contributing to WordPress accessibility.

To organize such an event, the accessibility team needs at least 10 organizers and some support from other teams. That would be interesting to connect with WPTD organizers.

@ryokuhi: Last week we decided to leave a week so that everyone could check their possible involvement. I don’t know how are other local 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 organized, but (at least in Italy) we have a dedicated local channel for a11y. How about asking people involved in accessibility in their local communities, but not in the Make/WordPress general accessibility Slack channel, to take part in the Accessibility Day organization?

@afercia: Maybe the first step would be pinging persons from different countries and ask this question.

We identified this page as a list of the local communities Slacks: https://make.wordpress.org/polyglots/handbook/about/teams/local-slacks/ That would be great to have some feedback to know if that list is up to date.

@sami.keijonen to ask in Finnish Slack Group. @audrasjb to ask in French Slack Group. @karmatosed to ask in UK Slack Group.

There is a public Google Document to share ideas on the event organization.

Next week agenda items

@afercia proposed one Agenda item for next meeting: 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. Directory in WordPress Admin.

During WCEU’s Summer Update, Matt presented a new wp-admin section for Blocks. @afercia want to share those early concepts during next Accessibility Team Meeting. In the meantime, please have a look at Block Directory in WP-Admin Concepts Make/Design blog post and the related GitHub Issues.

#gutenberg, #wordpress-accessibility-day