HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dequelabs
axe-core
HTML2015–2026
dequelabs / axe-core

axe-core

Accessibility engine for automated Web UI testing

14Distinct people
14Mentions
0Explicit recommenders
7.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Accessibility engine for automated Web UI testing

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year14 dated mentions

Observed mentions: 2015-06-10 19:46:58 UTC to 2026-02-24 02:15:07 UTC.

01232015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC211
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC211
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC321
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

14 sources
The whitepaper says that the benchmark counted accessibility problems using the tool axe-core (https://github.com/dequelabs/axe-core). It’s too bad that neither the site nor the paper contains any examples of an LLM output and its list of detected problems. I am curious about these aspects: • Which of axe-core’s rules (https://github.com/dequelabs/axe-core/blob/develop/doc/rule-...) LLMs violate most often • Which groups of users are most affected by those rule violations (e.g. blind users or deaf users) • Whether it’s likely that I unintentionally violate those same rules in web pages I write Examples of rule violations and statistics on most-violated rules would make the website more convincing by showing that the detected accessibility errors reflect real problems. It would rule out that the only detected error was a single noisy false
Read the rest
positive rule in axe-core. I bet that most readers are not familiar enough with axe-core to trust that it has no false positive rules.
In WebAccessBench: Digital Accessibility Reliability in LLM-Generated Websites [pdf]
snupix·Oct 23, 2025Submission

Show HN: Open-Source Accessibility Testing for the Web

Our team at Clym built an open-source Accessibility Testing tool to help developers and auditors identify and fix web accessibility issues, combining automated and manual testing in one place. Our tool integrates the open-source axe-core[1] library for automated testing against WCAG 2.0, 2.1, 2.2 and EN 301 549 standards. For issues that automation can't reliably detect, it includes manual review workflows that guide testers through contextual checks (like keyboard navigation and visual contrast validation). It can also generate Accessibility Conformance Reports (ACRs) in multiple formats and allows teams to define their own rules, mappings and remediation steps through a simple configuration layer. You can view and contribute to the project on our github[2] or download the app for Mac, Windows and Linux on our website[3]. We'd love feedb
Read the rest
ack from developers or accessibility testers — especially around how you combine automated and manual checks today, and what integrations would make this more useful. [1] https://github.com/dequelabs/axe-core [2] https://github.com/clymio/accessibility-tools [3] https://www.clym.io/products/accessibility-tools
18 points · Open discussion

Show HN: Evaluate your website usability in seconds

Hello HN! I'm working on a project called desplega.ai, and today we wanted to share a free tool we built to find usability and accessibility issues in your sites. We used our engine for browser navigation (fully custom on top of Playwright) in conjunction with the axe-core engine (https://github.com/dequelabs/axe-core) to find the usability and accessibility issues as we explore your application in seconds. Feel free to try it out and let me know what you think! It's free and there's no sign-up required to see how it works and the live results (we may ask for your email if you want to see a cool report tho, I guess it's fair? :D) Note for vibecoders: You can just use your deployment URL and copy paste the full report to the v0/replit/lovable/bolt chat to fix them :D (shortcut https://app.desplega.ai/demo/landing-1?url=<your_url>) Cheers,
3 points · Open discussion

Show HN: Donobu – Mac App for Web Automation and Testing

Been working on a desktop app for Mac that lets you create web flows and rerun them (https://www.donobu.com/). You can optionally use AI (BYOK: bring your own keys) to create flows for you and to do other interesting things, like making vision-based semantic assertions. Also, your data lives on your own filesystem, and we do not see any of it (further still, there is no phoning home at all). A nice benefit of this being a desktop app rather than a SAAS product, is that if you happen to be developing/iterating on a webpage locally, this has no problem hooking into it. What this intends to be a good fit for: - Testing web pages, especially locally. - Exploring random webpages with a stated objective. - Automating tedious flows. Rerunning a flow won't get caught up on using a single selector (many websites randomize element IDs, for instance
Read the rest
), there is smart failover using a prioritized list of selectors. - Getting a quick draft of an end-to-end test in Javascript. What this is a bad fit for: - Mass web scraping (too slow). - Adversarial websites. What we are still working out: - Click-and-drag operations. - Websites that are primarily controlled from canvas. - Smoothing out UI/UX (we are two backend engineers trying our best, and are handedly outgunned by real frontend engineers). Fun things to try: - Asking it to assert that a webpage has a certain theme. - Asking it to run an accessibility report for a page (uses https://github.com/dequelabs/axe-core). - Asking it to run a cookie report for a page. The tech: - Java 21 for the main business logic. - Javalin 6 for the web framework (https://javalin.io/). - Playwright for controlling the browser (https://playwright.dev/java/). - Axe for running accessibility reports (https://github.com/dequelabs/axe-core). Critical feedback is welcome. Thanks for trying it out! Cheers, -Justin and Vaz
134 points · Open discussion
My experience is that a11y is often not a priority and then one day it is suddenly the highest priority. It is not fun to have to drop everything you are doing and retrofit and/or redesign to avoid a lawsuit or losing a big contract. The easiest thing you can do is run a linter with an a11y plugin to make sure you cover the basics. It can be annoying at first, but you'll get used to it. A tool like axe (https://github.com/dequelabs/axe-core) is good for checking your work and/or automating away some of the less obvious stuff. It provides both a Chrome plugin and an automated checker for CI. Getting comfortable enough with this stuff that it no longer requires a ton of work is definitely a good goal. Your users will have a better time overall and you'll have peace of mind.
In Ask HN: Is accessibility worth it?
Hi I'm not blind but wanna just dump some links here I bookmarked related to accessibility. Might be useful. [1] The actively developed version of Mozilla TTS, named coqui-TTS. My understanding is that the original team was let go from Mozilla and they formed coqui. https://github.com/coqui-ai/TTS They are also on Element Matrix: https://matrix.to/#/#coqui-ai_TTS:gitter.im [2] FOSS automated accessibility testing engine for websites and other HTML-based user interfaces: https://github.com/dequelabs/axe-core [3] Emacspeak, developed by someone who was blind since childhood: https://en.wikipedia.org/wiki/Emacspeak [4] UK government websites are famous for being accessible. They have design guidelines: https://design-system.service.gov.uk/ [5] Similar system for the US govt. https://designsystem.digital.gov/ [6] Mozilla MDN learn accessibili
Read the rest
In WebAIM Screen Reader User Survey #9
Really nice tool, thanks! I'm more a backend developer so I might have some stupid questions: What is your competition and what are you doing better? Update: reading through this thread and a bit web search resulted in the following list: https://ghostinspector.com https://www.testim.io https://www.katalon.com https://www.cypress.io https://github.com/dequelabs/axe-core https://www.mabl.com https://preflight.com > We’re taking a new approach by loading the site-under-test inside of a VM in the cloud rather than rely on a locally installed browser extension. But how would I record and test things locally? I.e. I would need a public setup right at the beginning.
In Launch HN: Reflect (YC S20) – No-code test automation for web apps
Interesting tool! And you've definition given a lot of thought to many of the problems encountered while attempting to do UI testing automation. I've written my fair share of extensive selenium stuff (and appium, but.. let's forget about those painful memories) and one thing that I found fairly "easy' to add to the suites I had written was accessibility testing (using Deque's Axe[0] tools). It literally took a few lines of code and a flag at runtime to enable the accessibility report on my Jenkins/TestNG/Selenium combo. However WCAG is constantly changing and it's hard to keep up, and even Deque is not always up to date AFAIK. Do you have plans to have accessibility testing with your tool ? (even a subset of WCAG's rules) Another thing I've noticed is the jump in pricing from Free to 100 USD/month which goes from 30mins to 6hours. T
Read the rest
his might be steep for a team attempting to test out the validity of the tool against the competition - perhaps offering a first-month discounted trial or something like that would be appealing. I also haven't really seen if it is possible to enable concurrency (for example, is testing on three platforms at the same time for 10 minutes on that free tier possible? I would imagine so if one is doing the lifting with CI like Jenkins - but perhaps you have your own solutions). Tangentially related but you say your tests integrate with various CI solutions, does this mean one can extract the test results in a way that allows further processing and integration into other tools? (I'm thinking of the XMLs coming out of TestNG there). Lastly, I don't know if the time used is counted from the moment you start your VMs or browser starts, or the page is loaded, or the first step is done or something else. Clarifying that might help with a team's estimates (I had internal tests where the struggle was entirely on having the virtual environment/device/browser ready and the test was then a breeze, so the significant metric was the boot-up time). [0] https://github.com/dequelabs/axe-core
In Launch HN: Reflect (YC S20) – No-code test automation for web apps
While I don't yet know a ton about the accessibility software development community, I've discovered Deque Labs[1] while looking into some accessibility tooling. They have really good resources and training around accessibility for the web, and some of the software they develop[2] is incorporated into Google Lighthouse. Their guides and videos might help you get a sense for how other people use alternative access methods to interface with the web. With both the skills to write software and a deeper understanding of the use cases you'll be well-positioned to help improve things for a lot of people - I'm sure it could be tough at times, but stick with it, and best of luck to you. [1] - https://www.deque.com/services/accessibility-empathy-lab/ [2] - https://github.com/dequelabs/axe-core
In Ask HN: I'm a software engineer going blind, how should I prepare?
For web apps you can install the tota11y [1] browser extension and use its experimental Screen Reader Wand feature to get an idea of how a screen reader will interpret elements. tota11y uses Chrome's Accessibility Developer Tools. Deque maintains browser extensions that use their own open source engine [2]: http://www.deque.com/products/axe/#aXeExtensions Both engines could also be used in CI environments to perform a11y audits. That should help web developers target at least low hanging fruit. [1] http://khan.github.io/tota11y/ [2] https://github.com/dequelabs/axe-core
In Ask HN: Any other blind devs interested in working on dev tools for the blind?

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.