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