studio(a11y): caculate background image color and improve contrast checker

[peterpeterparker]

Affected part of DeckDeckGo

• [X] Studio

Feature Description

In #819 we have added a "contrast checker" for the slides' contrast. It works with colors (with or without opacity) but does not yet amend background images.

Use Case

It would be nice, if possible and if performant, to improve the contrast checker with the background images. Maybe it is possible to calculate on the fly an average color but not sure if it would be performant?

Is that possible?

Or maybe deferring some manipulation (image calculation) in a web worker or with some WASM?

[timrodz]

Hi @peterpeterparker - I'd be keen to have a look at this. Any tips on where to look for? What code is affected? :)

[peterpeterparker]

Sure @timrodz that would be awesome - it's quite a tricky one, at least for me so I am happy to get any help!

The contrast check happens in a related component.

As you can notice in the code, it currently only check text information respectively it only search for slot which can contains text.

The slide can contain a slot of type background which contains an image (provide on the slide level or cloned from the deck level).

For example

<deckgo-deck>
    <deckgo-slide-title>
          <div slot="background"><img/></div>
    </deckgo-slide-title>
<deckgo-deck>

The goal of this would be to check if it is possible to query this background and calculate an average color and then use it for the comparison.

Moreover than calculating this color, not also sure how it can be solved with a good performance.

Any hints appreciated and ping me if you have more questions!

[achimoraites]

@peterpeterparker Perhaps this could be used https://github.com/lokesh/color-thief for finding the dominant color and then we can calculate the contrast as we do with any other color.

[peterpeterparker]

indeed @achimoraites looks like it could be a good option, that would solve the feature.

so far, only reserved I've got is the usage of a third party dependency. I like to try to stick to an agnostic approach for our editor. But not sure if that would be possible here though.