ruby

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 onmousedown listener on that should probably be an onclick, 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.

got nerdsniped yesterday, in the process of trying to determine what the Capital C Correct way to implement the following UI is, in both a semantically correct and accessible way:

Success

yeah i know, bad colour contrast, shhhhh thats not what this chost is about

seems pretty straightforward, right? an icon, and some text next to it. how hard can it be? i mean, i just did it right there. surely it can't be that difficult.

turns out the actual specifications are surprisingly vague on this.

context: this whole godforsaken issue

EDIT: i've spun up a place to organize the fork i talked about in this post

i think it's pretty clear at this point that the yari repo is compromised. if people with push access are going to actively ignore community criticisms and forge ahead with their own plans, i don't see how we can trust that it will be maintained in the best interest of it's users.

it seems to me that the content itself is fine - i haven't seen any evidence to the contrary, and dear lord i would hope we can still trust that content. luckily, the content and the platform seem separate enough that it looks like it would be viable to fork the platform while still consuming the same content. i think this is the best course of action.

now comes the tricky part: actually getting the ball rolling on a fork. i guess this is a call to anyone reading - is there interest in maintaining said fork? is this something that people want? i'd like to pick this up, but there's not much use in forking if no one else actually wants to. or maybe someone's already started an effort, and i've not heard of it yet - in which case point me over, i'd love to help out.

i feel like this is the point where a lot of forks struggle - initial community organizing/building. in the chaos, it's not very hard to plant your flag down somewhere - but it is difficult to get everyone to see it, especially if there's multiple flags and no one knows which flag to go to. and when the forking process relies on accumulating a critical mass of users/contributors to move over, it's pretty difficult to get a fork established.

i hope we can do it. the web needs a place we can trust to get information on how it all works. unfortunately, mozilla's pretty definitively demonstrated that they either cannot, or are not willing to maintain that.