It's very hard to point at any one tool -- other than the one between your ears -- when it comes to doing accessibility. It's all about good practices, semantics, and other things that computers are actually too stupid to understand or evaluate until you get into high end AI stuff.
It also doesn't help, that the only thing approaching being an official "guide":https://www.w3.org/TR/WCAG21/
Is aging like milk, failing to keep up with technology changes.
For example, take the topic of colour contrasts. Due to "pixel aliasing", "font smoothing" or whatever other hot and trendy term is being used this week for it, the standards of contrast do NOT match up with the rendering norms. Just because you declare #AAFF00 doesn't mean text actually renders that color. cleartype could render it blurred to the background if it's not being hammered into boundaries, Apple's renderer's love of blurring everything could utterly mangle the legibility (even if it "preserves the glyph shape")
, don't even get me STARTED about how freetype can't even render the same character the same way twice on the same huffing page!
To that end whilst tools like webaim's colour contrast checker:https://webaim.org/resources/contrastchecker/
Whilst still useful is outdated in that you need to treat AAA normal as the MINIMUM for a great many fonts regardless of size or weight. Just look at idiotic inaccessible train wreck fonts like "raleway" where even with 100% contrast (literally black on white / vice-versa) it can be insufficient at anything below 16px. Which is why raleway really has no business being used on websites in the first damned place!
In fact, due to the issues of font-smoothing and webfonts, the only RELIABLE way is to make a few sample paragraphs, screen cap them, and zoom in looking for any slabs and bars that are not rendering the declared colour.
Other topics like logical document structure can be tested assuming the site hasn't been pissed on with scripting generated content. The "view document outline" in the "web developer toolbar"https://chrispederick.com/work/web-developer/
Being extremely useful for "legacy" compliance (which in WCAG is all that matters, hence trying to use HTML 5's alleged structural tags can still be considered in violation -- hence the hybrid approach)
often fails to be able to even pull up an outline in scripting heavy sites or those who pull goofy stunts. To that end, if you cannot pull up an outline in that tool I automatically treat the site as non-compliant.
Though this tool:https://gsnedders.html5.org/outliner/
Often works where the toolbar does not, it too has issues with scripting.
But really JS causes all sorts of headaches the way some folks (like the react and vuejs junkies) use it. You've heard me say "good scripting enhances an already working page"?
Scripting by and of itself is NOT an accessibility violation, but what you do with it is. If your forms don't work with scripting disabled, you're in violation. If your main content cannot be accessed without scripting, you're in violation. If navigation doesn't work without scripting... ANY basic functionality you would expect a page to be able to do without scripting that you've coded to require scripting? Doctor, doctor, it hurts when I do this!
Hence why I'm shocked nobody has sued the pants off Twitter or Facebook by now... they are so laden with bloated broken scripttardery that they basically have told every user with disabilities to go **** themselves.
Good scripting ENHANCES
an ALREADY WORKING PAGE
. If you care about accessibility on a project that is the limit of how you can use JS, which is why the "progressive enhancement" approach pays such dividends. Make it work without scripting FIRST, then add scripting atop it to make it better!
It's actually why I started this site a decade ago, was the LACK of resources to teach the basics of progressive enhancement and MSM, which are the fast-track to building accessible sites.
That said, I have a "bucket list" of things that I test for when working for a client. It's the "simple stuff" that if you follow brings you within 90% of what the WCAG is trying (poorly)
to say In a painful legalese
. Said checklist also includes the easiest answers to the problems.Accessible font sizes, area sizes, and breakpoints.
This is simple, measure everything in EM and be done with it.Legible Color Contrasts
Again, webAim's tool is handy, just treat 2.0 AAA as your minimum, and avoid "thin glyph" webfonts like "raleway" that inherently piss on how the renderers work.semi-fluid elastic layout
Fixed width layouts are inherently flawed and prone to causing accessibility woes. DON'T DO IT! Setting a max-width (making it semi-fluid) and measuring everything in EM (elastic) prevents you from making problems you shouldn't have in the first place.There's a reason for some fifteen years I've called fixed width layout, fixed metric fonts, and illegible colour contrasts the "trifecta of web design /FAIL/"Semantic markup
reason HTML even exists in the first bloody place! To say what things ARE
or WOULD BE
in a competently written document for structural or grammatical reasons, so that the user-agent software can best convey that meaning to the user REGARDLESS of if we're talking screen, print, aural/speech, or even future devices we've not even concieved of yet! This is why choosing your HTML tags based on their default appearance is incompetent nonsense, why pissing on the markup with style="" or presentational classes like "navbar-dark bg-dark box-shadow" is incompetent trash -- even if not an accessibility violation in and of itself
-- or any other misuse of HTML is just making everyone's life harder and the fast road to litigation when the subject of acccessibility comes up.
Say what things ARE or WHY
they might recieve a style, NOT
what they look like / what that style is. graceful degradation
When CSS is blocked, what does the page do? When JS is blocked, what does the page do? If images are blocked, yadda, yadda, yadda. Is it still useful to a PERSON on a screen reader or braille reader? (and I mean REAL screen readers like JAWS, not incompetent crap like what's built into crApple products)
If you're using HTML properly everywhere else, 90%+ of what you need to meet accessibility minimums is actually handled by just doing the above things.
Is that REALLY so huffing hard? Apparently to the know-nothing turds who use front-end frameworks in complete ignorance of the most basic principles of HTML and CSS, the answer is yes.
Overall though, it's just another of the many things where until you have AI working like the human mind, I don't think you can make automated tools that just go through a page, find these problems, and fix them properly. The most important tools in this process are learning, logic, reason, and a functioning brain.
Not to mention compassion, which of course is completely lacking in this industry as a whole when it comes to relating to the disabled -- hence the need to get courts and prosecutors involved in making sure the dirtbags who park in handicap spaces and bitch about what an eyesore handicap ramps are have their natural tendencies kicked in the groin.