read

· · to read
Inaccessibility of CAPTCHA
Various approaches have been employed over many years to distinguish human users of web sites from robots. The traditional CAPTCHA approach asking users to identify obscured text in an image remains common, but other approaches have emerged. All interactive approaches require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users. Research findings also indicate that many popular CAPTCHA techniques are no longer particularly effective or secure, further complicating the challenge of providing services secured from robotic intrusion yet accessible to people with disabilities. This document examines a number of approaches that allow systems to test for human users and the extent to which these approaches adequately accommodate people with disabilities, including recent noninteractive and tokenized approaches.
read

· · to read
How accessibility trees inform assistive tech by Hidde de Vries
The web was designed with built-in features to make accessibility possible; these have been part of the platform pretty much from the beginning. In recent times, inspectable accessibility trees have made it easier to see how things work in practice. In this post we’ll look at how “good” client-side code (HTML, CSS and JavaScript) improves the experience of users of assistive technologies, and how we can use accessibility trees to help verify our work on the user experience.
read

· · to read
Understanding SC 3.2.1 on Focus by Raghavendra Satish Peri
3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A) The intent of this success criterion is to make sure that any unwanted actions are not initiated when focus moves on to an element. For example during tab navigation or shift tab navigation if user focus moves on to a link & a modal is triggered this fails this check point. Here user did not initiate this action; it was initiated when user focus moved on to a particular element.
read

· · to read
Inclusive Content Strategy: How to Ensure Your Content is Accessible to Everyone by Deborah Edwards-Onoro
At the February 2019 Accessibility Talks online meetup, AmyJune Hineline, Drupal and WordPress Community Ambassador at Kanopi Studios, spoke about inclusive content strategy, what it means, and how to craft content that is accessible to everyone.
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.