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.
July 2019
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.
There’s a new international accessibility standard out – ISO 30071-1 – about embedding accessibility in your organisation and processes.
So why should we, as developers, care…?
Aren’t the WCAG checkpoints for developers, and the new ISO for the product/project managers?
Developers don’t have time to be reading every new bit of writing around accessibility. There’s loads of articles out there – some new, some old, some reliable, some misguided. An international standard should be able to be trusted, but does it give developers any solutions for tricky accessibility challenges that they may face?