Discussion: Extending the timeline for higher contrast form fields and buttons

Hi everyone! We recently discussed switching to new, higher contrast form fields and buttons throughout WP-Admin. That thread provided some great feedback, and resulted in an updated direction

This direction is available in the Design Experiments Plugin. It includes: 

  • Higher contrast form fields that mirror 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/ styles. (#47153, #47150)
  • Updated select fields to match. 
  • Updated primary buttons that use #007cba. This passes 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.0 contrast guidelines without the use of an additional dropshadow. 
  • Updated secondary buttons that use a light gray background and a dark gray border to match the updated form fields. 
  • All button variations include new focus styles. (#34904)
  • Updated table & card borders to carry that higher contrast aesthetic out to more of the 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. and create balance.  

This seems like a relatively solid direction, but I’m not convinced it’s the optimal one yet. There are many moving parts happening in the lead up to 5.3 — focus states, button styles, form borders, etc. — and I think we could benefit from taking more time to explore all of our options before we leap on this solution. 

For instance, while this work was happening, @drw158 concurrently explored a new WordPress color palette. This new palette takes a slightly different approach to solving some of the button contrast issues, and also deserves feedback and iteration. Similarly, we should consider directions that involve reducing or removing WP-Admin’s light gray backgrounds to achieve higher contrast and greater consistency with Gutenberg. 

I’d rather we take a fully confident, well-considered step forward than rush into a solution that’s truly only a couple weeks old. For that reason, I think it would be beneficial to hold off on deployingDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. #47153, #47150, and #34904 until after 5.3. This would allow us all to spend a little more time considering the full range of options for the colors, focus states, button styles, and form borders. Once we solidify around a direction, pushing the changes to a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. (either in the Design Experiments pluginPlugin A 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 or elsewhere), to fully test before moving to a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. patch seems like a solid approach. 

This is obviously not solely a design team decision, so I’d like to also ensure 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) folks are on board with this delay as well. Ideally, given a bit more time, we’ll end up with a higher-contrast, more accessible solution for this UI that’s even stronger than the explorations so far.