Chris Ashton

week11y issue 73

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

Introducing Editoria11y: Accessibility Autocorrect

  • The folks at Princeton University have released a tool, editoria11y, as a frontend module of JS and CSS (but also a Drupal module, and a WordPress plugin is in the works).
  • The tool aims to catch only editorial accessibility errors, rather than the “ALL the errors” approach used by other accessibility tools, which arguably flag too much. As noted in the article: “they do not just mark mistakes the author just made, they mark color issues the designer made, technical issues the developer made…”.
  • The demo shows editoria11y in action, warning the editor about common issues such as missing alt attributes, but also more nuanced things like when the alt text is too long or if ALL CAPS is used.
  • The article concludes with a vision for the future: what if authoring tools made it easier to make accessible content by default? “For example, the default table in most content management systems does not have headers. The onus is on the user to know to click ‘properties’ and add accessibility features; maybe it is time to reverse that?”.

Modern CSS Upgrades To Improve Accessibility

  • Stephanie Eckles shares some useful CSS tips. I’ve cherry-picked some highlights:
  • The use of max() to ensure that a focus outline is always at least 1px wide, whilst allowing it to be relatively sized with em:
    • button:focus { outline: max(1px, 0.1em) solid red }
  • Use of focus-visible to only apply focus styles when you’ve tabbed in via a keyboard (not mouse click):
    • button:focus-visible { ... }
  • Use of CSS grid to maintain the correct tab list order across multiple columns:
  • Stephanie uses currentColor throughout her examples. I don’t remember coming across it before, but it’s a way in CSS of defining a colour throughout your component, so that you only have to set that colour in one place. That’s not explained in the article, but there’s a good write-up of currentColor on DigitalOcean.
  • Finally, I love this quick global rule for disabling animations for users who prefer reduces motion:
    • @media (prefers-reduced-motion: reduce) {
      *, *::before, *::after {
      animation-duration: 0.01ms !important;
      animation-iteration-count: 1 !important;
      transition-duration: 0.01ms !important;
      scroll-behaviour: auto !important;
      }
      }

Adobe unveils ambitious multi-year vision for PDF: Introduces Liquid Mode

  • An Adobe announcement from September 2020, which I’ve somehow only just come across. Adobe Acrobat Reader on iOS, Android and Chromebook now has a ‘Liquid Reader’ mode, which is a button in the UI that processes the current PDF in the cloud and then renders a mobile-friendly version of the content. There’s a video showing how it works. It uses AI to identify headings, images, lists, tables etc, making otherwise inaccessible PDFs more usable on mobile. That said, this shouldn’t be used as an excuse to continue to churn out PDFs instead of good, accessible content.

EyeMine V2 is here!

  • EyeMine is free eye-control software for the game Minecraft. It allows players to navigate the world, mine resources, fight enemies, and essentially complete every in-game task using just their eyes. The source code is available on GitHub.
  • There is a 4 minute video demonstrating how it works: the screen is split into two panels, one containing the game view and one containing the EyeMine panel. Players shift their gaze to the EyeMine panel to change context, e.g. equip a pickaxe for mining, before shifting their gaze back to the game window.
  • EyeMine can also be used in conjunction with a switch for key selection or as a direct control for mining and building.
  • I think it’s worth celebrating that a relatively feature-rich game such as Minecraft can be played with just your eyes, given the right modifications. This is an accessibility success story that makes web accessibility look like a walk in the park in comparison!

An opinionated guide to accessibility testing

  • Iain Bean shares his approach to accessibility testing a website:
    1. First impressions (on page load) – are there auto-playing videos, etc? There may be a number of obvious a11y issues to fix right off the bat.
    2. Tab around the page, checking if every interactable element can be focused, and has a focus state. Iain points out that Firefox and Safari don’t tab very well by default on OSX, so need to be configured. Iain shares a useful bookmarklet which, when pressed, hides your cursor, helping you to test by keyboard navigation alone. There’s also an unexpected shout-out to my article, I Used The Web For a Day With Just a Keyboard… thanks Iain!
    3. The next step is automated testing: Iain clicks the tota11y bookmarklet, which brings up an overlay and highlights problems in the page such as low contrast, missing alt text, inputs without labels etc. He then runs Lighthouse, and a couple of the other tools mentioned on Web Accessibility Evaluation Tools.
    4. Finally, Iain tests his site with a variety of screen readers.
  • This approach sounds similar to the Three Phase Attack approach to testing I wrote about in 2016: starting with the lowest effort testing and working your way to the more laborious steps, with gradually diminishing returns. There are only so many browsers, operating systems and assistive technologies you’ll have time to test in, but you’ll usually find most issues by testing your site with a small handful of distinct combinations.

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...