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.
You can also ask questions during Accessibility Team Office Hours every Wednesday at 14:00 UTC in the accessibility channel in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
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 reviewed the proposal today during the weekly meeting. As we would like to bring this proposal forward, we investigated some possible keywords and would like some feedback on them.
needs-implementation could be a nice addition to needs-design: while needs-design usually involves only the creation of a layout, needs-implementation would convey also the need of an actual implementation to test for accessibility. The downside is that such a keyword would be very similar and difficult to distinguish from needs-patch.
has-accessibility-review (along the lines of has-privacy-review) could be added after a first triage to exclude tickets from scrubbing until extra feedback is needed. The downside is that often accessibility review is a multi-stage process that needs to happen after each UXUXUX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. change, not just once for a ticket: the wording has-accessibility-review might induce to think that everything is done once the ticket is reviewed.
needs-accessibility-feedback or needs-accessibility-review are keywords that could be added when an action from the accessibility team is required. The downside is that similar keywords don’t really add any extra information if the ticket also has the accessibility focus.
changes-requested underlines the fact that the owner of the ticket needs to do an action before the accessibility team (or any other team) can offer feedback on the ticket.
Apart from adding a new workflow keyword, the team also took in consideration two other options.
Differentiating between primary and secondary focuses on TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. might allow teams to distinguish more easily between tickets they are responsible for and tickets where only feedback is needed. Of course, this would require a change to Trac, which is probably complex and could be done only in the long run.
If the reporter or the owner of the ticket doesn’t take any action after a reasonable amount of time, the team will change the milestone of the ticket even if it’s not under their direct responsibility. The team consider this as an extreme option to invite who is monitoring the ticket to take action.
The team would like to have another round of feedback on the (updated) proposal and will review it again in one or two weeks.
Following a discussion that started a couple of weeks ago, 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 would like feedback about the possibility of adding a new workflow keyword to TracTracTrac 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 SlackSlackSlack 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!
WordPress 5.5 is planned to be released on August 11, 2020, with a BetaBetaA 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. 1 on July 7, 2020.
Given the large amount of 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) tickets in the milestone, the accessibility team added few bug scrubs to help moving them forward:
These bug scrubs will be specifically focused on technical issues with TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets and GitHubGitHubGitHub is a website that offers online implementation of git repositories that 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/ issues that are milestoned for WordPress 5.5.
Regular weekly bug scrubs are still planned every Fridays at 15:00 UTC.
During the last weekly meeting, the team discussed the recent change of default to the full-screen mode in the editor. There is a general concern about the usability and 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) implications this new default setting will have.
As a starting point, the WordPress Accessibility team is opposed to this change as it breaks some WCAGWCAGWCAG 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/. success criteria:
Success criteria 3.2.3: Consistent navigation “The intent of this Success Criterion is to encourage the use of consistent presentation and layout for users who interact with repeated content within a set of Web pages and need to locate specific information or functionality more than once.”
Success criteria 3.2.4: Consistent identification “The intent of this Success Criterion is to ensure consistent identification of functional components that appear repeatedly within a set of Web pages. A strategy that people who use screen readers use when operating a Web site is to rely heavily on their familiarity with functions that may appear on different Web pages.”
The main issue is that the fullscreen mode (when it’s activated by default) removes the top bar and admin menus. Navigation should stay consistent in the whole admin experience. There is another similar issue in WordPress admin, but this change happened years ago. This is not a reason to reproduce such a mistake.
If this change is here to stay, it would be nice to add a modal to explain how to restore the normal mode as this is not easily discoverable for the moment.
The current mechanism to exit full screen is a “Go Back” button using the WordPress Logo that sends the user to the posts list. It is worth noting that users are not necessarily coming from the posts list, and the “go back” button (WordPress logo) is not relevant as it takes the users back to a screen that wasn’t necessarily visited before.
There is also a concern about the date on which this change was introduced. If it had been introduced during the development cycle, the Accessibility team could have provided proper information to the GutenbergGutenbergThe 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/ team on the accessibility issues concerning this feature.
This change breaks the rule decided for WP 5.4: new features and enhancements can’t land during betaBetaA 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. cycle. While the full-screen feature itself is not a new feature, the change to including it as the default behavior constitutes a significant change to the 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. and how many users will use the editor. The related ticket was opened and merged only few hours before WordPress 5.4 RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1.
If this feature is going to stay in WordPress 5.4, the accessibility team believes it will need a post mortem on Make/CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. The goal would be to avoid this situation (including changes that late in the release cycle) being repeated in future releases and to make sure important changes introduced in WordPress are accessibility compliant.
Note also that this change was discussed in the #core Slack channel during the March 9, 2020 devchat meeting and the majority of the attendees appeared to be opposed to it. In conclusion @chanthaboune was going to give feedback to the project lead. As no decision has been communicated for now, the accessibility team assumes this change is probably going to stay in WordPress 5.4.
WordPress 5.4 is planned to be released on March 31, 2020, with a BetaBetaA 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. 1 on February 11, 2020.
Given the large amount of 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) tickets in the milestone (around 40 open tickets on Trac), the accessibility team added few bug scrubs to help moving them forward:
These bug scrubs will be specifically focused on technical issues with TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets and GitHubGitHubGitHub is a website that offers online implementation of git repositories that 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/ issues that are milestoned for WordPress 5.4.
Regular weekly bug scrubs are still planned every Fridays at 15:00 UTC.
TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets progress reports and next steps
8 blessed tasks/enhancement, reopened for iteration during BetaBetaA 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. cycle
For easy reference, all admin interface CSSCSSCSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. changes are now grouped under the “5-3-admin-css-changes” keyword.
Next steps
Tuesday 1st, October:
Extra bug scrub scheduled at 16:00 UTCStart to punt defects/bugs without enough progress or still waiting for patch/testing/feedback
Friday 4, October: bug scrub and weekly meeting
Thursday 10, October (5 days before release candidateRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. 1):
Milestone should be cleared
All the approved changes should be ready for release
Any help on the remaining tickets is welcome, including testing current patches. Discussion about tickets/patches/current implementation can happens at any time on the #accessibility channel in Making WordPress SlackSlackSlack 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).
Twenty Twenty 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) focused issues
For now, Twenty Twenty has 20 accessibility focused issues:
WordPress 5.3 is planned to be released on Tuesday 12 November 2019 with a BetaBetaA 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. 1 on Monday 23 September 2019.
Given the large amount of 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) tickets in the milestone (75+ TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets, with 57 still open tickets as of today), two additional accessibility bug scrubs are planned:
Are you an 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) expert? We need your help!
At the moment work is done to improve the WordPress content editor. This project is called GutenbergGutenbergThe 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 goal is to improve the interface and make it ready for the future. The new editor is now available as pluginPluginA 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 and the work is done on GithubGitHubGitHub is a website that offers online implementation of git repositories that 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/.
The accessibility team needs help to safeguard it’s accessibility and we can’t do this alone.
If you are a developer, accessibility tester or work for company that specialises in web accessibility, please help testing or join the work and discussions on Github. WordPress is used by +27% of all websites, so this will have a huge impact on the way people (can) publish on the web worldwide. And we need all the help we can get at the moment.
With great pride the WordPress 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 can announce:
All new or updated code released into WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and bundled themes must conform with the WCAGWCAGWCAG 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.0 guidelines at level AA.
On February 15th, 2016, the WordPress Accessibility Coding Standards were approved and added to the Core Handbook as a part of the code standards WordPress developers are expected to meet when contributing to core.
What does WCAG 2 AA mean?
WCAG stands for Web Content Accessibility Guidelines, created by the World Wide Web Consortium (W3CW3CThe World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/.). These guidelines ensure that people with disabilities can use the web. The current WCAG standards are version 2 and AA refers to the level of accessibility reached. Level A is the most basic standard, while Level AA is used as a reference for a legal standard in many countries worldwide. Level AAA is most commonly only addressed for special dedicated software.
What does this mean for WordPress core?
With every release WordPress gets more accessible for users with disabilities. We’re not there yet — a lot of work still needs to be done on current functionality and interface. We need all the help we can get! The accessibility of the Admin (the administration area of WordPress) is getting better and better. We are researching, testing and fixing accessibility issues in the Admin together with the core developers and our great test team.
What about themes?
The bundled themes, like Twenty Sixteen, already make it easy for you to create a web site that complies with WCAG 2 AA, so when you set up a new installation of WordPress, you’re already on the right track out of the box.
In the WordPress theme repository you can search for themes with the “accessibility-ready” tag. These themes have gone through much the same testing process as the bundled core themes. For every theme with this tag, a member of the WordPress accessibility team has personally checked the theme for keyboard accessibility, color contrast, and a variety of other specific accessibility guidelines. We don’t currently have the depth of reviewers to test every theme update, however, unlike with the core themes, so we can’t guarantee that each theme will continue to meet these standards in future updates.
What about plugins?
The accessibility of plugins is the responsibility of each pluginPluginA 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 author. Neither the accessibility team nor the plugin review team have the resources to review each of the more than 40,000 plugins currently in the repository. If you are a theme or plugin author, please take a look at our handbook for best practices and documentation.
What’s next?
Today, 25% of the web runs on WordPress and our mission is to democratize publishing. That is why we will keep moving forward on the accessibility of WordPress: to give everyone, including people with a disability, an excellent and easy to use tool so they can maintain their own website or application.
During the WCUS community summit 2015 in Philadelphia we made a start with 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) code standards for WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. Joe Dolson put a concept for the a11yAccessibilityAccessibility (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) code standards together (see below or as Google Doc).
These are the standards expected from new code (like feature plugins) at the time it’s to be merged into core. Our target for released code is WCAG2.0 AA.
Proposed place to put them is the Core Handbook: WordPress Coding Standards, we aim for a short list of very basic things with references to the Accessibility Handbook.
Feedback (in the comment section below) is very welcome.
Concept Accessibility code standards for core:
This document is a list of standards that a WordPress feature plug-in should meet for accessibility in order to be merged into core. These standards are focused on best practices and easily testable concerns.
The expectations for all code released in WordPress is conformance with WCAGWCAGWCAG 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.0 at the AA level.
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. Semantics
Headings Hierarchy
Definition of HTML for Controls
Usage of ARIA
Color Contrast
Keyboard Accessibility
Images and Icons
Labeling
HTML Semantics
Take a pragmatic approach to HTML semantics. Don’t add semantics purely for the sake of semantics; but if there is an HTML structure that clearly matches the content, use that element. For example, if you have a group of links, it should most likely use a list element.
Heading structure
The H1 is the main heading representing the page title on every core page. For sub sections, use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup should not be used for presentational purposes.
Use H2 through H6 to give internal structure to the page.
Don’t skip heading levels.
Don’t add extra functionality inside a heading, like links or buttons.
Semantics for Controls
Controls with a native keyboard interaction (buttons or links) are always preferred. If there is a valid target link for the control, either an in-page reference or a link, then the control should use an <a href=”url”>. If there isn’t, it should use a <button>
Related ticket: #26504 Semantic elements for non-link links
Dynamic Content
When there are dynamic changes within a page without a page reload you must provide audible feedback with ARIA for important changes, like a successful saving for example.
[Provide documentation and links for aria-live, wp.speak, etc.]
Color Contrast
In most cases, feature plug-ins are not expected to add or modify colors in core. However, if a feature plug-in needs to add new color combinations, those combinations must meet minimum contrast requirements. Minimum contrast requirements are 4.5:1 for font sizes rendering smaller than 24px or smaller and 3.0:1 for font sizes larger than 24px or 19px and bold.
[in detailed reference, comment on why we’re referencing as pixels]
Keyboard Accessibility
Users must be able to reach and successfully interact with all elements on the page that are actionable, including all form inputs, buttons and links by using the keyboard. They must be able to see a visual indicator of keyboard focus. You should be aware that keyboard events may operate differently when a screen reader is running.
Images and Icons
Any image resource must include an accessible name. An image can be represented by an actual element, an icon font, or an svg element; but any graphical representation is considered an image for these purposes. Different types of elements use different types of accessible names.
For <img> elements, the accessible name should be in the alt attribute. If the img is ornamental, the alt attribute should still be included, but left empty.
For icon fonts, the font icon itself should be aria-hidden, with screen-reader-text in a neighbor element. e.g.
For SVG, the SVG should be inline, so that accessible information isn’t hidden from assistive technology. SVG elements should contain aelement with the accessible name of the image. For cross-technology support, the title element should be associated with the svg element via aria-labelledby. For more information, see http://www.sitepoint.com/tips-accessible-svg/
Labeling
All form inputs must include an explicitly associated <label>
