Screenshots of issues is something we support in many of our paid offerings, but not in axe-core itself. It sounds like the Slack folks implemented their own version of it.
I am one of the maintainers of the axe accessibility testing engine the Slack team is using. It's awesome to see such a detailed writeup of how folks are building on our team's work!
We publish the engine (axe-core) and the "core" playwright integration library Slack is using (@axe-core/playwright) as open source, but if you're interested in what the Slack team has described in this blog, we also have a paid offering called axe Developer Hub (https://www.deque.com/axe/developer-hub) that offers a similar workflow to what the Slack folks describe here: It hooks into end-to-end tests you already have to add in accessibility testing without needing a ton of code changes to your test suite.
It's very enlightening to see which features the Slack folks prioritized for their setup and to see some of the stuff they were able to do by going deep on integration with Playwright specifically. It's not often you are lucky enough to get feedback as strong as "we cared about <feature> enough to invest a bunch of engineering time into it".
I think that even just on private machines, this would make some types of legal compliance needlessly difficult. If you ever need to delete that data, for example to comply with a corporate retention policy or in response to a request from an individual in a jurisdiction that requires you allow doing so, you would need not just to rewrite history but also to ensure that history is rewritten in every clone that any employee has ever made of that repository; there might not even be a record of which clones exist.
I used the Matias Ergo Pro for exactly 14 months. After the first month I bought a second for home. At 13 months (ie, one month out of warranty), the first one started having reliability issues with the quiet click switches failing. At 14 months the second keyboard started failing in exactly the same way, also one month out of warranty. Their support was unwilling to help outside the warranty period.
This is a neat tool, but unfortunately, text art like this generates is extremely unfriendly to folks that use screen readers. If you do use this for comment documentation, consider making sure that there is also a written description above/below it with equivalent descriptive content.
One not-so-obvious accessibility issue with keyboard shortcuts on websites is that if they're too simple (especially single-character), it's easy for them to conflict with assistive technologies like screen readers.
Living in constant fear that a Google algorithm may someday decide to ban our extension without providing a reason, advance notice, or a meaningful appeals process. It feels like there's some new horror story describing this situation at least once a week here on HN.
My team is still using yarn v1 because we want both dependabot support (rules out yarn v2+ and pnpm) and support for overriding transitive dependency versions to force security fixes (eg, yarn resolutions). We would love to explore other options but right now yarn v1 seems to be the only game in town that meets those requirements.
Once npm implements their recently-accepted overrides RFC, we're eager to try switching to that.
If you have general questions about axe-core, the best place to ask is our axe Community slack instance (https://accessibility.deque.com/axe-community). If you have a specific issue you'd like us to investigate, try https://github.com/dequelabs/axe-core/issues