Hi Adam, I’ve been working on accessibility audits for open source tools with SolDevelo, so I can share a few recommendations based on what has worked well for us in practice.
For general automated testing, I would recommend *WAVE* over *Axe*. From my experience, it gives more comprehensive insights, more detailed reports, and overall a better user experience when reviewing issues. That said, Axe is still a solid tool, so I would treat this more as a recommendation based on usability and reporting quality rather than a strict limitation of Axe. I would also strongly recommend including *guided manual testing* in the process. Many WCAG issues are difficult to catch reliably with automated or semi-automated tools alone, so manual verification is still very important. For that, I’ve found the Chrome extension *Accessibility Insights for Web* especially useful. It includes a set of guided manual tests with clear step-by-step instructions on what to check, what to look for, and what the expected outcome should be. It also provides a few helpful features for simulating conditions that some users may experience. It does include automated checks as well, but in my experience WAVE works better for that part, so I mainly use Accessibility Insights for its manual testing support. *Oobee* is also worth looking into. It’s an open source automated web accessibility testing tool with a CLI, which makes it a good candidate for CI/CD integration. It won’t replace manual testing, but it can still help automatically verify at least part of the ruleset on each build and catch regressions early. If helpful, I’d be happy to share more details or practical guidance on how to approach accessibility testing. Best regards, Damian On 2026/02/23 21:13:09 Adam Monsen wrote: > Welcome, Ali! > > Thanks for your excellent comms here and in FINERACT-2484 > <https://issues.apache.org/jira/browse/FINERACT-2484>. Some of this will be > redundant/review as I attempt to bring a few things together for the > mailing list. > > Please wait until the existing Hugo patch > <https://github.com/apache/fineract-site/pull/53> is resolved before > starting new work on the project website, including a11y (accessibility). I > agree with Aira's comments earlier in this thread as far as what to work on > next. > > The high-level priorities for the fineract.apache.org project website are > > 1. *compliance* (see below) > 2. *maintainability* (improving with in-progress migration to Hugo) > 3. *speed* (no issues here. It is plenty fast, we just need to keep it > that way) > > For compliance, we should > > 1. keep the ASF website checks > <https://whimsy.apache.org/site/project/fineract> green > 2. use valid HTML/CSS/JS markup & code > 3. set and maintain a11y standards > > For valid markup & code, I think HTMLHint <https://htmlhint.com> will help > us keep our HTML valid enough, CSS is OK but we should reduce/simplify/cull > it a bit, and I think we can cull ALL our JS code. Credit to Aira for > introducing me to HTMLHint. > > For a11y, I'm hoping Axe <https://github.com/dequelabs/axe-core> open > source tooling will keep us compliant enough. Credit to Aira for > introducing me to Axe. > > If anyone has experience with the tools I mentioned or strong opinions > about anything above, please speak up. > > I'm not sure about SonarQube. When it comes to our project website, I'd say > just ignore it. I didn't turn it on, I don't know why it recently starting > scanning apache/fineract-site PRs > <https://issues.apache.org/jira/browse/INFRA-22420>, and I don't find it > particularly helpful. If it is FOSS and can be made to be helpful, I'm open > to suggestions! > > See also: reference guide for Apache project web sites > <https://infra.apache.org/project-site.html> > > Best, > -Adam >
