Item — HN Reader

We have 5 badges in total, and 1 of them to points to our integrations test passing. And the integration test do serve an important purpose in making sure we are compatible on multiple different os and don't make a change that would break WSL for example. More info here https://github.com/reflex-dev/reflex/tree/main/.github/workf...

The others are the current latest version, python version we support, how many people are on our discord (A metric to see community activity), and a badge that points to our docs. I think all of these are important but open to suggestions on ones you think would serve a better purpose.

1 comments

They serve no purpose, other than make life hard for disabled people.

I expect tests to always be passing before merging anything.

pypi metadata has the list of supported python versions, in text format

A link to your documentation? Ok but why can't it be a regular link?

I use forums or IRC, so the online users on whatever aren't super meaningful to me personally.

I see thanks for bringing this to my attention, I didn't know that badges caused this problem for disabled people.

We will look into this, I think the info is still important to show but there probably is a better more inclusive way of doing it.

Can you be more specific in your criticism wrt disabled people? It's a lot easier for someone to receive feedback when it's specific, especially when discussing something like a README. It can be helpful to others reading who are on the fence about badges and their ilk, too.

What, specifically, is the issue with the badges concerning accessibility? Most badges I see can be reduced to a div containing two spans and some text, which should be usable with a screen reader. Is there missing alt text, aria attributes, etc?

Re: tests, it comes down to developer culture. It may be acceptable for experimental or alpha/beta versions to not pass tests, live on a separate branch, etc. Distros should be live-testing any packages they ship, too; upstream releases aren't guaranteed to be tested, depending on the upstream you're working with. It's nice to know that the latest commit is actually working without having to double check CI locally. However, tests also aren't created equally. The project author(s) could be learning how to refine their tests, and not actually trust the CI's results (yet).

Can we argue that's sloppy, or that they should've never done that before merging and pushing? Sure. Not sure where it gets us. Actionable feedback and cautionary advice is useful, though.

They can, but are they?

If a test is not working/outdated, remove or fix the test. It's not what the badge is showing anyway.