Accessibility Team Meeting Notes: May 14, 2021

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 discussion around the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue Post Title Block: add typography formatting options

The focus of this discussion is around whether it’s a good idea to allow underlining of text that is not a link as underline can strongly indicate that the text is a clickable link and may lead to confusion if non-links are underlined.

It was decided that it would be better to remove the underline formatting option from the pull request for now and maybe revisit implementation later if there is a greater need.

How to move forward with Proposal: new workflow keyword to exclude tickets until review is needed

At this point, the proposal was posted a couple weeks ago. The best way forward is likely to choose a keyword name. Another suggestion was brought up to just mark tickets as Future Release milestone. A list of keywords that the team is considering can be found in a comment on the original post: comment posted here.

Updates from the team’s working groups

Due to a time shortage, this agenda item was skipped for today.

Open floor

FSE Updates

Both are part of Full Site Editing Go/No Go: Next steps which makes these crucial for Accessibility team feedback.

Documentation

Accessibility Standards documentation updated via the GitHub PR: Update accessibility.md.

Media

The infinite scroll removal has been committed for 5.8. If you notice any issues during testing, please report them via Core TRAC.

Next Bug Scrub/Meeting (Friday, May 21, 2021)

Because of concurring tasks, @ryokuhi and @alexstine won’t be able to facilitate the Accessibility bug scrub or meeting on May 21. @chaion07 has offered to lead the bug scrub and @joedolson has offered to lead the meeting.

#meeting-notes

Changes in WCAG 2.1

The WordPress AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team is updating the existing WordPress accessibility standards for development. Web Content Accessibility Guidelines (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/.) are the industry standard recommendations for improving web accessibility. The current WordPress accessibility standards are shifting from WCAG 2.0 to WCAG 2.1.

WCAG 2.1 was published on June 5, 2018. WCAG 2.0 guidelines are built into 2.1 so by conforming to 2.1, you are conforming to 2.0. Where it differs is that WCAG 2.1 has an additional 17 success criteria targeted at users with cognitive or learning disabilities, low vision, and disabled users on mobile devices. 

The WordPress Accessibility Handbook, Accessibility Core Standards, and Accessibility Pattern Library are being updated to reflect these changes and provide better guidance. This will include:

  • the principles, guidance and success criteria for conforming to WCAG 2.1
  • a list of documents and resources (technical and non-technical) for reference
  • a library of patterns (good and bad) with examples that will help improve the user interface

Below is a summary with examples of the additional success criteria for WCAG 2.1 under each of the principle and corresponding guideline.

Principle: Perceivable

Guideline 1.3 Adaptable

1.3.4 Orientation — Level AA

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. 

Example:

This would be an uncommon scenario in WordPress. A hypothetical example might be implementing an editing interface that only worked in landscape format, because some tools were not visible on screen in a narrower viewport. 

1.3.5 Identify Input Purpose — Level AA

The purpose of each input field collecting information about a user can be programmatically determined.

Example:

This success criteria essentially means “use supported autocomplete attributes when they are relevant.” When collecting common user information, such as name, email, address, or other common information, the fields collecting that information must use the relevant autocomplete attribute. This aids users with cognitive or mobility impairments.

Guideline 1.4 Distinguishable

1.4.10 Reflow — Level AA

Content can be presented without loss of information or functionality and without scrolling in two dimensions.

Example:

The table element, in normal usage, has a significantly limited capability to be responsive while retaining the semantic value of a table. This commonly results in the need to scroll vertically to see all rows and horizontally to see all columns. Interfaces must avoid requiring users to scroll in multiple directions to see content. 

1.4.11 Non-text Contrast — Level AA

The visual presentation of content images and user interface components must have a contrast ratio of at least 3:1 against adjacent colors.

Example:

Form fields, buttons, or icons that are not supplemental to text are all examples of design elements that now have a contrast requirement. WordPress has applied this expectation in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for several years already, so this should not have any profound impact on design expectations.

1.4.12 Text Spacing — Level AA

No loss of content or functionality should occur when line-height, paragraph spacing, letter spacing, and word spacing is changed.

Example:

Users may employ custom stylesheets or other mechanism to make text more readable for their needs. While primarily targeted at text, it may result in unexpected overlaps when containers become wider or taller. Test with the text-spacing bookmarklet (https://codepen.io/stevef/pen/YLMqbo/

1.4.13 Content on Hover or Focus – Level AA

When hover or focus states are used to reveal and hide content, the content can be dismissed without moving hover or focus; hover can be moved over the revealed content without a loss of visibility of the content; and the content remains visible until the hover or focus trigger is removed, the user dismisses the content, or the information is no longer valid.

Example:

A standard tooltip (using the ‘title’ attribute) violates most of these requirements. It becomes visible only on hover, you cannot move the hover pointer over the content, and disappears after a pre-set timeout. An accessible tooltip would need to meet the criteria specified. Principle: Operable

Guideline 2.1 Keyboard Accessible

2.1.4 Character Key Shortcuts – Level A

If a keyboard shortcut is implemented using only letter, punctuation, number, or symbol characters, then it is possible to either disable or remap the shortcut or the shortcut is only active when the reacting component has focus.

Example:

A shortcut that requires a non-printable key to activate, such as Alt, Cmd, or Ctrl is not a single-key shortcut. However, the comment navigation shortcuts (j, k, a, s, d, z, u, r, q, and e) in WordPress are single-key shortcuts that could cause problems. They are disabled  on a user-by-user basis and default to off, however, which meets the required criteria. 

Guideline 2.5 Input Modalities

2.5.1 Pointer Gestures – Level A

All functionality that uses multipoint or path-based gestures can be operated with a single pointer without a path gesture.

Example:

A slider or carousel that is navigated by swiping, pinch gestures to zoom in and out on a map, or a value slider incremented only on strict left/right axis operation are examples of problematic interfaces. 

2.5.2 Pointer Cancellation – Level A

For functionality operated using a single pointer, at least one of these is true: execution does not occur on the down event; completion is on the up event, and a mechanism is available to abort or undo after completion; the up event reverses the outcome of the preceding down event, or it is essential that the event occur on the down event.

Example:

The purpose of this criteria is error prevention. Events executed on a down event have no safety exception to prevent accidental actions. The primary example of essential action include keyboard emulations or other examples emulating a trigger action (piano keyboard, shooting game implementations, etc.)

2.5.3 Label in Name – Level A

For interface components with labels including visible text, the accessible name of the component contains the visible text. 

Example:

If the visible text on a button is “Submit”, then “Submit” is a valid accessible name, and so is “Submit the Entry Form” (with “the entry form” as hidden screen reader text.) If the button contained an aria-label with the text “Send the Entry Form”, that would not be valid, as the aria-label attribute has overridden the accessible name and there is no match between the visible text and the control’s name. 

2.5.4 Motion Actuation – Level A

If functionality is activated or operated using device motion, the motion can also be operated using user interface components and the motion actuation can be disabled.

Example:

Features such as “Shake to Undo” or tilt to advance pages may impose barriers to users. A mobility impaired user with a device held in a fixture may not be able to tilt the device; a user with Parkinson’s or Multiple Sclerosis may undo an action unintentionally. 

2.5.5 Target size – Level AAA

The size of the target for pointer inputs is at least 44 by 44 CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. pixels unless it’s: duplicated by another control that meets this requirement; an inline target with a sentence or 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. of text; determined by the user agent; or essential to the information conveyed.

Example:

This is a level AAA criteria, but it is our intention to meet the requirement as well as we can. This primarily effects the size of controls, such as buttons to close modals, tools within the editor, or submit buttons. An example of an essential target size might be when displaying an uploaded image; if the image is smaller than 44 x 44 CSS pixels but is an actionable control, it should be displayed at true size. 

Principle: Robust

Guideline 4.1 Compatible

4.1.3 Status Messages – Level AA

Status messages can be programmatically determined through role or properties such that they can be presented using 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 without moving focus.

Example:

This is an extremely common pattern throughout WordPress. Most status messages can be communicated by using `wp.a11y.speak()`, though in some cases it may be necessary to use an independent handler. ARIA roles such as ‘alert’ or properties like ‘aria-live’ are required to receive messages that will be observed by assistive technology.

How to Meet WCAG (Quick Reference) offers a complete list of all the success criteria and techniques for 2.1. Please help us make WordPress more accessible.

Thanks to @joedolson @afercia and @jillmugge for drafting, editing and providing feedback to this post.

#accessibility, #accessibility-docs

Accessibility Team Meeting Agenda: May 14, 2021

This is the proposed agenda for the weekly 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 on Friday, May 14, 2021 at 16:00 UTC.

  • Accessibility discussion around the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue Post Title Block: add typography formatting options.
  • How to move forward with Proposal: new workflow keyword to exclude tickets until review is needed.
  • Updates from the team’s working groups:
    • Design
    • Documentation
    • General
    • Gutenberg
    • Media
    • 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.
    • Themes
  • Open floor

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, May 14, 2021, at 15:00 UTC.

This meeting is held in the #accessibility 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).

#agenda

Accessibility Team Meeting Notes: May 7, 2021

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.

Updates from the team’s working groups

Only teams that gave updates are listed.

Design

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/

Full Site Editing (FSE)

  • The second Go / No Go Test was cancelled: the list of features that will be included in WordPress 5.8 can be found in the post about Full Site Editing next steps. Here is a list of items included in the scope, shared from the core-editor channel 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. theme building
    • Theme blocks (Query, Navigation, Site Logo…)
    • Template editing within the post editor
    • Widgets Editor & Block Widgets in the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.
    • Persistent List view in the post editor
    • Duotone design tool
    • Gallery block refactor
  • The Global styles “interface” is not going to be included in 5.8, but Global Styles infrastructure which theme authors can use to build their themes is
  • Query Quest Summary for the latest call for testing. A community member did two different keyboard tests.
  • Round two of questions is open until May 12th and the next round of testing on template editing mode will ship on May 12th as well.
  • Template Editing Mode is gearing up to be an important feature most likely for 5.8 so getting testing done there would be very helpful. Tied to this, I expect testing for the Widgets Editor come up soon too. Of note, the current “opt out” approach seems to be through a new classic widgets plugin with more context in Add a plugin to disable the block based Widgets editor.

Documentation

  • The Documentation working group is working on updating the Working Groups page.

General

  • In the last two weeks the Accessibility team checked all Enhancements / Feature Requests tickets, which are due by May 25. It’s seven tickets, so we should be able to get them committed in time.
  • There are also nine tickets marked as Bugs / Blessed Tasks, we’re starting to address them beginning next week, but still prioritizing Enhancements / Feature Requests.
  • Would like to clear the Awaiting Review queue, but will likely prioritize 5.8 milestone.

Media

Open floor

  • The proposal by the team to add a new workflow keyword was shared during dev-chat, and both the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and the Design teams were cross-linked. Feel free to add your thoughts to the post.
  • Because of concurring tasks, @ryokuhi and @alexstine won’t be able to facilitate the Accessibility bug scrub or meeting on May 21. @chaion07 has offered to lead the bug scrub and @joedolson has offered to lead the meeting.

#meeting-notes

Accessibility Team Meeting Agenda: May 7, 2021

This is the proposed agenda for the weekly 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 on Friday, April 30, 2021 at 16:00 UTC.

  • Updates from the team’s working groups:
    • Design
    • Documentation
    • General
    • 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/
    • Media
    • 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.
    • Themes
  • Open floor

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 May 7, 2021, at 15:00 UTC.

This meeting is held in the #accessibility 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).

#agenda

Accessibility Team Meeting Notes: April 30, 2021

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.

Advancement status of TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets, 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 and team’s goals for WordPress 5.8

During the last but one meeting, the team agreed to have a general check on how the team’s work for WordPress 5.8 is progressing: the goal is to keep better track of what areas need more help and to decide if extra meetings or bug-scrubs are needed.

Trac Tickets

Here’s the situation for Trac tickets at the time of the meeting.

  • All tickets milestoned for 5.8 have an owner
  • Eight tickets are Feature Requests or Enhancements and, as such, should be committed in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. by the Feature Freeze date (May 25, 2021); during the bug-scrub before the meeting, the team reviewed all but two of them
  • Nine tickets are marked as Bugs or Blessed Tasks, but there are two extra weeks after Feature Freeze date to commit them

While the team has done a good job at reviewing tickets, more contributors or more time would be of great help to solve these issues. Unfortunately, this is one of the biggest issues that the team is facing, but there’s little that can be done to improve this. Anyway, as the situation is under control at the moment, the team agreed not to plan any extra bug-scrubs.

Gutenberg Issues and Pull Requests

Version 10.5 of the Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party was released on Wednesday, April 28. The second go / no go test for Full Site Editing should have taken place on Tuesday, April 27, but the final decision about whether Full Site Editing will be included in WordPress 5.8 and at what scope was still pending at the time of the meeting. Contributors are invited to monitor the Make WordPress Core blog to check for updates.

More in general, the only accessibility issue included in the list of “WordPress 5.8 Must Haves” issues was solved two days prior to the meeting.

At the time of the meeting, there were 211 issues / Pull Requests with the “Accessibility (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))” label and 77 issues / Pull Requests with the “Needs accessibility feedback” label. Some team members have been asked to review if some of the older issues are still relevant, hopefully they would find time in the near future.

Team Goals

@ryokuhi still have to start updating the page with instructions on how to test Gutenberg for accessibility: updated instructions will be ready at the latest by the Feature Freeze date.

Work on documentation has slowed down a bit and there are no updates, but work on it can happen also outside of the release cycle, so it’s not a big issue.

Open floor

@joedolson asked for feedback on the latest patch in the ticket to Remove infinite scrolling from the media grid.

@ryokuhi posted the proposal to add a new workflow keyword to exclude tickets until review is needed. The Core team was cross-posted and the link shared during dev-chat.

#meeting-notes

Accessibility Team Meeting Agenda: April 30, 2021

This is the proposed agenda for the weekly 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 on Friday, April 30, 2021 at 16:00 UTC.

  • Check advancement status of TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets, 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 and Accessibility Team’s goals for WordPress 5.8
  • Open floor

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, April 30, 2021, at 15:00 UTC.

This meeting is held in the #accessibility 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).

#agenda

Accessibility Team Meeting Notes: April 23, 2021

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.

Proposal to improve usage of keywords and labels on accessibility tickets, issues and pull requests

Add a new workflow to TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets. This will allow the accessibility team to skip a ticket if there is an in progress or not yet developed 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. from popping up in weekly bug scrubs. The proposal post was published on the Accessibility blog. Our request will be brought up in dev chat.

Updates from the working groups

Only the groups with updates to share are listed below.

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/

The following updates were provided by @annezazu for Gutenberg.

  • Check out the upcoming FSE Outreach Program schedule. TLDR: call for questions coming next week + the 6th call for testing is planned to be about template editing and the navigation 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. starting May 12th.
  • Read a detailed post sharing next steps after the first go/no go date. TLDR: various testing calls and refinements need to happen before 5.8’s feature freeze on May 25th.
  • Read the IE 11 Support Phase Out Plan. TLDR: officially removing IE11 support in WordPress 5.8.
  • A PR was merged to add focus on the save button in FSE but there’s some feedback indicating that this is a disruptive flow.

Documentation and Patterns

moved the 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) Pattern Library to its own document. The 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 Update doc was getting substantial.

Media

not much movement. Requesting opinions on  removing infinite scroll.

General

Regarding general, today we still had a look at the Awaiting Review queue, next priorities are:

  • Assign an owner to all tickets in the 5.8 milestone.
  • Go through tickets milestoned for 5.8 and marked as enhancements and feature requests.

Open floor

It was suggested that the team make the accessibility team working groups more visible this way new contributors could find the list and know what each group’s responsibility is.

#meeting-notes

Proposal: new workflow keyword to exclude tickets until review is needed

Following a discussion that started a couple of weeks ago, 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 would like feedback about the possibility of adding a new workflow keyword to TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.. Both the original discussion when the proposal was brought up and the related discussion during the last weekly meeting can be found in the #accessibility 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).

The problem: asking for accessibility feedback too early

It’s very common to add the Accessibility focus to Trac tickets related to new features, in particular those which introduce new interfaces: for example, all tickets related to the About page of the last few WordPress releases have had the Accessibility focus. This allows the accessibility team to check new interfaces early in design and development and to fix problems as soon as possible: this saves a lot of time and energy, so we highly recommend doing this whenever needed.

The issue is that sometimes the Accessibility focus is added “too early”: some tickets with no mockups or where new features still have to be designed or implemented have the Accessibility focus, but they pop up during bug-scrubs week after week even if the accessibility team doesn’t really have anything to review.

This problem becomes very evident when these tickets don’t have an owner, when they are not correctly milestoned (for example, they stay in the Awaiting Review queue), and in particular when the Accessibility Team is not the main driver of design or development of the new feature.

The (possible) solution: adding a new workflow keyword

One of the proposed solution is to add a new workflow keyword to identify these tickets, so that they can be excluded from bug-scrubs until “real” feedback is needed.

A few options for the new keyword were explored.

  • needs-accessibility
  • needs-accessibility-testing
  • needs-ui
  • pending-ui

The first two options should be actively added when feedback from the accessibility team would be needed, but that would almost be identical to adding the Accessibility focus. Using one of the the last two options, instead, would probably be better: such a keyword could be added to mark tickets that can be ignored until they are moved forward.

The accessibility team didn’t express strong preference for one keyword or the other, but a keyword starting with needs- might be preferable for consistency with the other workflow keywords.

The proposed solution is especially important for the accessibility team, where interaction with other teams happens on a daily basis. In fact, the issue we are trying to solve can be more general: whenever a ticket has several focuses, but only one team is responsible of moving the ticket forward, the same situation can arise. If we’re able to find a more general keyword that fits all these similar situations, it might be useful for all teams and can have an even greater impact.

The new keyword, together with proper bug-scrubbing and moving tickets out of Awaiting Review as soon as possible, might improve the workflow not only for the accessibility team, but for the entire WordPress Community.

We would like to hear your feedback regarding this topic: you’re invited to leave a comment below and let us know what you think!

X-post: FSE Program: Bring your questions – Round Two

X-comment from +make.wordpress.org/test: Comment on FSE Program: Bring your questions – Round Two