
Equal Access: Automated accessibility checker for web projects - iovrthoughtthis
https://github.com/IBMa/equal-access
======
mfontani
Automated tools are all fine and dandy and I like to use them.

A pet peeve of mine is that "red on white" is considered bad while being, in
fact, perfectly legible:

> Element has insufficient color contrast of 3.99 (foreground color: #ff0000,
> background color: #ffffff, font size: 9.4pt (12.6px), font weight: normal).
> Expected contrast ratio of 4.5:1

I think whatever algorithm is used to determine contrast is deeply flawed for
some colour combinations.

I remember reading an article here on HN about how luminance (or luminosity?)
varied in a way that wasn't easily discernible by inspecting the RGB
components of a colour and how there was a different (much harder) algorithm
which instead ensured luminosity could be taken into account when picking
colours for a site.

I'd wish accessibility tests used _that_ instead of taking the easy way out
and using known-flawed RGB checks.

~~~
fluffybucket
Could it be because it is accounting for people who are colorblind?

~~~
GordonS
I'm colour blind, and red on white is totally fine for me as long as the red
is dark enough. Actually, any colour on white is OK if it's dark enough.

~~~
mfontani
Thank you for that. Could you confirm whether "pure red on white" is okay for
you, or whether it's too light?

i.e. #ff0000 on #ffffff

~~~
GordonS
Just checked and I'd prefer it just a touch darker (#dd0000), but as long as
the font weight isn't too light, I think it's OK.

There are different forms of colour blindness - I have the red-green type
(though can't correctly identify many colours), but I don't think it should
make any difference for this.

------
some_furry
This looks extremely useful.

Ensuring that websites are accessible is important work. I used to work at a
company where the CTO personally dedicated several sprints to refactoring the
display layer code to better support screen readers. From what I remember, it
was a bit of a tedious process, but nonetheless one appreciated by all of
their customers who had disabled staff.

Tools like this could save a lot of time and make the web more accessible.

------
josefresco
For WCAG work, I use and highly recommend WAVE
[https://wave.webaim.org](https://wave.webaim.org)

~~~
dallascoop
WCAG's api just shows the no. of errors per type. Do you run it on your own
servers and does it give more info that way?

------
gregod
I have also found
[https://accessibilityinsights.io/](https://accessibilityinsights.io/) from
microsoft to be usefull. It only covers the in-browser test side for web but
has a nice ui.

------
Vinnl
I'm not entirely sure if it's the same use case, but I think the de facto tool
here is axe: [https://www.deque.com/axe/](https://www.deque.com/axe/)

(IIRC, it's also integrated in Webhint and Google's Lighthouse.)

------
avontell
Automated accessibility testing for Android - both static and dynamic
accessibility issues, all automated with little to no setup:
[https://github.com/vontell/Bility](https://github.com/vontell/Bility) (all
open source too)

~~~
avontell
Identifies color issues, keyboard, and user interaction issues, etc... by
building up a state diagram dependent on a user's simulated abilities.
Generates a report based on WCAG 2.0 specs.

~~~
avontell
With some help from others, it is also extendable to other platforms like Web
and iOS

------
ggurgone
Amazing, I had a similar idea last year and I am glad a corporate actually
built this [https://giuseppegurgone.com/automating-accessibility-
tests-p...](https://giuseppegurgone.com/automating-accessibility-tests-
puppeteer/)

------
gnicholas
PSA: Global Accessibility Awareness day is tomorrow (Thursday) and will be
mostly celebrated on twitter under #GAAD. Most years there are in-person
events all over the world.

------
brightball
Very cool. It’s hard to find good tools to ensure you’re staying accessible
once you’ve made the effort to get there.

------
ecmascript
You should make this as a web service imo.

~~~
extra88
There are web services to add accessibility checks to your CI processes.
[https://tenon.io](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](https://www.ibm.com/able/checklists.html)

~~~
thbrunet
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.

