Skip to content

Improving the traffic light system for colour blindness #526

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
K-Meech opened this issue Mar 12, 2025 · 6 comments · Fixed by #531
Closed

Improving the traffic light system for colour blindness #526

K-Meech opened this issue Mar 12, 2025 · 6 comments · Fixed by #531
Labels
accessibility Something relating to the ease of accessibility (alt-text, colour choices, language, etc) bug Something isn't working documentation Improvements or additions to documentation good first issue Good for newcomers website Related to https://github-pages.arc.ucl.ac.uk/python-tooling

Comments

@K-Meech
Copy link

K-Meech commented Mar 12, 2025

Which Section of the Documentation Needs Improving?

The sections involving red/orange/green traffic lights such as the home page / pages for linting, packaging etc..

What Can be Improved About This Section

The traffic light system provides an easy to understand ranking of the different options, but presents some issues for people with colour blindness. The most common type of colour blindness (red / green) would make it difficult for people to distinguish the red/green traffic lights on colour alone, and other colour blindness types could make it difficult to distinguish all of them.

How to Improve This Section

In the tables of ranking (for example the linting one) - would it be possible to provide another way to distinguish the categories? For example, text indicating the different groups, or potentially having the traffic lights as different shapes (like a green tick, red cross...).

@K-Meech K-Meech added the documentation Improvements or additions to documentation label Mar 12, 2025
@samcunliffe samcunliffe added bug Something isn't working website Related to https://github-pages.arc.ucl.ac.uk/python-tooling accessibility Something relating to the ease of accessibility (alt-text, colour choices, language, etc) good first issue Good for newcomers labels Mar 12, 2025
@samcunliffe
Copy link
Member

samcunliffe commented Apr 11, 2025

I pinged UCL's Digital Accessibility team. They are going to take a general look at our pages, but in the meantime, they had some specific, signposted suggestions for this.

To answer specifically about the traffic-light indicators, the most accessible approach would be to include descriptive text as well, as best practice is to avoid having colour/shape/size as the sole means of conveying information, and using plain text is the safest way to ensure screen readers can also access it.
[...]

Our team has published guidance on visuals and use of colour, which discusses what to avoid in colour schemes, but I'll just drop in a few more links about colour and accessibility with specific suggestions included:

In particular the second link has a few nice images.

Here's a good illustration of the problem:

Here's a nice option:


So a couple of options spring to mind...

  1. Stick with emoji only but make them not be traffic light colours: ✅ ➖ ❌
  2. Stick with emoji and traffic light colours but add shape: 💚🟠⛔️
  3. Another set of emoji that are not traffic lights: 🙂😐☹️ or 👍👌 👎
  4. Go with something like above: colours in the background of cell of the table, but also include a word describing our opinion: "Best", "Good", "Avoid"

Though technically the most fiddly (we'd have to do some CSS 😱 ) I wonder if option 4 is the best because we can use a word in plaintext

best practice is to avoid having colour/shape/size as the sole means of conveying information

And for us "amber" is actually an OK tool:

We don’t discourage using this, but it may duplicate functionality of a green tool.

So it's more of a "Best", "Good", "Avoid" kinda situation.

@samcunliffe

This comment has been minimized.

@paddyroddy
Copy link
Member

Though technically the most fiddly (we'd have to do some CSS 😱 ) I wonder if option 4 is the best because we can use a word in plaintext

Why is that the best? I would prefer emojis and would work better in dark mode

@samcunliffe
Copy link
Member

Well, "Best" == most accessible, because that's what the accessibility team said...

the most accessible approach would be to include descriptive text

But I think the point is: there's a plaintext thing that will appear if all emoji fails to render or can't be handled. (Like in screen readers for sight-impaired people)

@samcunliffe
Copy link
Member

@all-contributors please add @K-Meech for bug, a11y, review

Copy link
Contributor

@samcunliffe

I've put up a pull request to add @K-Meech! 🎉

samcunliffe added a commit that referenced this issue Apr 29, 2025
…c's labels. (#531)

An attempt to solve

- #526 

by replacing the emoji (same shape different colours) with a
[JustTheDocs
label](https://just-the-docs.com/docs/ui-components/labels/) UI
component.
Unfortunately, the JTD-flavoured markdown syntax for this is 

```md
Good
{: .label .label-green}
```

... that is to say: it needs two lines. And obviously, this doesn't work
inside markdown tables.

But once upon a time, I learned some HTML 🙃 so we can also access them
as
```html
<span class="foo"></span>
```
 tags.

----

Now! This makes the markdown not look as beautiful/colourful/emojiful
when viewed in GitHub...

![Screenshot 2025-04-11 at 16 07
24](https://github.com/user-attachments/assets/ba17275a-6169-40ca-b481-009adc5dffce)

(though arguably more readable... which is perhaps the accessibility
point.)

----

Here's what it looks like on the built pages:

![Screenshot 2025-04-11 at 16 04
10](https://github.com/user-attachments/assets/227dcafa-2e8f-4385-9595-f10807796ebb)

![Screenshot 2025-04-11 at 16 04
17](https://github.com/user-attachments/assets/893e1d5e-0445-4838-946a-8a6ab9ec85a6)

---------

Co-authored-by: Patrick J. Roddy <[email protected]>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Something relating to the ease of accessibility (alt-text, colour choices, language, etc) bug Something isn't working documentation Improvements or additions to documentation good first issue Good for newcomers website Related to https://github-pages.arc.ucl.ac.uk/python-tooling
Projects
None yet
3 participants