fortnight11y issue 35

Your fortnightly frequent11y newsletter, brought to you by @ChrisBAshton:

iPhones can now tell blind users where and how far away people are

  • An article from October 2020, but it taught me something I didn’t know: iOS 14.2 allows you to detect whether there are people in view (using your camera), and how far away they are. iOS will say how far the person is away, in feet or metres. The user can set a tone corresponding to difference, i.e. if somebody gets too close the tone changes. For deafblind people, there is a haptic pulse option instead, which goes faster as people get closer.
  • It isn’t explicitly mentioned in the article, but this feature is aimed at allowing blind users to keep a safe distance from people during the coronavirus pandemic.

In Praise of the Unambiguous Click Menu

  • Mark Root-Wiley shares his thoughts on why hover-based menus should be a thing of the past. They violate Jakob’s Law of Usability: that users prefer your site to work the same way as all the other sites they already know. This is because there are several different hover menu behaviours in the wild, so it’s impossible to predict which one a site is using until you click around. For example, is the top menu item a link to its own page, or a ‘fake’ link (href="#")?
  • Hover menus are also difficult to use on touch screen devices, which have no concept of hover, and also require careful pointer precision; it’s easy to accidentally hide the submenu again by moving the cursor out of its range.
  • Mark suggests using click menus instead, following the guidance of the US Web Design System, Bootstrap and others.

Wearable tech helps this blind runner compete in ultramarathons

  • In 2017, Englishman Simon Wheatcroft was the first blind person to run the New York City Marathon solo, without being tethered to a sighted running guide. He managed this by wearing a “Wayband” on his wrist; the device has built-in GPS and vibrates to keep the wearer on a set path.
  • Simon collaborated with New York based startup WearWorks to develop a prototype of the band in 2016, and the product is set to launch officially this year.
  • It is hoped that the band will enable blind users to “travel independently and discreetly” without audio instructions, which could help them explore unfamiliar places by themselves.

3D-printed exoskeleton allows paralysed woman to “walk”

  • An blog post by accessibility consultant Nicolas Steenhout, which has resurfaced recently. It gives his opinion of a CNET article about a paralysed woman whose 3D-printed exoskeleton allows her to “walk”. As Nicolas points out, the $150k exoskeleton holds the woman up, and moves her in a way that looks like walking, but she isn’t actually “walking”.
  • The article is well worth a read, detailing some of the considerations the engineers at 3D Systems had to factor in, such as ensuring that hard parts of the exoskeleton don’t bump into parts of the body. (This wouldn’t be felt by the paralysed wearer, and would lead to bruising an abrasions that could become infected).
  • What I found most interesting was Nicolas’ suggestion that such developments could be considered ableist. He references a previous blog post where he debunked the idea that you need to “stand” to cook or socialise. Nicolas’ implication here is that the exoskeleton offers no benefits over a traditional electric wheelchair, other than conforming to societal norms.

Automated accessibility testing: Leveraging GitHub Actions and pa11y-ci with axe

  • A blog post describing how to install pa11y-ci to your project and run it automatically with GitHub Actions. pa11y-ci is a Continuous Integration wrapper around pa11y, which is an automated accessibility tool that scans your web pages for issues.
  • You can configure the WCAG standard to which the tool validates (WCAG 2 A, AA or AAA), and tell it to run the tests using aXe-core using the axe ‘runner’ (htmlcs is the default runner, though the article doesn’t describe why you should use one over the other).
  • Once you have pa11y working locally (using NPM package files to declare your dependencies), you can write a .github/workflows/pa11y.yml file to define your GitHub Action. The article explains how to get GitHub Actions to run your pa11y tests when you open a PR to your repository.

Next up is a two-article WCAG special:

  • WCAG 2.1 Checklist
    • A checklist by Raghavendra Satish Peri, an accessibility evangelist working for Deque. It lists each guideline for WCAG 2.1 A and AA compliance, along with a summary of each and a “Points to Ponder” section, containing useful tidbits like “Always provide alternative options like audio or OTP (one time password) for CAPTCHA.”.
    • It’s a long page, but not as dauntingly long as the official WCAG guidelines page, which also lacks the specifics of the “Points to Ponder” section (in favour of linking off to extensive ‘understanding’ pages, e.g. Understanding Success Criterion 1.2.1). Some people might prefer Ravhavendra’s checklist.
  • WCAG guide
    • A ‘quick reference’ guide to WCAG, built by designer Marcelo Sales. It displays each success criterion (SC) as a ‘flash card’, summarising each SC in one paragraph. There are options to filter by compliance levels A/AA/AAA, and there’s also a real-time fuzzy-matching search, so you can easily search for, say, “focus”, and see all relevant SC’s.

And we finish with another special two-parter, this time to do with accessible front-end components!

  • A Complete Guide To Accessible Front-End Components
    • A Smashing Magazine article that does a bit too much, in my opinion! It begins with a table of contents, listing common UI components but also media preferences such as dark mode and prefers-reduced-motion. Each anchor link jumps to the specific part of the article which either describes how to build it, or links to an article which describes how to build it, or links to a library that implements it well.
    • Then the components list comes to a quiet close and there’s a long section promoting different a11y resources and tools. I discovered a11ysupport.io, which describes which ARIA roles and HTML features are supported in popular combinations of browser and screen reader.
    • A useful resource, well worth a read, but I’m not entirely clear as to what it’s trying to be!
  • Accessible front-end components: claims vs reality
    • This article by Hidde de Vries references the first article, and warns that we must do our due diligence when using third-party components that claim to be “accessible”. Some “accessible” components may have good colour contrast but not work with just a keyboard, or may work fine when zoomed in but not be interactable with voice navigation. You should perform some basic checks on the component yourself.
    • Look for specifics in the claims – what WCAG standard do the maintainers claim their component conforms to? How was it tested (e.g. formal WCAG testing, checklists, or automated tests), and what kind of browser support does it have?
    • Check the GitHub issues on the project – particularly ones mentioning WCAG or accessibility – and read the maintainers’ responses.
    • Are the maintainers open about any caveats / planned fixes? See if the project has an accessibility statement.

Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.

Loading...