Hacker News Reader

Comment by ecmascript | Hacker News Reader

You should make this as a web service imo.

The trouble with running these sorts of things as a web service is that it often means the assessment has to happen after deployment.

Obviously, it doesn't have to be live. You can deploy to test.example.com and try it out there, but I think that's too late.

Easily detectable poor accessibility should be as much of a closed gate as having the layout go all wonky and the words all in the wrong place.

Ideally, it should be runnable on your local copy as you are writing it, just the same as viewing the page in a browser.

There are web services to add accessibility checks to your CI processes. https://tenon.io is one, Deque has services. Deque makes axe-core, an open source library of accessibility checks that's used by Google's Lighthouse and Microsoft's Accessibility Insights for Web.

This code from IBM uses their own accessibility checklist, I'll be interested to see how it compares to axe-core.

https://www.ibm.com/able/checklists.html

The accessibility-checker package provides CI tools for Node and Karma. These tools started out as server-based checkers about a decade ago, but not all DOMs are serializable and you lose a lot of the CSS context that's needed to do proper evaluation. It's fine for fairly static pages, but has a lot of potential for false positives/negatives.

The tools provide checking for WCAG 2.0 AA, WCAG 2.1 AA and the IBM checklist. The IBM checklist is basically WCAG 2.1 AA, but has some more strict requirements for defining landmarks for screen reader navigation.

FYI - it's possible to run Google Lighthouse against any URL (includes accessibility checking), and there are web services for that.

https://www.webpagetest.org/lighthouse is one example.

Reply on news.ycombinator.com