Domino’s asks the Supreme Court to shut down a lawsuit requiring its website be accessible to blind people by Nick Statt
Domino’s is arguing the requirements would be inconsistent and costly

One more time for the folks in the back. Accessibility guidelines and a metric ton of supporting documents with examples along with easily findable mailing lists with every accessibility practitioner on the planet providing help and advice on accessibility for free every single day have been around now for twenty something years. There’s also Twitter, where those same practitioners have been providing free help for something like ten years every day. This isn’t hard. And a multi-million-dollar company to complain about paying $38,000 to fix their website so that it’s accessible to everyone is crap. Dominos wouldn’t be charged $38,000 to fix things if they had, wait for it, built accessibility in from the ground up. Stuff like this is why people with disabilities are practically in “sue them all and let God sort it out” mode. We shouldn’t have to keep asking politely that large corporations not violate our civil rights. “Please Sir, may I use your site?” I’m not sure if this will make it to the Supreme Court, it can decline to hear this case. I’m not even sure if the court ruling in favor of the plaintiff in this case is likely. But if it has to come to this, then so be it.

How to Use Brand Names on Your WooCommerce Store by Bob Dunn
Let your customers search your products using the brands that you resell on your WooCommerce online store with lists an widgets.

This site continues to be an excellent resource for user-centered WooCommerce information. wooCommerce is a very powerful, and very complex plugin, and Bob does a great job highlighting extensions and providing instructions for using those extensions as well as the plugin itself in clear, easy-to-read language. Bookmark his site and check back often if you run your own store.

Facebook's Image Outage Reminds Us How Bad Social Media Accessibility Really Is by Kalev Leetaru
Facebook’s brief image outage earlier this week exposed the general public to just how bad accessibility really is in our modern visual-first social Web. While governments and the technology community are investing heavily in AI bias, they care little about accessibility bias.

I don’t use Facebook very much these days, so I heard about the media outage from the outside. And yes, while there have been improvements, and while I’m not placing blame on Facebook’s accessibility team, the accessibility isn’t great even when the AI so-called alt text functionality is working. The best alt text is text which exposes the context of the image being described, and this is down to content creators. This incident is a prime example of why accessibility advocates and consumer organizations should not be using Facebook as their primary distribution platform. If you must use something like Facebook, then you have a responsibility to make the content you host there as accessible as you can by learning how to add alternative text to your images and, (if you’re using Facebook Live), to transcribe that content and host those transcriptions somewhere else until you can make arrangements to use either a different third-party platform or your own platform, otherwise known as your own website.

I Am Cookie Dough by Allie Nimmons
I was always told I had to go to college. I was “gifted” so learning came easy and I enjoyed it.  From ages 6 to 18, I went to competitive accelerated schools designed to churn out college students. It was a narrow path I’d been set on, without encouragement to explore beyond.

These posts are often times the highlight of my week.

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.

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.

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.

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.

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.

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.

( )

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.