The AccessibilityAccessibilityAccessibility (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 shares accessibility expertise across the project to improve the accessibility of WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and resources.
BlockBlockBlock 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.
WordPress Design Team confirmed this design is meant to become the default for any future admin page.
The AccessibilityAccessibilityAccessibility (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.
The “more” button icon (three vertical dots) purpose is not very clear.
The current headerHeaderThe 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 UIUIUI 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
First, the way .screen-reader-text is documented is inconsistent – it’s a mix of saying “this is the CSSCSSCSS 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 HTMLHTMLHTML 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.
@nataliemac is looking for volunteers who will be at WordCampWordCampWordCamps 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 SlackSlackSlack 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.
The documentation working group will have a one time meeting on February 22nd at 17:30 UTC. We are going to discuss finalizing the structure of the Handbook as well as discuss strategy going forward. If you are interested in getting started with documentation this will be a great time to join in!