The focus style for the element template chooser list view has a too low color contrast

[rpkoller]

Describe the Bug
If you take a look at the screenshot on the projects description page (same is reproducible when actually using it)
https://github.com/bpmn-io/element-template-chooser/blob/master/resources/screenshot.png you notice that the grey focus style for the template selected has a background color of #EDEEED while the background has #FEFFFE which leads to a color contrast ratio of 1.2:1 but the goal should be >= 3:1(WCAG21 SC 1.4.11). That way the focus isn't visible or makes it had for people with lower vision to determine which element among multiple elements has the keyboard focus (SC 2.4.7)

Environment

• Library version: "@bpmn-io/element-template-chooser": "0.0.1"

[smbea]

cc @andreasgeier

[andreasgeier]

@currandwyer

[currandwyer]

This is a tricky issue, because if the hover state background is too dark, the text above also becomes less legible. Still, we could tweak it.

The current state of the design includes an additional icon. This icon links to external documentation, while helping to mark the hover state for a11y purposes. @andreasgeier what do you think about making the hover state background color g-225-10-95 a bit darker?

[rpkoller]

indeed a tricky problem. i've used the element template chooser only in the context of ECA on Drupal. there we dont have for example the link to external documentation.

but taking a look at your screenshot it has a bit of modified styling compared to the screenshot from the description page i've linked in the initial page as well as the out of the box version of bpmn.io i've actively tested on. there the title and the description are both blackish in your linked exampled here you have a greyish description. that fails the SC 1.4.3. regular sized text has to have a ratio of 4,5:1 while large sized text aka 24px or bold with 18,5px has to have a ratio of 3:1. so you have to keep SC 1.4.3 in mind as well unfortunately :/

and in regards of finding the appropriate focus color those two constraints have to be met for SC 1.4.11:

• The area has a contrast ratio of at least 3:1 between the colors when the component is focused and it is not focused.
• Where the area is adjacent to the component, it has a contrast ratio of at least 3:1 against the component or a thickness of at least 2 CSS pixels.
  (means the background color for the focus has to have a color contrast of 3:1 to the one the regular background in the template chooser has. and the second constraint is automatically met in that case)

but one question about your suggested color. is that in the hsl format? g-225-10-95

but i suppose when an element in the list gets into focus its background-color, color of its title and description as well as the color of the external documentation icon has to be changed to get the desired results.

[nikku]

@rpkoller For a little bit of background on different screen showcased (#7 (comment)): We'll ship some updates to our element template foundations as well as this library in the near future.

We'll end up with something like #7 (comment); you'll be able to

• Provide (optional) icons with your element templates
• Provide (optional) link to a documentation URL with your templates

Your input on A11y topics is really apprechiated, here and in other issues you've raised. We'll do our best to incorporate these hints as we move forward :).

[nikku]

Moving to backlog for the time being. We'll revise a11y feedback we get in the near future.

[rpkoller]

@nikku ah cool thanks for the headsup! that means the screenshot provided refers to a future state of the layout of the element chooser - its taken from the dev branch?

out of curiosity is the same icon used and applied for each element or are there different images for every element or a group of elements? in case it is the same icon for each element then it might be a good idea to mark those icons up as decorative with alt=""so they get ignored by assistive technologies. in case icons are for a group of elements each then that directly relates to #5 - meaning if there is some sort of grouping and segmentation implemented based on issue 5 then the icons could be marked up as decorative as well imho otherwise it might be discussed if some sort of alt attribute value is needed. but that brings up again teh groundhog day problem if you have several elements with the same icon in a row #5 (comment) . and in case each element has its own icon i would tend to label it as decorative again. the icons are way too small to convey an individual meaning which isnt already communicated in the element title and or the description.

and about the optional link that is an excellent idea and improvement in general. unable to check right now in an installation to label the optional link with an aria-label that the user knows the purpose of the link and where it is heading. because just having and icon without and text is the similar case like the read more... text.

[nikku]

We're updating to modern popup menu foundations (#14). Any a11y improvements now contribute directly to the core