dbjorge

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.

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

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".

If you're interested in building these sort of accessibility tools, my team is hiring! https://www.deque.com/careers/senior-accessibility-tool-deve...

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.

Recommend staying away from them.

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.

This is a neat concept!

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.

Maybe consider including a pointer to https://www.w3.org/TR/WCAG21/#character-key-shortcuts in the docs (and/or as some sort of warning message if a user tries to configure a custom single character shortcut).

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.

Yes, navigation links that don't behave like normal links are also an accessibility problem[1]. That's a separate issue, though; I don't think it is a reasonable argument against supporting reflow based on perceived window size.

[1] https://www.w3.org/WAI/WCAG21/Techniques/failures/F42

I don't think the article is using unclear wording; I think it is clearly arguing the exact opposite of what you're describing. I think the clearest demonstration of this is the concluding section, where the author specifically talks about using "is desktop/laptop" as a preferred alternative to breakpoints that are based on window size.

This article starts with a pretty big assumption:

> Now, I think we can all agree that, on our desktop computers, we prefer viewing the full-width layout of most web pages.

This assumption is not reflective of current accessibility research. For folks that regularly use browsers at high zoom levels, it's important for content to be able to reflow even on a desktop computer. This is disproportionally impactful for older seniors, who might struggle with instructions like "remember to put an m. in front of the url".

WCAG 2.1 success criterion 1.4.10: Reflow is a good starting point for learning about this: https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

The article explains the technical details of the render process escape. Contrary to all the current replies to this comment, it does not look to me that this is using a generalized Electron escape; rather, it is using specific main/render IPC calls which Teams has implemented unsafely as the escape mechanism. Perhaps folks are confusing this with an electron sandbox issue because Teams happens to have called the variable containing their IPC APIs "electronSafeIpc".

I work for Microsoft on a moderately complex chromium extension. We've investigated porting it to Firefox (we've had a small but nonzero minority of users ask about it, and several of our engineers have a personal interest in it), but it's really hard to estimate ahead of time how much effort it's going to be. Most of the issues are not so bad to fix individually, it's just an unknown-length onion peeling exercise. It's especially challenging when a library/framework you use is impacted by a difference and its maintainers aren't motivated to improve compatibility; some examples of this we've run into include "Firefox's RegExp implementation doesn't support named capture groups" (but the library author doesn't want to make the code less readable by not using them) and "Firefox's auto-size behavior for extension popup UI (what you see when you click am extensions toolbar icon) sometimes sends spurious window resize events when the DOM is modified" (the UI control library we use has behavior to dismiss context menus on window resize, which this breaks).

The most painful incompatibility I've read about was in the Bitwarden extension, which basically doesn't support most operations in Firefox private windows because Firefox intentionally doesn't support getBackgroundPage() from there, and Bitwarden architected their extension to use that for all IPC between their frontend and backend layers. You can avoid that incompatibility by using runtime.sendMessage for that purpose, but they didn't know that at the time they wrote it (there's a warning about it in the MDN docs for getBackgroundPage now, but that warning wasn't there at the time). We happened to have gotten lucky in our extension in that we use sendMessage for the same purpose, but we certainly didn't know about that incompatibility at the time we were making the architectural decision.

Beyond just making it work, our team would also want to be able to automate regression tests against Firefox if we were to officially support it. For a long time, selenium was the most realistic option for that, but we switched away from selenium to puppeteer a year ago due to reliability issues with the former. Now that Firefox support in puppeteer is very recently starting to stabilize, we're hopeful we'd be able to use that, but we haven't tried it yet and it's new enough that we wouldn't expect it to be fully compatible/stable yet.

The article notes near the top that extensions are supported, and also answers your other questions.

On Android I use an app called Materialistic, which has a dark mode

Highcharts has put a lot of effort into designing charts to be accessible. They did a presentation about it at my workplace a few months ago and I was impressed by the passion and level of user testing they had done.

https://www.highcharts.com/docs/accessibility/accessibility-... is a good starting point to learn more about the sorts of features and considerations they've made (you can find articles, demos, and videos describing more from there)

My team at Microsoft maintains an open source browser extension for this called Accessibility Insights (https://accessibilityinsights.io), which is what Microsoft recommends internally for its own teams developing websites.

It offers a fast 5 minute scan for some of the most common/easily detectable issues, and also a much fuller assessment with a mix of automated checks and guided/assisted manual tests that aims to help web developers who aren't accessibility experts achieve full WCAG 2.1 AA compliance.

Happy to answer any questions about it!

The most popular FOSS screen reader by a very, very large margin is NVDA (https://www.nvaccess.org). It is Windows specific, though.

Rolling your own CAPTCHA is very, very likely to introduce accessibility issues for your site. It is the accessibility equivalent of "rolling your own cryptography" for security. Among surveys of screen reader users, CAPTCHAs are regularly listed as the single most frustrating part of trying to use web sites via assistive technology.

Even if a CAPTCHA does offer a non visual alternative, it is very common for it to be inaccessible for folks with cognitive disabilities (eg, dyslexia) or motor impairments. Another common issue is assuming that users all speak English fluently. In this example, "beauty" is likely to be sufficiently culture specific to cause localization challenges.

https://www.w3.org/TR/turingtest/ is a good resource for learning about the accessibility implications of many common types of CAPTCHA implementation.

There are lots of options for automated accessibility scans, but there are many common accessibility issues that aren't feasible to test for with automation.

My team at Microsoft recently open sourced a tool called Accessibility Insights (https://accessibilityinsights.io). The web version is a chromium extension that includes both automated scans and also a guided assessment option that leads you through how to test for and fix the stuff that has to be found manually. This is the tool Microsoft pushes its own teams to use as part of their release processes.

Microsoft recently open sourced[1] one of the main tools they use for web accessibility testing.

Accessibility Insights for Web (https://accessibilityinsights.io) is a Chrome extension that guides you through doing an accessibility assessment of a website. It includes a combination of automated checks (using aXe[2]) and assisted/guided manual checks. Its rules are based on the W3C Web Content Accessibility Guidelines[3]; passing a full assessment in the tool amounts to meeting all the "A" and "AA" WCAG 2.0 requirements.

Like other commenters have mentioned, automated checks (like aXe) are a great start, but aren't really sufficient on their own. Accessibility Insights will lead you through how to test different aspects of screen reader usage (and other types of accessibility issues, too!). It will also help you track issues as you go, and produce a pretty report at the end that you can attach to a bug.

As with most types of UI testing, no matter what tools you're using, there's really no substitute for watching a real user try to use your product.

Disclaimer: I am an engineer that works for Microsoft on the Accessibilty Insights team.

[1] https://cloudblogs.microsoft.com/opensource/2019/03/12/micro... [2] https://www.deque.com/axe/ [3] https://www.w3.org/WAI/WCAG21/quickref/