how does one actually measure a11y? like, some things are obviously bad, but when i'm in doubt i have no actual idea how to investigate it. i have no idea how disabled people interact with technology...
i know there are all these "best practicies" but i have no idea where they come from; how do i simulate a blind/colorblind/bad vision/alternative input methods?
- your browser's devtools: firefox has the Accessibility tab, chrome has the side pane of the Elements tab, the Lighthouse inspector, and some other stuff too (it's kinda all over the place there...). these will give you a breakdown of the accessibility tree by roles, as well as associated properties like names, descriptions, etc - basically the view of your page from the perspective of input and assistive technologies. firefox goes the extra mile with some basic linting checks, a tab order visualization tool, and a vision impairment simulator built in (if anyone knows equivalents for these in chrome, like an extension or something, i'd love to know them).
- the axe suite of tools - there's a bunch of stuff here, like a linter extension for vscode, a browser extension, and integrations with testing tools to check your code for correct semantic structure, colour contrast, accessible labelling, and a bunch more. i've not messed with this super in depth yet, but i know it exists and it's a pretty widely adopted tool so i think it's worth a callout.
- a screen reader: on macos/ios it's VoiceOver, android has TalkBack, windows has Narrator built-in but JAWS and NVDA are also popular options, and on linux i test with Orca. learn to use the screen reader, and try using it to interact with your website as you go. can you navigate where you need to go easily? is the screen reader telling you what you need to know? is it telling you things that aren't important? at the end of the day, these are the tools users will be accessing your website with, and you should make sure your website works with them, just like you would make sure your site works across browsers.
- your keyboard: keyboard use is a pretty important aspect of accessibility, too! try navigating and interacting with your site without touching your mouse. tab around to focus, pgup/pgdn to scroll, enter to interact, space for selecting things like checkboxes. browsers do a pretty good job of making this work by default, but every now and then you might catch something you only have an
onmousedownlistener on that should probably be anonclick, for example. - the WAI resources: W3C's Web Accessibility Initiative are the people in change of defining accessibility standards for the web, and they have a whole load of useful resources on their site. give it a flip through, particularly the stuff for developers and designers. the quick reference in my opinion is super useful, with a bunch of "here's how to do xyz in a way that meets accessibility standards".
- i'll also call out APCA, a new method for calculating contrast between two colours that looks like it'll get adopted as part of the upcoming WCAG 3.0 guidelines. in my opinion, this method is much more useful than the current WCAG 2.2 rules, and has less false positives on poor contrast and false negatives on acceptable contrast. it's not standard yet though, and might not ever be (i'll be surprised if it doesn't get into WCAG 3.0 though), so your mileage may vary with this one.
this is by no means exhaustive! accessibility is one of those things that's really hard to measure objectively, but a little more vibes-based, in that it's more about "does this feel easy to use? am i having a hard time using this site?" than hard, technical pass-or-fail requirements (although that's still a factor!). it's hard to get everything right, but hopefully some of these tools can help guide you to a pretty solid place.
