read

· · to read
Avoid Emoji as Class Names by Adrian Roselli
The title of this post is not broad enough. Avoid emoji as any identifier, whether as strings in your script, IDs on your elements, classes for your CSS, and so on. As soon as you start using emoji, you are blocking some users from being able to understand or use your code. It doesn’t matter how popular the technique becomes (or doesn’t).

As a screen reader user, I agree with this advice, but mostly because Jaws for Windows, (“the best-in-class screen reader), pretty much sucks at any language that isn’t written with Latin characters. And quite frankly it’s time for this situation to change. In order to read Hebrew using Jaws, I’d have to call to have a flag added to my serial number to allow for Hebrew and Arabic. I don’t have to do that with my operating system, and I can handle switching my database over so that WordPress will handle actual unicode, which is necessary for expressing anything in any language which is not composed of Latin characters, but when it comes to a screen reader for which I must maintain a license, I essentially have to ask for someone else to handle this for me. That’s crap.

If you want to read or type in Hebrew or any other non-western language on a notetaker, be prepared to turn off your speech and essentially trick the braille display if it exists into accepting Hebrew braille. Turn off the speech because otherwise you can’t think in Hebrew while typing since every notetaker embeds Eloquence, and Eloquence absolutely does not speak Hebrew. Want to interact with Hebrew text on your phone and get braille feedback? Hahahahahahahaha no because even if VoiceOver and Talkback support Hebrew, (VO supports Hebrew and will smoothly transition between it and other languages), braille displays don’t. And braille displays absolutely do not support unicode to any extent.

More broadly, regarding non-western languages and code, I don’t think we should continue to ask developers who are not native English speakers and who also do not speak a language which is expressed in Latin characters to make sure their English is good enough so they can code. That seems like an all too arbitrary requirement to me. So it’s not that I’m disagreeing with Adrian, because he’s acknowledging the reality on the ground, and practically speaking his advice is what we need to follow. I just think the whole situation of coding in general and assistive technology in particular being as incredibly ethnocentric as they are is pathetically stupid.

note
· · to read

If you’re waiting to add accessibility to your projects until your clients ask and pay for it, please rethink your strategy. Accessibility is not a feature. It is not a nice to have. It’s harder to do when you bolt it on after the fact instead of building it in at the start, and the only thing you’re doing with this approach is creating more work for yourself, more hardship for your clients, and a shitty experience for people with disabilities. Please do not do this. Add as much aas you can by stealth if you have to. If your client asks you for some functionality, build the accessibility in without their permission if necessary. If the eclient balks at accessibility, (this does happen), walk away. I’m telling you to do that because I’ve done it myself. I promise you that if they’re balking at accessibility there’s a pretty safe bet they’ll balk at other best practices too, and then blame you when things go south because best practice corners were cut.