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 Notes: March 12, 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.

Meeting time change following Daylight Saving Time introduction

Meeting and bug scrub times will stay the same. Bug scrub at Friday 15:00 UTC and meeting at Friday 16:00 UTC. The day will stay the same on Friday.

Improvement of onboarding for new contributors

Here is a list of ideas that the accessibility team came up with to improve the onboarding process for new contributors to the accessibility team.

  • Add information about the bi-monthly meeting for new core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. to the accessibility handbook
  • Ease participation to tickets and issues with good-first-bug and needs-accessibility-feedback labels: make them more discoverable and improve how to ask for feedback from team members about them
  • Add a Slackbot welcome announcement when someone joins the #accessibility channel 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/.
  • Update the “Get involved” chapter in the accessibility handbook and make the handbook more friendly for new contributors (discussion will happen in the #accessibility-docs channel on Slack)

Open floor

@annezazu informed the team that Taylor Arndt very kindly joined a Zoom meeting to share some feedback around the Full Site Editing experience when using screen readers. Here’s a quick summary of issues to be aware of (she’ll include some of these in a recap post she’s doing for the FSE Outreach Program’s second call for testing):

@annezazu also flagged the following items:

Here are a couple other issues brought up by the team.

If you have time to review/contribute to the new accessibility standards, your feedback is welcome and much appreciated.

#meeting-notes

Accessibility Team’s goals for WordPress 5.7 and beyond

After the release of WordPress 5.6 on December 8th, 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 is already at work to plan the next release.

The 5.7 development cycle hasn’t been defined yet, but a tentative release date was set for March, 9th 2021, a bit less than three months from now. This isn’t really a lot of time: after the release of the first 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., only bugs introduced during the relase cycle can be fixed, with no possibility to add new features or enhancements or to fix bugs introduced in WordPress 5.6 or before. Given that some contributors may slow down their activity during alpha because of the holiday season, it’s probably better not to delay further the discussion on possible targets.

Because of this, the Accessibility Team is going to discuss possible goals for the 5.7 release during the next weekly meeting, happening on Friday, December 18, 2020 at 16:00 UTC 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).

By that time, you are invited to suggest possible goals as a comment to this post, so that it can be included in the discussion.

Given the team decision to create working groups focusing on specific areas of interest, it’ll be up to each working group to set goals and choose targets for the release, but you’re more than invited to share your ideas, take part in the discussion and suggest what to prioritize.

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

Four WordPress releases are planned in 2021 with shorter release cycles: if you think that solving a specific issue or adding a new feature may require work that spans over multiple releases, let us know so that we can try to coordinate and help to get the job done.

If you have any questions, feel free to drop them in the comments or in the #accessibility channel on Slack.

#5-7, #goals

Accessibility Team Meeting Notes: July 24, 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 of 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 marked as accessibility regressions

The first part of the meeting was dedicated to reviewing Gutenberg issues marked as accessibility regressions; it was a continuation of the bug scrub that had started an hour before. In the end, the team analyzed eleven issues and discussed which of them were considered as must-have to be included in WordPress 5.5.

The complete discussion about Gutenberg accessibility regressions (including items addressed during the bug-scrub) is in the #accessibility channel 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/..

Planning of an extra pre-alpha triage session

Following the discussion we had two weeks ago about how to better address accessibility bugs in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and issues in Gutenberg, the team agreed on organizing an extra bug-scrub after WordPress 5.5 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. The scope of the additional triage is to identify easier and self-contained tickets and issues to mark as good-first-bug.

The team agreed to separate the Friday bug-scrub from the extra once-per-release triage: half of it will be focused on WordPress Core tickets and the other to Gutenberg issues.

The suggested time for this extra bug-scrub is Tuesday, August 4th, 2020 at 15:00 UTC, but the team will choose the final date and time and the bug-gardener in charge of conducting the triage during next weekly meeting. If we can’t get through all tickets and issues in a single meeting, a follow-up will be planned.

Updates on WordPress Accessibility Day organization

Organization of WordPress Accessibility Day, the 24-hour event about WordPress and accessibility starting on Friday, October 2nd, 2020, is in progress, but the organizing team asked for some help.

They are looking for people to volunteer as Emcees, moderators, and monitors during the event, and a specific call for volunteers will go live in the next few days.

If someone wants to participate to a greater extent, please join the #accessibility-events channel, where discussion about the event is ongoing and a weekly meeting happens every Wednesday at 16:30 UTC.

#meeting-notes

WordPress Accessibility Meeting Notes for 27 Sept 2019

Meeting transcript on Slack

Progress 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

31 open tickets in the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) focus remaining. There are a total of 138 open tickets in the 5.3 milestone. 6 tickets relating to contrast and focus have been reopened for continuing work. 32 tickets in the accessibility focus have been fixed.

CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. Changes related to link focus style

After the focus and contrast changes, the link focus style is a dotted outline. This is a regression against the previous release, which used a blue glow focus. Discussed options and agreed that switching to a solid outline and adding and outline offset of 2 pixels will improve. Also noted that the admin nav menu is using the same color as the main focus, needs to be reversed.

This change will also need to be ported to 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/, and that may not be able to happen by 5.3.

Off-agenda: discussion on whether we have time to complete changes.

@karmatosed raised a question whether we should focus on moving continuing changes to 5.4 rather than attempt to complete this for 5.3

After discussion, generally agreed that the continuing changes for focus and contrast are minor tweaks, and while there are a large number of tweaks, we should have time to complete them.

Noted that while 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. status closes trunk to new enhancements, tweaks to the contrast changes are bugs, and can continue through the RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. stage.

Next accessibility bug scrub

Next bug scrub will happen on Tuesday 1 October 2019 at 16:00 UTC in the #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.

Twenty Twenty Status

Twenty Twenty has 9 accessibility labelled issues awaiting attention. @poena raised the menus as the biggest concern, needing review. There’s a PR by @acalfieri waiting to land on the menus – we’ll take a look at it after this is finished.

New EU accessibility standards

Note: on 23 September 2019, the first stage of the European Union directive on accessibility of websites and mobile applications came into force. This stage requires all public sector new websites to be accessible. Existing websites have until 23 September 2020 to be made accessible; all public sector mobile apps have until 23 June 2021.

The EU directive uses 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 at level AA as their reference for a harmonized standard.

After WordPress 5.3, we will discuss updating the WordPress accessibility standards to WCAG 2.1. This was last discussed in October 2018, and was inconclusive.

Hackathon automated accessibility testing with Deque on the WCUS contributor day

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 in Nashville, Deque Systems will join 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 a hackathon to set up automated accessibility testing for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., on Sunday, December 9th.

The goal is to include accessibility checks for core, together with the current tests, like Unit and e2e tests and the checks for PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. coding standards we have now.

Deque develops tools like aXe core that can be used for automated testing and they will be sending one or two of their lead developers to work on this with the WordPress core developers.

From the WordPress side we would like to invite core developers to join in and help find solutions to set this up.

Do you know your way around the automated testing system of WordPress core, do you attend the 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/. and do you have time to help?
Please contact the accessibility team in 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/. in the #accessibility channel.

#hackathon

Team meetings September 3 and 10, 2018

Transcript meeting in Slack

Meeting topics

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/ 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) work update by @afrecia

There is a new feature (despite of the feature freeze) “Spotlight Mode”: Andrea addressed some 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) concerns here.

Request from Andrea: please test Spotlight Mode and Full Screen mode for accessibility (keyboard use, screen reader feedback, voice recognition control). They are both merged into the latest Gutenberg release.

At this moment there are still 99 open accessibility issues, 12 of them are labeled Milestone Merge Proposal, so have priority.

Gutenberg AT Manual

@abrightclearweb is working on a Gutenberg manual for 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 (AT). And while writing she also finds new issues which she reports on the 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/ repo. Draft version manual.

It’s a lot of work, help with this is very much appreciated. @Wingo5315 is already helping out.

WP a11y handbook

At the 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/. in 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. Nijmegen attendees reviewed the handbook. We a Google doc and have now 6 pages of comments; @lucp checked for 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./CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. errors, @ireneyoast fixed typos , translation and code errors and @jaapwiering did a huge amount of work reorganising and trying to give more structure to the pages. @rianrietveld will process this in the next few weeks.

A11y review codex/develop

We need to review the code examples in the codex (develop) section of wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. They contain a11y mistakes, and as this code will be copy/pasted a lot, we need to fix them.
Rian talked with Pieter Daalder (@wizzard_) from the docs team. The proper workflow for this is add a comment on the page with the error and pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” in the doc channel that you need this fixed.

Drupal and Gutenberg

Drupal shows interest in using Gutenberg. At the request of Per Andre Rønsen, Rian posted in the Drupal #accessibility channel info about where to find the issues in Github and what the status is. Let’s see what happens.

Project management tool

We are going to research a good project management tool for the a11y team. Other teams use TrelloTrello Project management system using the concepts of boards and cards to organize tasks in a sane way. This is what the make.wordpress.com/marketing team uses for example: https://trello.com/b/8UGHVBu8/wp-marketing., but maybe that’s not accessible enough for our use. An alternative could be GitHub projects.

What we did on a contributor day

Proposal: if you led a team on a contributor day, white a summary about what you did, so we can post it on our blog.

To-do list

  • Test Gutenberg new features Spotlight Mode and Full Screen mode for accessibility
  • Find an accessible project management tool
  • Gutenberg AT Manual: Ask for help from marketing team and users of AT
  • Handbook: Process feedback at WordCamp Nijmegen
  • Codex/Develop: Set up a review of the example code in those sections
  • Write blogpost about impact new recommendation 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 AA for WordPress

Next meetings

  • Gutenberg bug scrub: September 17, 14:00 UTC
  • Team meeting: September 17, 15:00 UTC

Accessibility team meeting, April 9, 2018

Agenda

  1. AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) statement
  2. Handbook
  3. 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/, priorities for 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. London
  4. Contributor drives
  5. Open floor

Meeting notes

Accessibility statement

The WordPress project now has an accessibility statement. We still need to add an ATAG (Authoring Tool Accessibility Guidelines) statement to add to that page. @joedolson will write that, sometime in the near future.

Accessibility Handbook

At the moment @rianrietveld and @samikeijonen are writing pages about how to test for accessibility to add to the handbook best practices chapter, for developers, designers and content managers. This at the request of the Gutenberg team. The pages are in draft now, to be published this or next week.

Gutenberg, priorities for WordCamp London

@karmatosed suggested the following workflow for this:

  • sit down together at 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) table on the 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/. prioritising all a11y issues in a spreadsheet
  • create a solid few weeks plan for accessibility, get everything in milestones, get everything so we all know we’re on track
  • get a ‘hot list’ from that and give easy wins to developers present at  the contributor day
  • leave that clearly knowing what needs to be done for a11y and how help can get there
  • focus on a plan of tasks and that all tasks have enough information to be developed by anyone working on project

Contributor drives

Angela Jin asked us to write up content for their info pages about work that can be done for the different teams during a contributor drive (a bite sized contributor day). @rianrietveld also adjusted the page Getting Started at a Contributor Day for this too.
If a contributor wants to select an a11y task:

  1. Tell the #accessibility channel in 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/. that you are hosting a Contributor Drive and request specific projects and direction.
  2. If you need assistance during the Contributor Drive, ask questions in Slack.

To avoid having to maintain a page with a list of tasks in the documentation of the contributor drive.

Open floor

  • @postphotos came with the idea of organising “contributor drives” in regions across the world, focused on a11y. Like the translation days. He will research this further. We agreed this is a fun idea (wpa11y day?)
  • @arush will publish her research on the screen reader accessibility of Gutenberg this week
  • We had a discussion about adding hreflang to links in translatable strings, like e.g. <a href="%s" hreflang="en"> . Adding the hreflang="en" in the translation triggers a warning
  • We discussed setting a new date/time for the meetings. There will be a separate post about this tomorrow.

 

#weekly-meetings

Changed accessibility meeting times!

Because the regular 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) meeting was at the same time as the design meeting, we rescheduled our meetings.

New times, same place (in the 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/. #accessibility channel)

WPa11y documentation meeting

Attending: @travel_girl, @samikeijonen, @sergeybiryukov and @rianrietveld

Goal of the meeting:

Kickoff meeting for rewriting and reorganising the documentation on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ regarding web 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).
We want the documentation set up so that it’s complete, without duplicates, easy to find and put it on places where people actually will read it.

What we agreed on:

  • We will start with our own handbook
  • In the topic spreadsheet we gather topics and assign ourself to write about them
  • We will add topics as we go
  • We will write in Google Docs (Sami opened a directory for this)
  • We can organise the topic later in a logical way before publishing them in the accessibility handbook
  • We report and discuss our work every Thursday in the #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
  • The goal is to write one topic a week per person
  • When the topics are added to the handbook, we will review the current documentation on wp.org to see where we can ask the teams to replace/add/modify text to prevent double info and to link to better information.

For the topics we want to keep a template, for example:

  • Topic
  • Short intro with:
    • Good Practice
    • Bad Practice
    • Why
    • Exceptions
  • Examples
  • Resources with links

We don’t want to copy all the info there already is on the web, but point to good info and examples.

If more people want to join in, you are most welcome.

#documention