Category: Accessibility

Domino’s is arguing the requirements would be inconsistent and costly

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.

Icons are an essential part of many user interfaces. The thing is: more often than not, they break clarity. Just replace them by a text label. Or an icon plus label.

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.

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.

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.

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.

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.

A call for urgency in finding a solution to the content reordering problem which our new layout methods make far more likely.

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.