Display an overarching 'theme accessibility' notice which directs users to any blocks that may have colour contrast issues

[thatisrich]

What problem does this address?

The colour contrast notification displays a notice within a block / element when its selected colours do not meet the AA contrast ratio, however this notice is only visible when viewing that block / element.

Displaying a Themer-wide notification that directs users to any colours that may need updating could bring accessibility issues to the surface, making them easier to address.

What is your proposed solution?

Using a variation of the proposed custom colour contrast component, a notice could be displayed within the layout grid like in this quick mockup.

As outlined here, this example mockup will need refining to ensure it fits the use case correctly.

[PaulREnglish]

@thatisrich @g-elwell How should this work? I'm thinking it loops through the theme config object and checks every background and text colour combination it can find then tells you if there are any issues. This might be quite a complicated implementation though so keen to get your thoughts.

[thatisrich]

I believe this was my initial thought, too, but it could be quite the overhead.

Brain dumping a little, I wonder if an Accessibility context approach could work here? As colours are set / selected, the combinations are added to the context and then those colours are the ones compared. It's only really reliable to compare background and text colours that are set, skipping unset colour values, and checking all the possible values across the config could slow things down. Having only the components and their colours that need to be compared being queried should make things cleaner?

[PaulREnglish]

I believe this was my initial thought, too, but it could be quite the overhead.

Brain dumping a little, I wonder if an Accessibility context approach could work here? As colours are set / selected, the combinations are added to the context and then those colours are the ones compared. It's only really reliable to compare background and text colours that are set, skipping unset colour values, and checking all the possible values across the config could slow things down. Having only the components and their colours that need to be compared being queried should make things cleaner?

I could be wrong but I think React context will have limited success. Your approach would work for new colour combinations set by the user. But if there's already existing problematic colour combinations, this approach won't pick them up because the offending React components will never be loaded into the page and thus not have the opportunity to add those colours to the context.

But maybe it's ok for the notice to only warn you about problematic unsaved colour combinations?

[g-elwell]

A combination of both suggestions would likely work. Checking the entire styles object on load, then reacting to onChange events from colour pickers, rather than continually parsing it.

[thatisrich]

I was thinking the same. I wonder if we could possibly even store an accessibility object in the database that stores the initial full scan to reduce the load of needing to run it on page load each time? It could be quite handy having options moving forward to store accessibility related data that isn't just colour, for example font size, but it may be overkill.

[g-elwell]

I wonder if that might be over-complicating things / worrying too much. Parsing an object once shouldn't cause much overhead, especially since we'll be skipping a lot of it, and I think the complexity of keeping things synced with the database could introduce a different set of problems.

Perhaps a custom store would be a good shout though. Similar to context but will be much more flexible and extendable should we wish to add more data, sync to the database, etc.

I don't want to expand the scope of this issue, but I have often thought that the data management throughout this plugin would be much easier to manage (and more performant) if it used a store. We could get one set up here and migrate other pieces of data across as and when.

[PaulREnglish]

Thanks guys. A combination of both suggestions plus the custom store should work wonderfully.