Your fortnightly 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:
  • This can’t be easily summarised in one line, so worth reading this section of the article.
• 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.

WebAIM Million – 2021 Update

• This is an annual report that uses the WAVE web accessibility testing tool to analyse the homepages of the top 1 million websites. Compared to last year:
  • The number of detectable accessibility errors dropped from 60.9 to 51.4.
  • The number of DOM elements in the page has increased from 864 to 887.
  • 97.4% of home pages had detectable WCAG 2 failures, down from 98.1%. These were most commonly missing alt text, empty links & buttons, missing language metadata and low contrast text. The latter affected 86.4% of all homepages.
  • Almost half of all form inputs are not properly labelled. However, more websites are properly using headings.
  • The presence of JavaScript libraries (and, counter-intuitively, the presence of ARIA) tends to correlate with a higher number of accessibility errors.
  • .ru (Russian) and .cn (Chinese) websites had twice as many accessibility errors as .us (American) and .ca (Canadian) websites.
  • And finally, a sign of the system working(?): web site categories that were subject to increased civil rights complaints and lawsuits in 2020 were among the most improved.

Accessibility devices at CES 2021 reflect growing focus on inclusive tech

• The entirely virtual CES in January 2021 saw a number of assistive technologies, as companies begin to realise the importance of inclusivity and the money that can be made. Some highlights include:
  • Mantis Q40 – a $2.5k QWERTY keyboard with built-in braille display.
  • Oticon More – a hearing aid with built-in neural network, trained on 12 million real life sounds, to help process speech in noisy environments.
  • Sravi – an app that uses AI based lip-reading technology to recognise specific phrases from lip movements. It is aimed at people with speech difficulties, or patients in critical care with ailments that render them incapable of speaking. The app is in trials within the UK’s National Health Service.

iOS 14 review: access all areas?

• This is another one from the bookmarks that I’ve just gotten around to reading! Colin Hughes reviews the accessibility of iOS 14. He has muscular dystrophy and therefore relies on voice control.
• Since iOS 11, iPhone users have been able to activate an auto-answer capability for incoming phone calls, but Colin notes that it requires you to touch the screen to set it up in the first instance. You can also make calls by saying “Hey Siri, call…”, but there’s no equivalent for ending the call, so if you go to voicemail you are stuck until the mailbox times out. This is still an issue in iOS 14.
• Since iOS 13, the Announce Messages with Siri feature reads out your incoming messages and allows you to respond hands-free. Colin hoped this would be expanded to other apps like WhatsApp or Facebook Messenger, via an underlying API, but this has not happened in iOS 14.
• Voice Control now supports UK English, which has improved the accuracy of Colin’s dictation, though the accuracy remains low and using the app is frustrating when compared with Voice Access in Android 11, which is “incredible” by comparison.
• Colin also cites “improvements to the VoiceOver screen reader, a new Back Tap Feature, sign language in FaceTime calls, and Headphones Accommodations to help you hear better”. However, overall, Colin is disappointed that some of the the basics are still neglected.

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.