read

· · to read
The Anatomy of Accessible Forms: The Problem with Placeholders by Deque Systems
Instructions help users to submit forms successfully. However, if the instructions are provided with a placeholder attribute, then the user might not be able to use that instruction effectively.

Yet another example of the need for HTML elements and attributes to be used as intended by the specification.

read

· · to read
The difference between keyboard and screen reader navigation by léonie Watson
People often include screen reader users in the much larger group of keyboard-only users. Whilst this is correct (most screen reader users don’t use a mouse), it also creates a false impression of the way screen reader users navigate content.

This is a really good primer for anyone building things for the web as well as screen reader users on the differences between screen reader and keyboard navigation. I’ve seen lots of situations where the two are conflated, by both developers and screen reader users.

Also, I really like the footer text on léonie’s site.

read

· · to read
( )

I still think it’s pretty messed up that, for the purpose of getting the topic of equal access for all on the web some play, we have to refer to the benefits for search engine optimization, (most of which are myths), because that’s the only way most people are going to pay attention. It’s either that, or try scaring people by reminding that eventually, they won’t be fully abled. I get it, I’m not going to stop doing it, but it’s still one of the less-desirable, less-lovable parts of accessibility for me.

read

· · to read

This essay from the Hoover Institute is worth a read for anyone discussing either online speech in general or the embarrassingly wrong pieces on Sec. 230 which have appeared in both Vox and the Washington Post in the last few days. Click here to read the full version in as accessible a format as possible without having to download the document yourself and tag it.

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.