At long last, we’ve hit the 100 issue milestone (or, if you count all the dai11y, week11y, fortnight11y and month11y newsletters together, over 600!). I’ve been publishing week11y newsletters for over two years now, with the first issue published in October 2019.

I didn’t honestly know if I’d be able to keep it up, especially after stepping down from frontend web development and becoming a backend developer. But I’ve really enjoyed keeping up to date with the ever-evolving world of accessibility, and sharing my learnings with you. As ever, please do spread the word about the newsletter – your friends and colleagues can sign up here – and do drop me a line if there’s anything you can think of to improve the newsletter (or any feedback you’d like to give).

Without further ado, let’s kick-off issue 100 with a double HTMHell digest!

• Debugging HTML: Accessibility
  • “In Chrome or Edge open DevTools, click the Elements tab, select the element you want to inspect and click the Accessibility tab. The accessibility pane shows you how the element is represented in the accessibility tree, which ARIA attributes it has, and its computed properties.”
  • Buttons need a label (denoted by Name:, populated by fields such as aria-label, title, or button innerText).
  • Buttons need a suitable role (denoted by Role: "button").
  • Buttons need to be focusable (denoted by Focusable: true).
  • Note that you also need to be able to activate buttons with Space or Enter, but this information isn’t exposed in the Accessibility tab.
  • There are also instructions for Firefox, which uses a different accessibility API. For example, the role name in Firefox will be pushbutton, rather than button.
• Debugging HTML: Linting
  • The Edge browser now highlights accessibility issues directly in the elements panel of the DevTools (see screenshot).
  • “The built-in linter highlights potential issues in your HTML by marking affected elements with a squiggly yellow line”.
  • “If you hover over the opening tag, a tooltip with a description of the issue appears.”

The ADA lawsuit settlement involving an accessibility overlay

• A UX Collective article about a recent case against accessibility overlays.
• Eyebobs is an online glasses company that used an accessibility overlay to attempt to conform to WCAG. It was sued by a blind plaintiff in January 2021, for violations of the ADA (Americans with Disabilities Act).
• The case enrolled Karl Groves as an expert witness, who wrote a 35-page indictment of how inaccessible the Eyebobs site was even with the overlay. Karl also created overlayfactsheet.com, to educate on how accessibility overlays don’t work.
• The settlement requires Eyebobs to take the following actions:
  • Create an accessibility coordination team
  • Perform an accessibility audit of its ‘digital properties’ (using an accessibility consultant)
  • Adopt an accessibility statement
  • Implement an accessibility strategy
  • Provide accessibility training to its employees
• It must comply with these measures within two years.
• It must also work with third-parties (such as embedded maps) to make their content accessible. The deadline for this can be extended up to five years, reflecting the added complexity.
• The article ends with a link to Lighthouse vs ADP – “the next lawsuit to keep an eye out for”.

Finally, we’ll finish with a two-article special – both written by Raghavendra Satish Peri:

• The Captcha Conundrum & Accessible Alternatives
  • Raghavendra, a blind, accessibility specialist, talks through the problems they faced trying to create an account on Wikipedia. They were faced with a CAPTCHA (Completely Automated Turing test to tell Computers and Humans Apart). It was visual only, and had no audio alternative and no option to use a one-time confirmation code sent to email or phone.
  • Some CAPTCHA solutions do provide an audio alternative, but this is inaccessible to deafblind users.
  • In addition to email/phone options, you could also use the honeypot method, whereby a text field is added to the form but visually hidden. Bots will find the input and fill it with text, so you can avoid a lot of spam form submissions by filtering out all submissions that contain that input.
  • Another inclusive option is a logical or mathematical test, e.g. “Is fire hot or cold?”, as bots will struggle with this. It can be confusing for some users to know how to respond, however.
  • Google’s reCAPTCHA is apparently quite good, requiring only a box to be checked. However, it sometimes treats screenreader behaviour as bot behaviour.
  • Raghavendra concludes “it’s always better to offer multiple options that work for multiple types of disabilities than just one or two”.
• Scroll to top: Where should the focus land?
  • This is more of a placeholder than an article, in which Raghavendra asks us, the community, where the focus should land when activating a “scroll to top” link. What exactly is the ‘top’? It’s easy enough to visually scroll to the top of the page, but where should the keyboard focus go? We have three options:
    1. Move focus to the <body> tag (a poor experience in NVDA, as nothing is announced).
    2. Move focus to the “Skip to main content” link.
    3. Move focus to the <h1> heading level one, or <main> region landmark.
  • There is no definitive answer, but there are some interesting comments at the bottom. The community seems largely split on whether it should be 2 or 3.

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.