These are the weekly notes for the accessibility 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.
Feedback on the CSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. audit being performed by the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-css team
Context: the Core CSS team proposed to launch a CSS audit of WP-Admin in the #core-css channel. They recently asked the design team for input on what they would like to see covered in the audit, and it would be great to also have some input from the accessibility team. They have a bunch of tickets to track everything audit-related:
- Determine methodology recommendations for CSS audit – #49638
- Create a report outline for CSS audit – #49637
- Add visual regression testing to core – #49606
Everyone is welcome to comment on the above tickets.
@afercia shared some general considerations: while an admin CSS audit is extremely necessary, there’s also the risk to overdo and enter the “refactor for the sake of refactoring” territory. He would definitely recommend the css-team to start with baby steps and avoid bigger changes, at least at the beginning.
There are also some CSS properties that are a no-go. For example, all the ones that change the visual order e.g. flex order, flex-direction row-reverse, column-reverse and so on. Also simple things like list-style: none may significantly impact assistive technologies or the way some browsers expose information to assistive technologies.
@joedolson also wanted to ensure we are all on the same page concerning browsers support. @audrasjb answered WP-Admin doesn’t officially supports less than IE11 and @afercia added that it is safe to assume we can remove all CSS related to old IE and prepended with .ie7 – .ie8. See also this Trac ticket for reference.
5.4 post-mortem on Make/Core blog
The WordPress Accessibility team published their position concerning default fullscreen mode on the block editor.
As this change is going to land in WordPress 5.4 –it was announced during the last dev chat– @audrasjb pointed out that the content of the Accessibility Team’post could be used to write a 5.4 post-mortem, and he is going to coordinate with @francina to write this post on Make/Core. It will be a team effort to ensure that all the Accessibility Team viewpoints are captured. @ryokuhi is also available to help on this.
@mapk added he is also organizing some people from Automattic to help wrangle support forums for this release. They will probably have some feedback there.
Accessibility team’s work kick-off for 5.5
The team defined the main projects to focus on for WordPress 5.5:
- Accessible color schemes: Provide some accessible color schemes for WP-Admin. Lead: @joedolson. @ryokuhi also proposed to help on this project.
- Alternative WP List Tables views: Propose an alternative way to display List Tables in WP-Admin – ticket #49715
- “Howdy fly-out menu”: Refine/replace the upper-right WP-Admin fly-out menu.
There are also 29 other Trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets milestoned for 5.5.
WP Accessibility Day update
Next meeting scheduled on Tuesday March 31, 2020 at 16:30 UTC.
