Category: month11y

This issue comes a month too late – I’m so sorry! Looks as though I overlooked it. So please enjoy this month’s issue – which is really last month’s issue – and don’t be too surprised to see month11y issue 20 arrive soon after that!

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.

Should you use an <h1> in email code?

• A thorough investigation by Mark Robbins, looking at the state of webmail across a dozen different providers.
• 60% of screen reader users prefer pages containing just one <h1> with the document title, whereas 33.3% prefer two <h1> headings, for the site name and the title.
• Given a preference for one <h1> tag per page, the question is: should you include a <h1> in the emails you send people, or would that conflict with a <h1> that already exists in the webmail client? In other words, when viewing an email on gmail.com, how many <h1> tags are there?
• Mark found that most webmail clients don’t add a <h1> to the page when viewing an email. I verified this by opening an email on gmail.com and inspecting the subject line, which is marked up as a <h2>. A couple of webmail providers do include a <h1> in the page, but their market share is low, and leaving out <h1> tags would do more harm to the many users of the other webmail clients.
• Mark’s advice is to therefore include a <h1> tag in your emails. That’s easier said than done, of course – it only really works for email designers using professional services such as Mailchimp. For one person sending an email to another person, it’s not so easy.

We asked an expert to redesign Wikipedia – here’s what they came up with

• TechRadar Pro asked UK-based designer Kevinsdesign to improve the design of Wikipedia. The screenshots in the article are fun to look through, showcasing a useful ‘table of contents’ side panel, a homepage of discovery options, and accessibility and language options brought to the forefront.
• Kevinsdesign interviewed four users to discover their friction points with the existing website, before mocking up the designs. He spent most of his time thinking through the accessibility options. He said:
• “Wikipedia is accessed by billions worldwide with the common goal of consuming written articles, however reading isn’t a given for everyone, between 5-10% of the population are dyslexic (myself included), even more have visual impairments and so on. Things like colour contrast, font size, and even black text on white backgrounds can make content very hard to consume.”
• “I asked the question: could I bake in accessibility options to the new design that would break down these barriers and make Wikipedia more accessible to people? The new accessibility option in the menu allows the user to customize the setting to their needs, be it making the font size bigger, making the content seizure safe, changing the font to child friendly and even adding a color overlay to the article which for many dyslexics massively helps them read.”
• These options are captured in the screenshot above.

Wix Launches First of Its Kind Accessibility Tool to Help Make The Web Accessible for Everyone

• Wix is a popular platform for building and hosting websites, choosing from pre-built themes and customising the content. It has now launched its ‘Accessibility Wizard’, which is built into the CMS.
• You can use the wizard to scan your site for accessibility issues, detecting things like images with missing alt text, improper heading orders, or insufficient colour contrast. The wizard provides detailed instructions on how to fix each issue.
• The article above is frustratingly thin on detail, but you can find out more on Wix’s official blog post. It arose from a checklist which Wix created and asked website editors to follow, but users found this too heavy and time-consuming to follow.

What Is It Like to Use a Screen Reader?

• Anthony Vasquez shares some things you may not know about how some people use screen readers. The article is a follow-up to a Screen Readers in the Wild seminar. Some video demonstrations from the seminar are linked below:
  • Using JAWS to find a video on YouTube
  • Using NVDA to find stock information on Google Search
  • Using NVDA to customize an order on See’s Candies’ website
  • Using VoiceOver to order from Coffee Bean iPhone app
• “Often, developers go too far treating images as decorative”, (perhaps because it’s easier to specify an empty alt="" attribute than to come up with good alternative text? ~Chris), leading Anthony to feel he’s missing out on something, and to try to derive context from the surrounding content. Anthony praises The Atlantic for getting alt text right, with a good mix of short and long descriptions.
• Anthony mostly navigates pages using arrow keys, which can “reveal important information” that is otherwise missed by tabbing. However, computer science student Su Park – who also demonstrated in the webinar – navigates mostly with tabbing and shortcut keys. Anthony says it is important to test both interaction styles.
• The article finishes with a little detail on what refreshable Braille displays are.

Shifting left: how introducing accessibility earlier helps the BBC’s design system

• Sophie Beaumont writes about working on the BBC’s design system. A team had hoped to re-use one of the existing components in a new feature they were building, because it matched their visual design. However, on closer inspection, the underlying HTML semantics were unsuitable for the task, and they decided a new, separate component would be more appropriate. Sophie summarises: “Focus on what components achieve, rather than their appearance”.
• They were able to catch the issue early because of a recent push for accessibility documentation during the design phase. In other words, designers talking to developers about what the structure of the content should be, including semantics such as headings, lists and landmarks. This is considered “shifting accessibility left”, i.e. embedding it earlier in the software development cycle, and in this case it exposed a requirements issue that would have been costly to fix later.

These are my notes, which I wrote while attending the BBC’s “Monday 17th May: Hearing” event to mark Global Accessibility Awareness Day (which is Thursday 20th May). There were a range of speakers in the 1-hour session:

• Keynote from Jenny Lay-Flurrie, Chief Accessibility Officer at Microsoft:
  • Unemployment rate is approximately double for people with disabilities.
  • People with disabilities have asked to work from home for decades – COVID has removed that barrier, but the unemployment gap actually increased.
  • Shout out to two great developments recently: Seeing AI app and Xbox adaptive controller.
  • Microsoft is working with universities to level up accessibility skills in its undergraduates.
• Nigel Megitt, Executive Product Manager for AV Accessibility at BBC:
  • We saw a demo of changing the size of subtitle text on the iPlayer TV app. Note that this was already a feature on the web version.
  • iPlayer received mixed feedback on the default size of the subtitles. Realised that there was a preference for different default subtitle sizes based on device type and size.
  • There was some technical detail around the standard of subtitle files that the BBC exports.
• Kay Ashton MBE, Accessibility Project Coordinator at BBC:
  • We watched ‘Sing’ – BSL SignSong (“Fletch@rettes Signing Choir”, participants from BBC Children in Need projects, BBC Ability, BBC Philharmonic and BBC Singers, recorded in lockdown to raise awareness of BSL for Deaf Awareness Week 2021).
• Panel discussion including Esmail Patel (of Interpreting Solutions), Fletch@ (of Fletch BSL), and Lewis Vaughn Jones (of BBC Global News):
  • Platforms such as TikTok are driving better accessibility on social media (though probably down to better engagement, rather than ‘for accessibility’). And people are becoming proud to show off sign language on social media, both British Sign Language and International Sign Language.
  • Automated transcriptions are improving all the time. Also a shout out for the Text to Speech app.

These are my notes, which I wrote while attending the BBC’s “Tuesday 18th May: Vision” event to mark Global Accessibility Awareness Day (which is Thursday 20th May). There were a range of speakers in the 1-hour session:

• Talk by Molly Watt, founder of Molly Watt Trust:
  • Molly was born deaf. She had a good speaking voice and could lip read, so not many people even realised. In her teens, her vision started to deteriorate, and Molly was formally diagnosed with Usher Syndrome.
  • From the age of 3, Molly had analogue hearing aids, which were replaced with digital at the age of 9; Molly remembers hearing birds singing for the first time. Later on she was given a ‘smart’ hearing aid, where the quality of sound improved even further, and came with surround sound – essential for someone who is blind as well as deaf. It also has a smartphone app, where Molly can change the bass/treble/background noise levels.
  • Molly has an iPhone, which comes with lots of assistive technology built in. It has two screen readers – VoiceOver and SpeakScreen – and Molly uses mostly the latter. Molly also uses colour filters, rather than dark mode, to place a tint on the screen and reduce the glare. Finally, she uses Siri to send messages, meaning she doesn’t need to physically get her phone out in public. Molly now feels ready to move out of the family home, even during COVID, and says this is all down to technology.
  • Molly went to university but couldn’t access the intranet, due to its inaccessibility. She fought for change, but couldn’t get the university to make any changes, so left the uni in order to educate on a larger stage.
  • The Molly Watt Trust was founded to raise awareness of Usher Syndrome, and for people with Usher Syndrome to meet one another and boost morale and give the tech/tools needed to get by.
• Talk by Natalie Curran, Assistive Technology Tester at BBC:
  • There has been a lot of movement on equality over the past few years, but disability equality seems to have been left behind.
  • Natalie has been an ATT for 8 months, and says she is still learning lots. She is looking forward to going into the office, where she’ll be able to use assistive technologies she hasn’t used before, such as ZoomText.
  • Natalie wants to help “bridge the gap”, saying “if only one person walks away and next time they [build] something, they think twice about [how to do it accessibly], then I’ve done my job”.
• Talk by TV Platform Accessibility Guild at BBC:
  • Watched a presentation – ‘Screen Readers on TV’ – presented by “BBC Synthetic Voice”, which sounded very human. It’s challenging to build TV apps – older ‘smart’ TVs often don’t support new technology. The average person keeps their TV for 7-8 years – the equivalent of web developers having to support iPhone 5 today.
  • BBC Sounds was designed with basic screen reader support from the start, as it’s a relatively new app, but iPlayer has been slower going. It was, until recently, silent when using a screen reader, but new changes available in beta introduce support in some pages (though not all pages, notably the the sign-in screens).
  • The BBC are working with TV manufacturers, writing & providing automated tests to them so that they can identify issues prior to the device being released. The BBC are hoping this will improve the experience for ALL applications on the device, not just iPlayer.
• Panel: Paul Smyth MBE of Barclays Accessibility, Robin Christopherson MBE of AbilityNet, Adi Latif of AbilityNet, Emma Tracey of BBC Journalism, and Sean Dilley of BBC News:
  • It was 2009 when Sean had his first accessible phone – the iPhone – which “opened up the world” to him. Prior to that he had some Nokia phones that spoke to him but weren’t particularly useful.
  • [What do you use for work every day?]
    • Paul uses ZoomText to avoid eye strain, and to reduce the reliance on (and noise of) his screen reader.
    • Robin uses a Bluetooth headset, joining with audio only, listening to the meeting but also having other earphones for their computer so that he can multitask.
    • Emma uses a Perkins Brailler – a metal braille typewriter for labelling her kids’ books, kitchen spices etc.
    • Adi loves his PenFriend – a pen shaped device to record voice notes associated with labels you can stick to things, such as food in the kitchen, and then wave the pen over it to play the voice note. It allows him to easily identify spices etc.
    • Sean has a barcode scanner app on his iPhone to tell him what tins he’s looking at, and also apps where he can ask a person what’s in front of the camera, which is very useful sometimes.

These are my notes, which I wrote while attending the BBC’s “Wednesday 19th May: Motion” event to mark Global Accessibility Awareness Day (which is Thursday 20th May):

• Vivek Gohil, is a gaming accessibility consultant:
  • Vivek has muscular dystrophy. He started gaming at age 10 with a gameboy: “it helps to escape reality” and is “very important for mental health”.
  • At 15, Vivek first experienced accessibility issues with holding a controller. He managed to overcome it with a table and sponges for support.
  • The SpecialEffect charity uses technology to help people with physical disabilities to play games to the best of their abilities, using technology such as modified joypads.
  • Vivek started a YouTube channel to create accessibility reviews of new games.
  • The Last of Us: Part II is critically acclaimed for its accessibility options. It has slow-motion aiming, makes you invisible while prone, has an aiming toggle, and has full control remapping support.
  • Vivek would like to see these accessibility options as standard in future: alternate sprinting option, slow motion aiming, remap different actions to either button tap or hold.
• Christopher Hills, video editor and founder of HandsOptional:
  • Christopher has cerebral palsy, and self-confessed technology geek. In 2012, Christopher studied information technology. He made a video showing how he uses technology to consume his lectures, which he sent to his lecturers and also uploaded to YouTube. It got shared by Chris Pirillo and overnight gained 50,000 views. Christopher now has a sizeable following on his channel.
  • It was at this moment Christopher realised “I had something valuable to share with the world, and the technology at my disposal is infinitely more powerful than I’d thought.” After studying film at university, Christopher became Apple-certified in Final Cut Pro, started a consulting business and co-wrote a book.
  • Christopher uses a lot of Apple technology, which supports a wide range of a11y features, including Switch Control. He uses Siri Shortcuts to configure his office to shut blinds, close the door, etc, all from one click interaction, and is comfortable completely redesigning his on-screen keyboard layout when it doesn’t suit him.
  • Christopher closes by sharing a video of how he flies drones to capture cinematic shots. It goes into detail on his assistive technology setup. Christopher created the music accompanying the video, using apps on his machine. It’s incredibly powerful and moving, and well worth watching.
  • “With today’s technology, it is not my body that limits me – it is my imagination.”
• Panellists: Brannon Zahand of Microsoft XBox Accessibility, Andrew Bromilow of EveryoneCan, animation student Nu McAdam, and Allan MacKillop of BBC Diversity & Inclusion:
  • Nu: keen for us to return to the office – there’s a lot of loneliness in the disabled community that is being amplified by us all being remote.
  • Brannon: there is an increasing recognition that “we are not our user”, seen in things like customisation, e.g. allowing you to set your colour preference.
  • Andrew: when stuck on an a11y problem, reach out to the disabled community – they are experts. And be prepared to pay them for their time.
  • Allan: the current generation of elderly people need support with technology. But he expects the elderly people of the future will be much more tech savvy, playing video games, etc.
  • There’s also a shout out to Xbox for maintaining backwards compatibility between its consoles and controllers: good for sustainability, and less of a barrier to those with accessibility needs who have a particular setup.

And then, finally, it was Global Accessibility Awareness Day! There were lots of events all over the web, and it was hard to choose what to attend. Aside from a couple of internal work events, I mostly attended sessions at the very well run Festival of Accessibility:

• Digital by Default: Baby Boomers and the impact of COVID-19:
  • “Over the past year the digital world has quickly evolved. This change has impacted older web users more than most.”
  • My takeaways from this session: of people who are over 50 years old, around 23% find an ‘increase font size’ option useful (according to, I think, YouGov). And the UK has an average reading age of 9, so it’s very important to use simple language. This became something of a theme in many of the talks I saw today.
• Writing in Plain English – the inclusion challenge:
  • “Did you know that as many as 1 in 4 UK adults have very low literacy skills? And 10% have dyslexia, which can cause reading challenges?”
  • Think about your target audience before you write. Imagine how you would talk to your target reader if they were in front of you, and write that down – it won’t be quite right, but it’ll be a great starting point that likely sums up the most important things you have to say.
  • Use signposts throughout your content: headings, bullet lists, and frontloading of content (i.e. put the important content towards the beginning of your sentence). Personal, conversational language tends to read better, e.g. “your heart may beat faster” vs “the heart may beat faster”.
  • The Flesch Reading Ease scale looks at sentence and syllable length and arrives at a score of complexity from 0 to 100, where the lower the score, the more confusing the content. GOV.UK aims for a minimum of 70.
• Digital Literacy & Accessibility in the Public Sector:
  • “Up to 1 million people in the UK cannot speak English well or at all.”
  • 50% of the population are below primary school numeracy level.
  • The Patient Information Forum has a charter that organisations can sign up to. It encourages:
    • Using clear communication (verbal, written, digital)
    • Creating easy-to-use digital tools/websites, printed information and premises
    • Involving users in the development of information as routine and inviting feedback
    • Training staff in health literacy
    • Commit to consider digital exclusion and the equalities impact when introducing new resources.
• The Future of A11Y:
  • This panel session ended the day of events. It touched on lots of interesting topics.
  • There was talk of Public Sector Accessibility Regulations being a useful ‘stick’ to encourage compliance, where the ‘carrot’ of inclusivity doesn’t always work.
  • Advocating for accessibility at the highest levels requires different tactics: the threat of litigation (see above), the cost to the business (someone mentioned that accessibility costs 200 times more to retro-fit into an established product than to build in from the start). But empathy can work too: invite a disabled person into your board room to demonstrate the challenges they face using your product.
  • There was a shout-out to DIVERSish on YouTube, a skit which points out that whilst 90% of companies claim to “prioritise diversity”, it usually means focusing on LGBTQ, BAME and women, whereas disability regularly gets overlooked (“only 4% prioritise disability”).

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

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.

Is your CAPTCHA keeping humans out?

• CAPTCHAs are important for preventing DDoS attacks, as they prevent botnets from accessing processor-intensive parts of websites such as login forms. But they can give false positives, where CAPTCHAs filter out humans, which is particularly bad in the COVID-19 era where it is essential to be able to access services virtually. The article goes on to describe the history of CAPTCHA development:
• reCAPTCHA is a CAPTCHA service company that was acquired by Google; it accounts for around 93% of all CAPTCHAs on the web.
• Early versions of CAPTCHA software had users deciphering distorted words and numbers, and typing these into a box. These should no longer be used today, as they are entirely visual and therefore inaccessible to users with visual impairments.
• reCAPTCHA version 2, released in 2014, analyses the way the cursor moves across the screen to determine whether the motion is likely to be human. If it isn’t, it presents the user with an audio or visual challenge, such as clicking images which contain fire hydrants.
• reCAPTCHA version 3 was released in 2018; it eliminates user challenges altogether and returns a “probability score” indicating the likelihood the user is human. It is up to the developers to take extra steps if the score is low, e.g. authenticate the user through an email link.
• The article closes by asking developers not to roll out their own CAPTCHA solutions, which are likely to be less accessible than the industry standards.

Alt text that informs: Meeting the needs of people who are blind or low vision

• A really interesting article by Microsoft that is not (as I suspected from the headline) your typical “how to write good alt text” article.
• A recent Microsoft study found that users who rely on alt text want different alt text depending on the context of the image:
• “For example, if a photo of a person appeared in a news story, people might want a description that includes details about the setting of the image to give a sense of place. But if a photo of a person appeared on a social media or dating website, people might want increased details about that person’s appearance, including some details that may be subjective and/or sensitive, such as race, perceived gender, and attractiveness”.
• “One participant mentioned that knowing the race and gender of people in photos of board members on an employer/employment website might help them understand whether the company values a diverse workplace. These latter examples illustrate practical and ethical challenges for emerging AI systems, such as whether AI systems can – or should – be trained to provide subjective judgments or information about sensitive demographic attributes.”
• The article includes a table of contexts (such as e-commerce, news, dating) cross-checked against properties in an image that would be important to include in the alt text (e.g. weather, expression, hair colour), as indicated by the study’s participants.
• Microsoft concludes that new categories of metadata should be produced to feed into improved machine learning models, and there should be “custom vision-to-language models” that give different alt text depending on the context in which an image appears.

Next up is a Steve Faulkner special, as I’ve had two of his blog posts bookmarked for some time!

• re-upped: placeholder – the piss-take label
  • Steve confirms that use of the placeholder attribute alone, in absence of a label, fails Success Criterion 3.3.2: Labels or Instructions. The problems with placeholder are summarised nicely in one paragraph:
  • “While the hint given by the controls label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.”
  • This bonus article from HTMHell adds that translation tools such as Google Translate may not translate attribute values, placeholder text gets cut off beyond the size of the field, and “if browsers auto-fill fields, users have to cut-and-paste auto-filled values to check if browsers filled in fields correctly”.
• aria-description: By Public Demand and to Thunderous Applause
  • The new aria-description attribute coming to WAI-ARIA 1.3 is similar to aria-label (takes a string of text associated with an element), but is intended for more verbose information. Steve sees it as replacing aria-describedby in those cases where the linked element is visually hidden, i.e. <a href="#" aria-describedby="help">Help</a><div id="help" class="visually-hidden">This description is for screen reader users only</div>.
  • It’s supported in Chrome, Firefox and Edge already.
  • Steve closes with some advice: for aria-label, a word or phrase is better than a sentence, and for aria-describedby or aria-description, a sentence is better than a paragraph.

Apple Music Adds “Saylists” to Help People with Speech-Sound Disorders

• At the end of March, Apple worked with Warner Music to launch the “Saylists” feature on Apple Music. This feature helps users find songs with lyrics and sounds which can be challenging to vocalise if you have a speech-sound disability/disorder (SSD), as one in 12 children in the UK do. Getting people with SSD to repeat hard and challenging sounds (such as words beginning with “ch”, “g”, “k” and “z”) is one of the most successful strategies to treat the disorder.

Clubhouse, the Shift to Spoken Social Media, and the Voices That Will Be Silenced

• Lawrence Weru discusses the Clubhouse app and what it is like as a person with a stutter. The invite-only app can gather over 1,000 people together in “rooms” for voice chats, where you can raise a ‘hand’ to ask to speak on the stage. He describes the anxiety stutterers feel when ‘raising the hand’ to speak on Clubhouse, and the instinct to just stay silent.
• Lawrence has listened to several hours of Clubhouse conversations per week, but it was 49 days before he heard someone with a stutter take to the stage. To put that into context, around 15% of Americans have a speech/language/voice disorder, often starting between the ages of 2 and 6, with a 1 in 4 chance of it staying for life.
• There is an increasing reliance on voice to interact with technology, making life difficult for stutterers: automated phone systems which require specific words without substitution, and Siri/Alexa which misinterpret pauses in speech as the end of the command. Clubhouse, and Twitter’s similar new “Spaces” feature, are continuing the move towards real-time voice. There’s an unfortunate lack of suggested solutions in the article, but it is worth a read to be made aware of the issue.

Checking Windows High Contrast Mode on a Mac for free

• Microsoft estimates that 60 million people use Windows High Contrast Mode (WHCM) regularly. The mode is under-tested compared to VoiceOver, which Adrian Roselli claims is over-represented. Marcus Herrmann shares his tips for developers wanting to test WHCM on their Apple machines:
  • Download VirtualBox.
  • Get a Windows 10 virtual machine (VM).
  • Write down the Windows admin password – which is Passw0rd! – as you’ll be asked for it a lot.
  • Launch VirtualBox and select your virtual machine. Optional: use VirtualBox to take a restorable ‘snapshot’ as soon as you’ve got it working, as the Windows license on these VMs expire after 90 days.
  • To activate WHCM, click on the search field next to the Start button and search for “high contrast”.
• Marcus notes that there are 4 High Contrast themes available in Windows 10: “High Contrast Black”, “High Contrast White”, “High Contrast #1” and “High Contrast #2”. You should ideally test in each.

Uber ordered to pay $1.1m to blind woman who was refused rides 14 times

• Lisa Irving filed a complaint against Uber in 2018, after, on multiple occasions, being denied a ride or being harassed by Uber drivers not wanting to transport her and her guide dog. An independent arbitrator this month ruled in her favour, ordering Uber to award her £790,000, or $1.1 million.
• Ms Irving’s lawyers said: “Of all Americans who should be liberated by the rideshare revolution, the blind and visually impaired are among those who stand to benefit the most. However, the track record of major rideshare services has been spotty at best and openly discriminatory at worst”.
• Uber had claimed that it wasn’t liable for its drivers conduct because they were contractors. This has been struck down in the UK after a lengthy legal battle, and was dismissed by the arbitrator, who concluded that Uber still had contractual supervision over the drivers.

Add punctuation to your alt text

• Eric Bailey reminds us that we should always finish our alt text with punctuation, such as a full stop/period. This makes the screen reader voice pause slightly before announcing the next words in the sequence, which feels a lot more natural. Example code:
• <img src="puppy.jpg" alt="A golden retriever puppy wearing a tiny raincoat." />

Chrome now instantly captions audio and video on the web

• Live Captions, Google’s real-time captioning feature, is available now on Chrome. The technology, which first appeared on Pixel phones in 2019, has captions appearing as a small, movable box at the bottom of the browser. The captions are generated in real time from the sound of the audio, so there is a slight delay and a fair few mistakes, but it is still a useful feature, and works offline too.
• “Live Captions can be enabled in the latest version of Chrome by going to Settings, then the Advanced section, and then Accessibility.”

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

Android update adds scheduled texts and improves accessibility

• Whilst Android 12 will likely be released in September 2021, a first developer preview is out now. One accessibility improvement is that you will be able to make calls, set timers and play music from the lock screen, using Android’s ‘Assistant’. This will benefit those with mobility impairments and enable hands-free use.
• Android 12 will also incorporate big changes to the TalkBack screen reader (version 9.1). It adds 12 new multi-finger gestures that, for example, allow you to switch between reading just headlines, or words, or individual characters. It adds voice commands, so you can tell TalkBack “find” to locate text in the screen, or do things like increase the speech rate. Finally, it adds more customisation for its braille keyboard, including support for Arabic and Spanish. This blog post by Google explains the updates in more detail.

How we created a reporting tool to improve the accessibility of GOV.UK

• Avision Ho, a data scientist at GDS, describes how their team built a tool to check half a million GOV.UK pages for some specific WCAG failures. They concentrated on 8 problems, including non-semantic headers (paragraph text styled with bold, mimicking the style of a heading), badly ordered headers and falsely labelled non-English text.
• It goes into some technical detail on how the team used multi-processing techniques to generate the reports in just a few hours. The reports were sorted by government department, so that the Accessibility Team could speak with the relevant content editors about the issues identified.
• The article lacks a summary of how many issues were identified and how much has subsequently been fixed, but it’s certainly a step in the right direction and I hope we can read more about this soon.

The no-mouse challenge: Taking the keyboard navigation red pill

• Denis Boudreau describes “the no-mouse challenge”: start a timer, open a website and see how long it takes you to run into a brick wall. Participants in his workshops are “blown away” at the brittle nature of the web once you go off the beaten track of mouse navigation. He likens this to “taking the red pill” in The Matrix; the sudden realisation of how inaccessible most sites are. Common issues encountered are:
  • Losing your place, due to a lack of focus styling.
  • Triggering modal windows and having difficulty focussing on them.
  • Jumping around the page at random, due to confusing & illogical page order.
  • Skipping over entire sections of the page that really should be interactable.
• One person who took the challenge is Mickey Mellen, in his article, “An hour without a mouse“. It references my own article – which is always nice to see! – and also shares a useful resource on Chrome keyboard shortcuts.
• Both articles reference the 7% of working-age adults with severe dexterity difficulties, who might struggle to use a mouse. Combined with screen reader users, that’s about 10% of users who depend on keyboard support.

Material Design Text Fields Are Badly Designed

• Smashing Magazine article by Adam Silver, describing what’s wrong with the text fields in Material Design (Google’s design system).
• Material Design uses “float labels”: text that appears in the input, like a placeholder, but moves above the input when you focus on the element. This is better than relying on placeholders, which disappear on focus, and which can make it hard to remember what the input is for.
• However, float labels share the other drawbacks associated with placeholders; namely:
  • Float labels that are longer than the input itself get cut off.
  • The presence of text inside the input can make it appear as though it’s been filled in already.
  • As a result, in order to help the user distinguish between inputs that have been filled in and those that have not, float labels tend to have poor contrast, making them harder to read.
• Adam concludes that Google sacrificed usability for minimalism, and that forms that use conventional text labels can be beautiful too.

Accessible motion: why it’s essential and how to do it right

• Stephanie Cree shares some good UX tips for making your motion accessible:
  • Keep animation at the point of focus, to prevent zoomed in users from missing it outside the part of the page they’re zoomed in on.
  • Avoid flashes more than 3 times per second, which could trigger epileptic seizures.
  • Avoid parallax scrolling where the background and foreground move at different speeds, which can cause motion sickness.
  • Keep animations shorter than 1 second long.
  • Provide a setting to turn off all motion on your website. And, to facilitate this, you’ll need to design all elements of the page with and without motion.

Amazon Echo Show 8 extends the power of Alexa to people with disabilities

• An article from last November, reviewing the accessibility of Amazon’s Echo Show 8. It highlights a bunch of accessibility features I’d never considered the Echo devices to have:
  • Like phones and tablets, it has a pinch-and-zoom feature to allow you to magnify the screen.
  • Using VoiceView – Echo’s built in screen reader – information on the screen can be swiped through and interacted with by a blind person.
  • Screen colours can be inverted, providing higher contrast, and there are colour correction modes for colour blindness too.
  • Finally, Alexa Captioning shows subtitles for Alexa responses, making the devices viable for deaf users.

Hiding Content Responsibly

• Kitty Giraudel writes about the HTML attributes and CSS properties commonly used to ‘hide’ content, either visually or from assistive technologies (AT), or both. They then go into detail on each one:
  • An sr-only class is great for visually hiding something while preserving it for AT.
  • aria-hidden is great for hiding content from AT while keeping it visually displayed (e.g. decorative SVGs). However, make sure that there are no focusable elements within these areas, as they are still focusable.
  • display: none or the hidden attribute hide content from everyone, although their contents can still be referenced via aria-describedby/aria-labelledby, which could be handy to avoid vocalising something twice. Use this over width: 0 and height: 0.
  • visibility: hidden hides content visually and from AT (equivalent to display: none) but keeps the space, helping to avoid layout shift. Generally you’ll want to use this over opacity: 0 and clip-path: circle(0), which are inconsistently treated by AT, and over transform: scale(0), which has limited uses.
  • You’ll also want to use visibility: hidden over the Chrome-only content-visibility: hidden, which has low browser support.

Gold Nanoparticles Inside Contact Lenses Correct Color Blindness

• Researchers in the United Arab Emirates have developed contact lenses that could help correct red-green colour blindness. The lenses are created with gold nanocomposites and hydrogel, creating pink-tinted lenses. These could be a popular alternative to tinted eyewear. The next steps will involve human trials.

WordPress.org Removes Fake Reviews for AccessiBe Plugin

• Accessibility consultant Joe Dolson noticed a pattern amongst the reviews for the accessiBe WordPress plugin, which had 31 five-star reviews, 2 four-star reviews and 2 one-star reviews. Many of the accounts of the positive reviews had interacted with some of the same plugins, and tended to be one-sentence reviews. WordPress removed the majority of the reviews, leaving 3 one-star reviews and 1 five-star review at the time of writing.
• accessiBe has repeatedly come under fire for claiming that their overlay automatically makes your site WCAG-compliant. Adrian Roselli refutes this in detail, and presents evidence that suggests the company has paid for praise before.

Inaccessibility Warnings in the Browser anyone?

• An interesting proposal by Martin Mengele: should we show warnings in the browser when a site is deemed to have accessibility issues? The warning about insecure connections, which all modern browsers now display prominently when connecting over HTTP, helped to drive a large HTTPS adoption; Martin argues that an equivalent for accessibility could be the visual deterrent some websites need.

The Automated Accessibility Coverage Report (PDF)

• Thanks to GDS colleague Anika Henke, who discovered this report via the “Accessibility Testing Coverage: Automation and Intelligent Guided Testing” talk at axe-con. According to the report, Deque’s accessibility testing engine axe-core finds 57.38% of accessibility issues, rather than the “widely accepted belief that automated accessibility testing only provides 20-30% of accessibility testing coverage”.
• The discrepancy comes from theory vs practice. The 20-30% figure is the proportion of all possible accessibility issues that can be detected with tools, whereas the 57% figure comes from issues actually found on these sample websites.
• In addition, the 20-30% figure only counts unique issue types, whereas the 57% figure takes into account the number of times each issue occurs. In other words, if an issue that can be detected with automated tools accounts for a large proportion of all accessibility issues in the wild, then it’s reasonable to conclude that automated tools do in fact detect a larger proportion of accessibility issues than theorised. Deque hopes that this report will “remove the stigma attached to automated testing”.
• It’s worth noting that Deque analysed new client sites in getting the statistics for this report, which is based on the analysis of over 13,000 pages.

Imagining native skip links

• A proposal by Kitty Giraudel that is so brilliant, it’s a wonder it hasn’t been thought of and implemented already: native skip links.
• Every website ought to have a “Skip link” link as the first thing a keyboard user tabs to in the page. This is important for keyboard users and screen reader users, so that they can jump directly to the main content of the page (usually the <main> element or the first <h1>), skipping over all of the menus and header content that is duplicated on every page.
• Building these “skip links” isn’t difficult, but many sites fail to implement them, or do so incorrectly. So why not make it the responsibility of the browser?
• Kitty is clear that a native skip link should have as little customisability as possible, from the website’s perspective. All we should be able to set is the destination of the link, via a <meta> or <link> tag such as <meta name="skip-link" value="#content" />, where value is a CSS selector referencing a node in the DOM.
• Kitty even proposes a polyfill that sites might run to decide whether or not to include their bespoke skip link (in the event that the browser doesn’t have one natively). Not that this matters hugely in practice, as Kitty points out that a native skip link would not interfere with a bespoke one in any way, since the focus would have shifted over the bespoke skip link by the time it would have been reached.
• If you like the idea, be sure to +1 it on the WebWeWant GitHub discussion!

HTML test cases

• A useful resource for testing: a complete list of form controls, and a table of how their associated labels/legends are announced by screen readers. For example, check out input type="url" – the page describes what is announced on VoiceOver, NVDA and JAWS in Chrome, Firefox, Safari and Edge. Each page has an example of the form control for you to test your screen reader on too. Worth bookmarking!

Disabled buttons don’t have to suck

• Product designer Justine Win describes three alternatives to using disabled buttons, which can otherwise lead to a confusing experience (“Why can’t I click this?”):
  1. Only show what’s actionable (i.e. don’t show the button in the first place)
  2. Provide context (i.e. show the disabled button, but pairing it with additional information – see screenshot above)
  3. Enable the button by default, then show error as needed. For example, a login form where the login button is enabled, but if you don’t fill in the username or password field, a validation error is shown.

Building an Accessibility Library

• Stephanie Hagadorn, UX Design Lead at Indeed, writes about the creation of the “A11y Annotation Kit“. This is a Figma-based ‘accessibility library’, designed to improve the handover from designer to developer and prevent both roles from making the same old accessibility mistakes around things like colour contrast issues.
• See the screenshot above: designers can, for example, use grey and red numbered dots to indicate the desired reading and tab order of a component. In addition, the kit gives designers a constant refresher and summary of a11y guidelines, which have been translated from the more “verbose” WCAG specifications.
• Stephanie says: “All components are prefilled with the correct CSS or HTML elements so designers don’t have to remember things like the autocomplete value for a street field (it’s “address-level1”) or the correct landmark role for a footer (that’s “contentinfo.”). This helps developers use the right values as well.”

How to make “Read more” links accessible

• “Read more” links are a poor experience for screen reader users, who often browse the web by navigating lists of every link in the page. Therefore, each link should make sense when read out of context; “read more” doesn’t.
• This article lists six different ways to improve your “read more” links:
  1. Change the link text to be more descriptive, which has the benefit of benefiting sighted users too.
  2. Hidden text within the link, e.g. Read more <span class="sr-only"> about what Digital Access do</span>
  3. Remove the “read more” link – it often repeats a link slightly further up in the DOM, so has no real purpose.
  4. Nest the “read more” link in a contextual element. This was a new one for me: WCAG actually allows links that don’t make sense out of context, provided it is nested in an element that does provide the context, which might be a paragraph, list item, table cell, whatever. Screen readers can be made to “read the current sentence” relatively easily, so screen reader users can get context this way, though it is less intuitive.
  5. Use aria-label on the link, to replace the link text.
  6. Use aria-labelledby to reference other text on the page (such as the heading). <h2 id="heading">Digital Access</h2><a id="read-more" aria-labelledby="read-more heading">Read more</a> would be read out as something like “Read more Digital Access, link”.
• Note that “read more” links make for a poor user experience, but many implementations are not inherently inaccessible. There’s a dedicated “Read more” example on Success Criterion 2.4.4: Link Purpose (In Context) which confirms that these links don’t fail that SC, provided that the context can be derived from the surrounding paragraph (solution number 4 in the article above).

This Free App Reads Money for People Who Are Blind or Visually Impaired

• EyeNote is a free app for iOS, which can recognise US bank notes using your device’s camera. Only half the note needs to be visible for it to be recognised, but the app can’t detect whether or not notes are counterfeit.
• There is a privacy mode which, when activated, uses vibrations or audible beeps (‘pulses’) rather than announcing the value of notes with a voice. For example, one dollar is one pulse, two dollars is two pulses, and five dollars is three pulses.

Beautiful accessibility with Floating Focus

• Dutch tech agency Q42 have published an NPM package – @q42/floating-focus-a11y – which embodies a new approach to styling the :focus state of form controls and links. Their solution animates the outline from one tabbed control to the next, making it easier to keep track of where the focus is at all times, particularly if your focusable elements aren’t very close together.
• You can see this in action on the Rijksmuseum website. I actually really like the effect, although it is quite complex under the hood and doesn’t work without JavaScript, so you’d still want to provide some fallback focus styles for when JS isn’t available, somewhat defeating the purpose of the project. And of course, there is a whole school of thought around not disabling native browser focus styles. But it is an interesting UX nonetheless, and attempts have been made to consider accessibility, such as not rendering any animation when prefers-reduced-motion is set.

Show/hide password accessibility and password hints tutorial

• Nicolas Steenhout describes how he implemented a standard show/hide feature for password inputs, with accessibility in mind. Show/hide is useful for those with memory issues, or essential tremors, or anybody who wants to double-check what they typed in. Nicolas’ tutorial is for a registration form rather than a sign in form, but much of the advice applies to both.
• Password constraints (e.g. “Minimum 8 characters”) should be visible up front, not only shown after a failed form submission. These constraints should be in a list that is aria-hidden, alongside the same information in a paragraph that is visible to screen readers only (class="sr-only"), as the paragraph is less verbose than the list.
• The input should go after the hint, and should have an aria-describedby associated with the hint. It should have aria-required="true", rather than HTML’s native required, as the latter announces the input is “invalid” the first time it receives focus (and thus still empty). Finally, it needs an autocomplete with a value of new-password, in this example, or current-password for a sign-in form. (This attribute is used by password managers).
• Now for the show/hide functionality: this should be a <button role="switch" aria-pressed="false">. When it is pressed, you should change the value of the input from password to text, and update the aria-pressed value on the button.

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

We begin with some special WCAG 3.0 coverage, in which I’ve read and summarised a two-parter by deque.

Part 1: What to Expect From The First Public Working Draft of WCAG 3.0

• WCAG 3.0 is designed to be easier to learn than its predecessors. Instead of ‘success criteria’, we have ‘outcomes’. The former concern the content of a web page, and are evaluated as either a pass or a fail. The latter are centered around user needs, and are scored from 0 (very poor) to 4 (excellent).
• Instead of using levels A, AA and AAA, WCAG 3.0 uses bronze, silver and gold. The current working draft of WCAG 3.0 only focuses on the bronze level, which is roughly equivalent to WCAG 2.1 A and AA compliance. WCAG 3.0 is not likely to be published as a W3C recommendation until 2023 at the earliest.
• WCAG 3.0 has a concept of ‘critical errors’, an example of which would be if an image missing alternative text prevents a user from completing a task. Sites which contain even a single critical error will not conform to any level of WCAG 3.0 compliance.

Part 2: First Public Working Draft of WCAG 3.0, A Brief History

• WCAG 1.0 was published in 1998, and was designed to help developers write accessible HTML.
• The W3C released the first working draft of WCAG 2.0 in 2001 and was designed to be applicable to all manner of competing web technologies including Flash. It was eventually published as a recommendation in 2008.
• WCAG 2.0 was republished as an ISO standard (ISO/IEC 40500) in 2012, making it easier for governments around the world to use it in law.
• In February 2017, the first draft of WCAG 2.1 was published, to address gaps in WCAG 2.0 concerning cognitive disabilities, low vision, and mobile devices. It was published in 2018.
• The first draft of WCAG 2.2 was published in February 2020 and is expected to become a recommendation this summer.
• WCAG 3.0 began life as “Project Silver” in 2016.

Fancy reading more on WCAG 3? You may be interested in An insider look at WCAG 3.0, by Jeanne Spellman, co-leader of the WCAG 3.0 project.

Now, on with the rest of the newsletter…

Accessible interactions

• Jeremy Keith describes his approach to building accessible ‘toggled content’: accordions, menus, modal dialogs and tabs.
• The first step is deciding whether the trigger should be a button or an anchor link. Jeremy bases this decision on the distance between the target and the trigger in the DOM:
  • If the target is far away, a link is better, as if your JavaScript doesn’t load then at least you’ll be taken to the right part of the page. You’ll also want to focus the target.
  • If in doubt, use a button, designed for general purpose activity. You probably don’t need to shift the focus.
• At this point there’ll be an addEventListener, tabindex, and optional focus(). You’ll also want a aria-expanded="false" on the trigger and an aria-hidden="true" on the target by default. When you activate your trigger, its attribute should update to aria-expanded="true" and the target to aria-hidden="false".

Apple Executives’ Bonuses to Be Tied to Their Performance With Respect to Accessibility and the Company’s Other Core Values

• Beginning in 2021, Apple will increase or decrease bonuses paid to its executives by a new ‘modifier’ worth up to 10% of their pay. It will be based on a performance evaluation with respect to Apple’s six core values: accessibility, education, environment, inclusion and diversity, privacy and security, and supplier responsibility.
• Apple doesn’t elaborate on how it will evaluate performance against these values, but it’s an interesting incentive and an example of what what some organisations are doing to maintain or improve the accessibility of their products, policies and services.

Do accessible websites still need to support Internet Explorer 11?

• IE11 was introduced in 2013 for Windows 7 and 8. Microsoft dropped support for IE11 in November 2020, but continues to provide security updates. Microsoft Edge replaced IE11 in 2015.
• IE11 accounts for around 1.4 – 2.5% of global site traffic, but the figure is higher amongst assistive technology (AT) users: as of 2019, 12.5% of screen reader users use IE11 (mostly with JAWS).
• Some ATs are still recommending pairing with IE11, though usually suggest an alternative too. For example, Dragon NaturallySpeaking recommends IE11 or Chrome.
• IE11 has a number of accessibility features, most of which are also offered by competing browsers (including Edge). One feature IE11 has, that Edge does not have, is the ability to natively override the fonts used in web pages, and also to add custom stylesheets. There are, however, extensions available that bridge the gap.
• Hassell Inclusion have tested JAWS v18 and Dragon NaturallySpeaking v14 on IE11 and other modern browsers. Where IE11 and Chrome worked as expected for both technologies, JAWS with Edge wouldn’t read out error messages linked to input fields with aria-describedby, and Dragon found it difficult to follow links or moving between browser tabs.
• In conclusion, Hassell Inclusion currently recommend that websites continue to support IE11, until Edge improves its offering for AT users. This is also in line with GOV.UK recommendations.

I’ve seen a lot of social media hype around the improved accessibility of the new White House website. So I read a couple of articles to find out more:

Under Trump, WhiteHouse.gov was a disaster. Biden’s team revamped it in 6 weeks

• This article looks at some of the new features of whitehouse.gov. There’s a high contrast dark mode, and a toggle for increasing the global font size. The team behind it have also worked hard to make the site load fast, [and were even responsive to feedback from our own Matt Hobbs]. Jenny Lay-Flurrie, Chief Accessibility Officer at Microsoft, reviewed the site for accessibility and found no issues, though more can always be done, such as adding sign language to videos.

What does the Biden Presidency mean for accessibility?

• Karl Groves does some navel-gazing at what the Biden Presidency might mean for accessibility more widely. Currently, 20 to 40 ADA (Americans with Disabilities Act) lawsuits are filed in US Federal Courts every day for accessibility violations on websites and mobile apps. Many, Karl argues, are opportunistic in nature.
• What muddies the waters further is that there’s no official standard for ADA compliance. In practice, settlements or judgements mostly measure against WCAG 2.0/2.1 at AA level, but Karl expects Biden’s administration to clarify the technical requirements for ADA (after – he says – the Obama administration deferred it). He also expects further momentum around Project Civic Access.

In other news…

Writing Alt Text for Data Visualization

• Amy Cesal guides us through the W3C guidelines for alt text for complex images. I actually learned a lot from this article:
• There’s a longdesc attribute for images, which can refer to other areas of the page. E.g. <img alt="Short description" longdesc="#desc" /><div id="desc">Long description goes here</div>.
• Screen readers read alt text linearly, meaning they can’t go back a word if they missed something – so keep it short.
• Supplement with a link to the raw data, so curious readers can access the data in their preferred program. But don’t put the link in the alt text – it needs to be clickable.
• Alt text for charts should generally follow the pattern [CHART TYPE] of [TYPE OF DATA] where [REASON FOR CHART]. For example, “Line graph of number of bananas sold per day in the last year where the winter months have more banana sales”.
• Finally, Amy describes how to add alt text on popular platforms such as Twitter, Medium, Microsoft Office and Instagram (which I didn’t know supported alt!).

How to Communicate with People Who are Blind or Vision Impaired

• An article by World Eye Cancer Hope, from October 2020, which I’ve been meaning to read for a while. It contains lots of handy do’s and don’t’s:
• Do ask if they want assistance, and how they’d like it (e.g. “Would you like to take my arm?”). Do describe your surroundings, e.g. “We’re about to go up some steps”, or “Attendees of this event are standing in small clusters near the buffet table”.
• Don’t fill glasses or mugs to the brim. Don’t seat them at a table when everybody else is standing. Don’t limit the options you give because you think explaining all the options will take too long. Don’t manhandle, and don’t distract Guide Dogs.

Nike’s latest FlyEase shoe slips on without zippers, laces or straps

• The Go FlyEase trainers require no hands to put on, thanks to their hinged kickstand design. You simply press down the heel of one foot with the other, and step out of the shoe (see gif). You can read more details on how the mechanism works, or watch the video about its design.
• The shoe will retail at $120, and is available from 15th Feb on an invite-only basis for Nike members. It will be made available to the public later this year.
• It was inspired by Matthew Walzer, who wrote a letter to Nike in 2012, at the age of 16. Matthew, who has cerebral palsy, has limited flexibility in one of his hands and found it impossible to tie his shoelaces, so appealed to Nike to help.
• Matthew is happy with the result, noting that it embodies the concept of “universal design”. Anyone can wear the shoes: they’re not just marketed as an accessibility feature. Everyone can benefit.
• This story was shared by subscriber Nick Levinson – thanks Nick!

CAPTCHA Be Gone

• I’ve just heard about this product by AccessibleApps, which fills in CAPTCHA forms for you. For the uninitiated, CAPTCHAs are those anti-bot questions which try to make you prove you’re human by, for example, showing you a garbled image and making you type out the letter and number sequence contained within it.
• CAPTCHA Be Gone is an extension for Chrome, Firefox and IE, aimed at visually impaired and deafblind users who find it difficult or impossible to complete any form which has a CAPTCHA.
• Listen to a demo of it working: it’s slow (taking around 15 seconds), but seems to work. It’s not free though, costing $3.50 per month. There’s a seemingly impartial review which is positive about its price and effectiveness.
• It’s great that this is a solution to a real problem faced by users. But it raises two points from me:
  1. If a browser extension can solve a CAPTCHA, what’s the point of having a CAPTCHA in the first place?
  2. Having a disability already comes with a price tag; it’s unfair that these users need to pay for workarounds just for basic website access.
• Hopefully the web can move on from frustrating CAPTCHAs in favour of more accessible alternatives.

Form design: multiple inputs versus one input

• Blog post by Adam Silver, explaining why splitting inputs can be problematic. A technique often used for credit card numbers and bank sort-codes, I’ve often found such forms quite slick, but hadn’t considered some of their accessibility downsides:
  • Multiple inputs mean users can’t easily paste information in, unless JavaScript has been written to allow it (which may not be obvious to the user).
  • It can be difficult to correct mistakes if the form auto-focuses the next input in the sequence.
  • Each input is difficult to label meaningfully. The label is often hidden from sighted users, if provided at all, and makes for a noisy screen reader experience.
• Instead, Adam encourages us to allow free-form text and to be forgiving of extra spaces and dashes in inputs. The exception is dates, where multiple inputs should be used, to clarify which portion of the date is the month and which is the day (as this varies around the world).

Glove translates sign language in real-time – ’99 percent recognition rate’

• A Daily Express article from last summer. Bioengineers at the University of California have developed a glove that can translate sign language into speech in real-time, using an accompanying smartphone app.
• The glove has thin sensors running to the fingertips, which can detect motions. The smartphone app uses a custom machine learning algorithm to convert the gestures into letters, numbers and words, and can recognise 660 signs. It translates at a speed of one word per second, with an accuracy rate of 98.63%.
• The glove has its critics. Gabrielle Hodge, a deaf researcher at University College London, says: “there is nothing wrong with [sign language as a] form of communication” and that the technology is “redundant”, due to deaf signers already making extensive use of text-to-speech software.

The Readability Group – Survey

• The Readability Group is a collection of experts in design and accessibility. Their mission is to “optimise typographic accessibility by providing expert advice based on data, not anecdote”. Essentially, they want to gather real user feedback on the readability of typography.
• Please take around twenty minutes of time to contribute to the “Readability survey”, which has been nearly 2 years in development!

Infinite Scroll: What Is It Good For?

• Article exploring the pros and cons of infinite scroll. The pros were simply “seamless mobile scrolling” and “serendipitous browsing”. The cons were numerous:
  • Could contribute to social media addiction.
  • Might make sidebars and other content inaccessible to assistive technology users.
  • Makes footers impossible to reach.
  • Causes users to lose their place (especially when hitting the ‘Back’ button).
  • Slows down users who have specific goals (e.g. wanting to jump to a letter midway through the alphabet).
• Tips to improve infinite scroll implementations:
  • Don’t place content below the infinite scroll.
  • Code in some logic to allow ‘Back’ interactions to keep their place.
  • Let user skip to particular numbers/letters.
  • Ensure it works for keyboard users.

Accessibility auditing and ego

• A very popular article among a11y newsletters at the moment. Eric Bailey reminds us that WCAG is a standard, that sets “objective criteria for what is and is not accessible”. In other words, you might hate the design of a website, but it might conform to all WCAG criteria. Don’t creatively reinterpret what a Service Criterion says to fit your agenda.
• As a designer, you can appeal to a product’s usability, giving subjective feedback grounded in objective origins. But in an auditing context, you have to kill your ego and only point out failures that map to WCAG rules.
• Eric says you should think like a lawyer: every call you make might have to be defended in a court of law [it’s worth noting that this article is written from an American point of view]. That is to say, “stay in your lane”, by sticking to established, legally accepted parameters, i.e. WCAG.

ProPublica experiments with ultra-accessible plain language in stories about people with disabilities

• News organisation ProPublica ‘translated’ one of their articles into plain language, in an effort to be more accessible to people with intellectual/developmental disabilities.
• Here’s the original article: People with Developmental Disabilities Were Promised Help. Instead, They Face Delays and Denials.
• And here’s the plain text version: Arizona Promised to Help People With Developmental Disabilities. But Some Had to Wait a Long Time. Some Did Not Get Help at All.
• It’s fascinating to read the articles side by side and see how they compare. The plain language version simplifies sentences, writes in active voice, and uses bullet points for lists.

12 Common Words and Phrases You May Not Realise Are Ableist

• Some of these seem fairly obvious, but others less so. With respect to autism, “high or low functioning” is an ableist term I hadn’t considered. ‘Differently abled’ and ‘special needs’ are also poor euphemisms for the term ‘disabled’. ‘Tone deaf’ and ‘blind spot’ are also terms in common usage, but which harmfully link deafness/blindness with ignorance.
• The other phrases this article considers ableist are ‘imbecile’, ‘crippled’, ‘spastic’, ‘lame’, ‘suffering’ (as in “suffering from [disability]”), ‘wheelchair bound’ (in reality, many wheelchair users find their wheelchairs liberating) and finally, a saying I hadn’t heard before: “See the Able, Not the Label”.

How to start testing screen reader support using VoiceOver

• Article by Yakim van Zuijlen, describing how to use VoiceOver on a Mac to test your website. It’s aimed at beginners, but goes into quite a lot of detail, including how to find items by type (e.g. blockquote). There are some beautiful, clear illustrations throughout the article, showing which keys to press to trigger shortcuts, or how elements in the browser are grouped together by VoiceOver.

5 Ways You’re Not Making Your Website Accessible

• A listicle by Twan Mulder, which I wasn’t expecting to learn anything from – but then I learned something from the very first point! It was this:
• You often need to denote the ‘current’ page in navigation, and you see this in the wild with class="active" or similar in the markup. Instead, it should use aria-current="page", to tell screen readers this is a link to the same page they’re already on.
• The other tips are to use aria-hidden to hide decorative separators between links; add visually hidden text to your icon links; apply ARIA markup to your <div> if you insist on not using a <button>; and, somewhat obviously, provide alt text for your images.

Empathy and innovation: How Microsoft’s cultural shift is leading to new product development

• Microsoft software engineer Swetha Machanavajhala is deaf and relies on lip-reading. Whenever she Skyped her parents, she had to ask them to turn the lights off behind them so that she could more easily focus on their faces.
• She wondered if technology could solve this problem for her, so worked with Microsoft to build a background-blurring feature for Microsoft Teams and Skype (it’s not clear in the article exactly how Swetha achieved this). This feature has a useful side-effect as being a privacy tool to help users hide their backgrounds during calls.
• Thanks to Lee Goudie for pointing me towards this excellent example of Universal Design!

I’d like to end with a shout-out to Jack McElaney’s excellent newsletter, Accessibility in the News, which is packed with content every week. It’s heavily skewed towards American news, but there’s an international section too, and I look forward to receiving it every Friday.

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

Lists

• A Jeremy Keith entry from his journal. Lists are helpfully announced to screen readers when they are navigated to (e.g. “List: six items”). However, Webkit browsers such as Safari don’t announce lists if the lists’ bullets have been removed using CSS (just like it doesn’t announce content that has been visually hidden with display: none). There’s a Twitter thread explaining why, but it boils down to this: “If a sighted user doesn’t need to know it’s a list, why would a screen reader user?”
• If you’ve removed bullets but your content is a list (you may have used some visual replacement for bullets, e.g. image markers), you can force screen readers to treat your content as a list by adding role="list".
• There’s an interesting point about “pixel perfection” across browsers, too. It’s widely considered to be an unattainable or undesirable goal nowadays; why should we demand the aural equivalent? Websites don’t need to sound identical in every screen reader.

VoiceOver Preview for macOS Firefox

• Mozilla have worked hard over the past year to deliver VoiceOver support for Firefox on macOS – something that had been lacking for 15 years. It’s now ready to try in the Firefox 85 Beta and Mozilla are calling on volunteers to try it out and report any bugs they encounter. Other than a few known issues, it is hoped to be fairly stable.

Equal Entry Guidelines for Describing 360-Degree Video

• An interesting set of guidelines describing the challenges of audio-describing a 360 degree video (which will become more prevalent as VR grows). You should divide the video into scenes, write a brief introductory description for each scene, then write audio descriptions for each direction a viewer could face during the scene. Consider ‘forward’, ‘left’, ‘right’, ‘backward’, ‘up’ and ‘down’ views. See the demo on YouTube.

Below I summarise not one, not two, but three articles. It’s my attempt to clarify what seems quite a contradictory issue: whether you should ‘try on’ a disability to build empathy, and/or build better products and services. As someone who has written a series of articles on using the web under various constraints, it’s a subject close to my heart and an important conversation to have.

Article 1: Why I won’t “try on” disability to build empathy in the design process (and you should think twice about it.)

• Amelia Abreu describes how accessibility workshops that, for example, have able-bodied participants trying to navigate a high street with wheelchairs to gain awareness of shortage of ramps, can be counter-productive. A research paper concluded that short-term mimicking of the effects of a disability can a) result in fear, apprehension and pity, b) fail to account for diverse coping mechanisms people develop over time, and therefore, c) cause participants to underestimate the true capabilities of persons with disabilities.
• Instead, Amelia suggests we build relationships with real people with disabilities. Get to know their diverse interests and accessibility concerns, and ask how you can be an ally for disability rights. Also, to draw upon your own experiences. In the wheelchair example, Amelia developed an awareness of the inaccessibility of infrastructure when she had to take her daughter around in a stroller.

Article 2: Going Colorblind: An Experiment in Empathy and Accessibility

• This article appeared a month before the first, and on the same website! Sara Novak describes her colleague Peter’s deuteranomalous colour blindness, affecting 5% of men. It means he has a hard time differentiating greens from other colours. Sara admits she was sympathetic, rather than empathetic, so talked to Peter and decided to see what it’s like to be colourblind for three days, using Chrome extension See.
• Sara realised she’d been colour-coding her responses in emails, and that this was difficult to decipher. She realised why Peter bolded important info in emails rather than rely on colour, and she started to do the same. She also encountered inaccessible web forms which used colour alone to convey error state.

Article 3: Get the Funkify Out: A Neat Accessibility Tool/Disability Simulator

• Michael Larsen writes about the “Funkify Disability Simulator” Chrome extension, which attempts to simulate what it’s like to browse the web with dyslexia, astigmatism, jittery hands and high distraction (much like GDS’s own accessibility personas). With it, Michael was able to create a custom profile that makes a page look “very much like it would without my reading glasses”.

In conclusion, I’m not convinced I have a definitive answer. These were all useful articles and I learned something from each, but this is still a topic on which I’m uneasy and am keen to keep learning about.

Can I use a screen reader and know exactly what it’s like to be a blind person? No, of course not – there are all manner of lived differences.

Can I use a screen reader to test my product? Yes, of course – without testing, we’ve no hope of finding and fixing accessibility issues.

Can I use a screen reader to build empathy? This is more complex. In Sara’s case, it seems she did build empathy for her colourblind colleague through use of a simulator. Perhaps the key is that she didn’t empathise in isolation; she was engaged with Peter and able to ask questions and compare her simulated world view with his. In contrast, I can see how a first time screen reader user with no point of reference could be overwhelmed and unable to navigate, and in turn develop a misguided view of what a blind person is capable of doing.

The articles above were hand-picked from various accessibility newsletters I’m subscribed to. If there are other articles that you recommend, please do send them my way!

---

State-Switch Controls: The Infamous Case of the “Mute” Button

• An article exploring the design of ‘mute’ buttons on the iPhone ‘call’ screen, on Zoom, and on WebEx. Two of the three use fill colour alone to denote state: the universal microphone icon has a dash through it, regardless of what state you’re in, making it difficult to know whether your microphone is currently muted. Zoom is the one that gets it right, as it removes the dash from the microphone when your mic is active, and has a label on the button to indicate what will happen when you press it.
• Aside: I still struggle with Zoom’s implementation, and have yet to find one that doesn’t confuse! Perhaps the best I’ve seen is Google Hangouts’ version, but that could just be down to familiarity as I use it every day.

WordPress adds support for video captions and subtitles

• WordPress v5.6 “Simone” introduces WebVTT support for its videos. This is a big deal considering WordPress powers around 4 out of 10 websites. It means you can upload .vtt files containing subtitles, to enable closed captions on the video. The article gives a nice example of a VTT file, which is just text formatted in a particular way.
• Many WordPress hosting providers aren’t actually well suited for streaming videos, so the author Jon Henshaw recommends uploading the video itself to a CDN, even if you self-host the VTT file.

The lang attribute: browsers telling lies, telling sweet little lies

• Manuel Matuzović shares some useful CSS that can alert you to a missing, empty or incorrect page-level lang attribute. For example:
• html:not([lang]) { border: 10px dotted red; }
• Manuel explains why setting the right value is important for screen reader support, as well things like auto translate.
• There’s an interesting section on quotation marks, highlighting the difference in style between English, German and French quotation mark notation. I wasn’t aware they were different!

Interaction Media Features and Their Potential (for Incorrect Assumptions)

• A really interesting CSS-Tricks article by Patrick Lauke, exploring the Media Queries Level 4 Interaction Media Features.
• In theory, they enable the detection of things like if the user is using a mouse or a touch screen (@media (pointer: fine|coarse) {), which you could use to decide whether to make buttons and touch targets bigger. It also exposes hover support: @media (hover: hover|none).
• In practice, these queries only expose what the browser thinks is the primary input. The user may have a mouse but choose to use their touch screen, or may have an iPhone but primarily navigate via a Bluetooth linked keyboard.
• There is another set of media queries that report on all available inputs: any-pointer and any-hover. If any of the inputs has hover support, for example, then any-hover: hover will be matched.
• We can combine queries for educated guesses. @media (pointer: coarse) and (any-pointer: fine) suggests the primary input is touchscreen, but that there is a mouse or stylus present.
• We risk breaking the user experience by optimising for the wrong input type. We should follow a progressive enhancement approach, e.g. always listen to mouse/keyboard events but also listen for touchstart events if a coarse pointer is detected. Another option is to provide users an explicit choice of ‘Mouse’ vs ‘Touch’.

Accessibility in tech improved in 2020, but more must be done

• A mammoth article highlighting the key accessibility improvements made by the 6 giants of tech: Apple, Google, Microsoft, Amazon, Facebook and Twitter. There’s a small conclusion at the end, briefly mentioning a few household names that have yet to fix fundamental issues in their apps, but the majority of the article is focused positively on the companies above.
• I learned that Microsoft deliberately designed Xbox Series S/X boxes so that they could be more easily opened unassisted by people with disabilities, and that the consoles’ ports have tactile nubs to help low vision users identify them. I also learned that Amazon have teamed up with Voiceitt – a speech recognition company – to make Alexa usable by people with speech impairments.
• Thanks to Matt Hobbs’ Frontend Fuel for linking me to the article.

Death of the PDF? Not quite, but it’s great news for accessibility

• Danny Bluestone writes about the significance of the change in content design guidance on GOV.UK, which came into effect on 7th December. The updated guidance states “If you publish a PDF or other non-HTML document without an accessible version, you may be breaking the law”. Government departments are expected to phase out their usage of PDF as a way of publishing content.
• The article highlights some great reasons why PDFs don’t work well online: they’re not responsive (so don’t scale on mobile), it’s difficult for visually impaired users to change their colour scheme and text size, and they easily become out of date as they’re harder to maintain.

Microsoft Backs Development of Smart Cane for Visually Impaired

• An interesting idea from London-based startup WeWalk, who have recently joined Microsoft‘s AI for Accessibility program. Their ‘smart cane’ uses ultrasonic object detection to spot hazards such as parked cars, and paired with a smartphone app also features turn-by-turn GPS navigation and taxi-booking facilities. The cane will retail at $600.

Is Progressive Enhancement Dead Yet? (video, 8 mins)

• Another Heydon Pickering ‘Web Briefs’ video, with a somewhat clickbaity title. This isn’t an analysis of frontend strategies in 2021, but a characteristically opinionated explanation of what good vs bad progressive enhancement looks like. In it, Heydon reinforces that:
• Sites should be functional and have decent layouts by default. Using CSS supports checking, you can progressively enhance to better layouts, and should not use JavaScript to ‘fill in’ unsupported CSS because it’s inefficient at rendering. JS modules should be imported using <script type="module">, which is ignored by older browsers.
• Progressive enhancement is not displaying a “Please turn on JavaScript” message, or rendering HTML only for it to re-render with JS ‘hydration’.

Focus management and inert

• Article by Eric Bailey, reminding developers to avoid manually specifying a tab order with tabindex="[positive integer]" (there is, arguably, never a good reason to do this). But using tabindex="-1" is great for building accessible widgets: it makes elements focusable with JavaScript or click/tap, where it would otherwise not be focusable (i.e. if it is not a link, a button or an input).
• One of the hardest things to get right is “focus trapping“: restricting focus events so that they only apply to elements within your modal, so that keyboard users don’t get lost tabbing through invisible elements underneath. The inert attribute makes implementation a lot easier. Assuming your modal is in a <div> outside of your <main>, apply the attribute with <main inert> and nothing within will be focusable. Browser support is extremely poor at the moment, but expect that to change in 2021.
• I learned about a screen reader mode I hadn’t heard of: “interaction mode“. This allows users to explore the page with a ‘virtual cursor’, without applying focus to any of the content. Naturally that won’t play well with your modal, so liberal use of aria-hidden="true" is the answer.

I then thought I’d try something different, and bring you five different articles on screen readers. Let me know if you enjoy #WeekOfScreenReader and whether you’d like some more themed digests like this! What better place to start than with a nice, digestible history of screen readers?

A Brief History of Screen Readers

• The first screen reader (for DOS) was created in 1986 by IBM Researcher and Accessibility Pioneer, Jim Thatcher. IBM Screen Reader/2 was developed to work with Windows 95 and IBM OS/2. To this day, Jim’s family sponsors the annual Jim Thatcher Prize, awarded to individuals who technically advance tools that improve access and increase participation for people with disabilities.
• Since 2009, WebAIM has surveyed screen reader users every year to monitor their preferences. The 2019 results show that NVDA, Jaws and VoiceOver are the most used on desktop/laptop, and VoiceOver on mobile.
• The article – as the title suggests – is brief, and jumps straight to present day screen readers, with a one line summary of their histories:
  • JAWS (Job Access With Speech) was developed by Freedom Scientific, for DOS and then Windows.
  • NVDA (Nonvisual Desktop Access) was first released in 2006.
  • Given VoiceOver’s popularity, the article offers frustratingly little by way of its history. So for completion, here are my conclusions from a quick search: VoiceOver first appeared in OS X 10.4 (Tiger) in 2005. It was then added to the iPod Shuffle – which had no screen – to read out song titles, and was intended to be used by all rather than marketed as an accessibility feature. It was first added to iOS with the release of the (third generation) iPhone 3GS in 2009.
  • Other screen readers are mentioned in passing too; I’ve added quick notes for some of these. Microsoft’s Narrator (built into Windows 2000 and above), Linux’s Orca (released in 2006 by Sun Microsystems – now Oracle), Android’s TalkBack and ChromeOS’s ChromeVox.

A message to web developers, from a screen reader user

• Holly Tuke, who is blind, explains to web developers the positive impact they can have on her web experience by following some simple tips:
  • Try to get comfortable with a screen reader – it will make it easier to spot issues in the code. Turn your monitor off to stop you glossing over mistakes.
  • As a screen reader user, Holly relies on keyboard only navigation. Get your site working with keyboard and you’re a lot of the way there.
  • The most common issues are unlabelled links and buttons, inaccessible web forms, and no heading structure (h1, h2 etc).
• 98% of the most visited websites in the world do not meet all accessibility standards. The positive thing career-wise is that “web developers who champion accessibility have an opportunity to stand out”.

A developer’s perspective: the problem with screen reader testing

• Jake Tracey laments the sheer number of different screen readers and browser/OS combinations, and the lack of data around screen reader versions. Jake argues we can realistically only test in the latest versions of screen readers, like we do with Firefox and Chrome.
• Automated tests are well and good, but can only tell you if your code is valid. Given screen reader support for ARIA is still patchy in different browser combinations, you can only verify your website works for your users by manually testing in the same combos as them.
• The market share of desktop screen readers shows a steady rise in NVDA, which overtook JAWS as the most dominant screen reader back in 2019. For this reason, Jake suggests concentrating testing efforts on NVDA (with Windows and Chrome), as its market share is only set to increase further, especially given it is free and JAWS is paid.
• We should also test on macOS Safari with VoiceOver, iOS Safari with VoiceOver, and Android with TalkBack.
• Less popular screen readers should be tested by a dedicated accessibility tester on your team; developers won’t have time.

Thoughts on screen readers and image recognition

• Léonie Watson talks about image alt text and the fact that over 30% of homepage images are missing text descriptions. An additional 10% had useless alt text such as “image” or “blank”.
• Screen readers have Optical Character Recognition (OCR) support, which can examine a graphic and convert it to text. I hadn’t heard of this as a feature of screen readers, but a quick search shows there’s an OCR add-on for NVDA.
• Some screen readers – such as VoiceOver on iOS – now have image recognition capabilities too. I talked about this in dai11y 22/12/2020: iOS 14 can recognise icons and buttons even if they’re not marked up as such.
• Léonie tested the Picture Smart feature in JAWS on an image of the Mona Lisa. It identified that it contained a “drawing, human face, painting, person, sketch and woman”, and that it “probably” contained “art, portrait and text”. This is a good result compared to its analysis of a more obscure image, which was far less descriptive.
• She concludes: “image recognition in screen readers is a massive improvement over the absence of anything better, but it isn’t better than a text description provided by a content author who knows exactly what’s in the image, why its being used and the context its being used in.”

We finish our #WeekOfScreenReader with a double article special: technical deep dives into data tables and dialog focus:

Article 1: How screen readers navigate data tables

• Léonie Watson describes how she navigates data tables with NVDA (alternatively you can watch the video demonstration – 2 mins). Her demo table is marked up with a caption, a first row containing all <th> heading cells, and a first column containing all <th> cells. Léonie first navigates the heading columns and rows to figure out what’s in the table, then zones in on a particular row that may be of interest. Depending on whether she’s moving left/right or up/down, NVDA will either repeat the column heading or the row heading before announcing the selected cell contents. In other words, it relies on her remembering the value of the unannounced heading. This is to reduce verbosity.

Article 2: Dialog Focus in Screen Readers

• Adrian Roselli discusses creating an accessible modal, using the inert keyword described in dai11y 18/01/2021. But where should the focus go when the modal is opened – the modal itself, the heading within the modal, or the close button?
• Adrian tries out several screen reader / browser / OS combinations to hear what is announced in each of the 3 focus scenarios. The results differ wildly.
• Adrian avoids concluding where the focus should go, saying that you should test with your users. In other words, consider which focus gives the best UX for the most popular screen reader combos your audience is using.

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

What would an ethical overlay look like?

• Karl Groves writes about the ‘overlay widgets’ offered by companies such as accessiBe, and how their claim that including their product on your website will make it fully WCAG compliant is simply untrue. Many a11y issues, such as missing alt text, can only be fixed by a person. Moreover, the extra features an overlay often provides (e.g. screen magnification) are poor imitations of what’s already available to the user on their computer. The only ‘ethical’ overlay is a temporary one, Karl says: it should only be used as a discovery tool to find accessibility problems, which you should then spend time fixing the root cause of.

Accessible Game Design / Accessible Player Experiences

• I came across accessible.games while watching the 2020 Video Game Accessibility Awards. It lists the basic “access design patterns” to follow when developing your games. Examples include “second channel” (such as captioning that alerts you to incoming attacks; not just relying on sound) and “improved precision” (allowing gamers to adjust sensitivity of mouse/controller input). There are also “challenge design patterns”, which are patterns to follow once you’ve got the basics sorted, which go beyond core access into the realm of inclusion, so that people can fully enjoy your game. Examples include “slow it down“, allowing gamers to adjust game speed or reduce enemy damage so that they can successfully progress through the game.

PlayStation 5: The Accessibility Review

Pros:

• The integrated screen reader is available across the PS5 system and comes in multiple languages, which can be adjusted for speed, volume, and choice of male or female voice.
• There are a number of global settings to accommodate different types of colour blindness.
• You can set a ‘game preset’ for game difficulty ranging from Easiest to Hardest, which should map to the standard options in most games. Similarly you can indicate a preference for subtitles, inverted controls, and audio language, which games should obey automatically.
• There are options to increase text size, and to remap your controller.
• 3D Audio, alongside supported headsets, give surround sound to the player, enabling blind players to pinpoint with accuracy where enemies are (as well as improving the experience for everybody).
• The new DualSense controller has a built-in microphone, which can be used for voice-to-text. Haptic feedback in the controllers is designed to immerse the player, but can be disabled if uncomfortable.

Cons:

• The controller is larger and heavier than before, and the accessible ‘Back Button Attachment’ accessory for the PS4’s controller doesn’t fit on this one.
• The ‘zoom’ option that allowed screen magnification on the PS4 has not yet been carried over.

Under-Engineered Responsive Tables

• Adrian Roselli describes how to create an accessible table that scrolls horizontally on mobile. You need to put your <table> element inside a <div role="region" aria-labelledby="mycaption" tabindex="0">, where “mycaption” references the <caption id="mycaption"> that should be inside the table. The tabindex satisfies WCAG Success Criteria 2.1.1 Keyboard, and the aria-labelledby satisfies 4.1.2 Name, Role, Value. For the CSS, apply overflow: auto to the table, and don’t forget to apply a focus style.

Accessibility Testing is like Making Coffee

• This article by Madalyn Parker was very popular back in August. Madalyn describes accessibility testing through different coffee brewing methods, with some nice illustrations. French Press is like automated testing: quick, easy, but doesn’t catch all of the grit. Aeropress, like semi-automated testing, is a step up from that, but requires more judgement. Pour Over is like manual testing, requiring the most time and attention but giving the smoothest brew. Going to a Café is like User Testing: you’ll learn things (either how to make coffee in new ways, or how users with disabilities use your site). a11y.coffee is kind of a sister site to this article and is also worth a look.

Survey of Web Accessibility Practitioners #3

• This WebAIM survey, which was previously conducted in 2014 and 2018, is aimed at “everyone that implements accessibility, whether casually or as a primary part of your job”. It is open until January 20th 2021 and its results will be published in the same month. Please take 5-15 minutes of your day to complete the 36 short questions and help inform the web accessibility field.

Introducing the Accessibility VRCs

• A blog post from Facebook’s Oculus team, describing ‘Virtual Reality Checks’ (VRCs), which are technical requirements all apps on the Oculus Platform must meet. It covers things like security, framerates, etc.
• There is now a set of Accessibility VRCs, which are unfortunately not requirements but “strong recommendations”. A 34m video, “Designing Accessible Experiences“, explains it in more detail.
• The actual Accessibility VRCs cover things like subtitle options, distance grabbing, head-tracking alternatives, in-game feedback & direction, colour blindness support, display setting customisation and controller reconfiguration. Each link describes how to manually test the requirement, and links out to a bit more implementation detail.

Almost 50% Got This #a11y Question Wrong! — WCAG Explained (8m video)

• Eric Eggert asked Twitter if the following code fails WCAG:
• <button aria-level="2">Action</button>
• 49% thought it failed WCAG, but Eric explains why it doesn’t. This all may seem a bit hypothetical, but it’s actually quite a useful exercise in how to judge code against the WCAG criteria.
• Eric admits the code is invalid ARIA, as buttons can’t have levels (level doesn’t appear on the button role documentation, nor does button appear on the aria-level docs), but that does not constitute a WCAG failure.
• It doesn’t fail SC 4.1.1 Parsing, as the HTML can still be parsed. SC 4.1.2 Name, Role, Value also passes; it says that “states, properties, values that can be set by the user can be programmatically set”, but as aria-level is unsupported on the button element, it cannot be set by the user.
• Eric explains a couple more WCAG criteria that people cited, and why they don’t apply. Worth a watch.

My watch told me I have a leak

• An AbilityNet article describes how Google’s Live Transcribe app, which turns speech into text for live conversations, can also be trained with non-voice data. An update to the app can now identify environmental sounds such as “crying baby”, “door knocking”, “smoke alarm”, or as the title suggests, “running water”. The app can vibrate or flash for these noises, and Google announced in October 2020 that it will soon be able to notify your Android watch (Wear OS), though the ‘listening’ will still be done through a nearby phone. The next step will be to bring environmental noise detection natively to any devices that contain a microphone.

A plan for accessible maps

• Benjy Stanton describes how he would design a map service from the ground up, considering the needs of all users. Maps are inherently inaccessible – they require digital and geographic literacy as well as visual methods of communication, so they should always be seen as an enhancement. Benjy’s tips can be largely summed up as follows:
• The core content should be available outside of the map, e.g. as a data table or downloadable spreadsheet. Design your map in black and white first, to help prevent you relying on colour alone to convey meaning. Avoid pan & zoom interactivity unless they’re required. Ensure all interactive features (rivers, roads etc) are high contrast enough to see. Turn off background layers you don’t need. Test the map works on mobile and with a keyboard.

Here’s What It’s Like To Live With A Tracheostomy

• Ginny Butcher describes her experience of living with a tracheostomy (or ‘trache’): a tube in her neck, connected to a ventilator to enable her to breathe.
• She’s completed a master’s degree to become a lawyer, and has done many impressive things such as rock climbing, abseiling, canoeing and zip lining, all with a ventilator strapped to her body. She’s also flown a plane and completed a half-marathon.
• The practical aspects are that she needs to carry three bags of machines and some spare batteries at all times. One of the machines is to assist with coughing and secretions. The tube needs changing daily, which Ginny likens to something as boring as “clipping your toenails”.
• It has its upsides too – Ginny doesn’t breathe through her nose or mouth, which makes her “the absolute best at downing pints”. Worth a read!

Accessible Web Animation: The WCAG on Animation Explained

• Val Head gives a detailed overview of WCAG animation recommendations. These include:
  • “Pause, Stop, Hide“: provide a way of pausing, stopping or hiding any autoplaying animation that lasts more than 5 seconds.
  • “Three flashes or below threshold“: avoid flashing more than 3 times in a one second period, to reduce chances of triggering seizures.
  • “Animation from interactions“: any animation triggered by the user, which gives the illusion of motion (so not including things like colour or opacity change) should have an option to be disabled, as they can cause people with motion sensitivities to become ill. You can implement this with a ‘toggle’ on your site, and also pay attention to the prefers-reduced-motion media query.
• These recommendations come under different WCAG conformance levels. for example, the first two rules are level A rules – the bare minimum standard to be met. The “animation from interactions” rule is AAA, which is the highest level of conformance. In general most people aim for the middle level: AA compliance.

More Accessible Skeletons

• Adrian Roselli describes – quite late on in his blog post – why he thinks skeletons (placeholder areas to display to the user while content is loading) are a bad idea. But he also describes how he would build one if he had to.
• Some skeletons have aria-busy="true" markup, which is designed to be temporarily ignored by screen readers, though few screen readers support it. Adrian recommends pairing it with aria-hidden="true" for now at least. In practice, this means having two sibling nodes; one for the skeleton and one of the content.
  • When your content is loading, it should be hidden and have aria-busy="true", and the skeleton node should be visible. When it has loaded, it should be flipped to aria-busy="false" and the skeleton node should be set to aria-hidden="true".
  • You should have CSS which sets display: none on aria-hidden content, and on aria-busy="true" content.

How we made GOV.UK more accessible

• A team on GOV.UK analysed a small subset of representative pages to identify any violations of the WCAG 2.1 AA standard. They prioritised each issue by its regularity / likelihood of occurrence and its impact on the user’s ability to use GOV.UK. These were either technical issues, content issues or a mixture. They could generally be fixed in one central place (the Design System or components) or by an improvement in the guidance. There’s a great video on how differently marked up tables are experienced by screen readers.

iPhones can now automatically recognize and label buttons and UI features for blind users

• iOS 14 has a new feature, “Screen Recognition”, which is built into VoiceOver. It uses AI to detect interactable elements on the screen, even when such elements aren’t properly labelled / exposed to assistive technology. It has the potential to allow blind users to use apps that are otherwise inaccessible.
• I highly recommend this GadgetHacks article which goes into more detail on the feature and includes screenshots demonstrating how to enable it.
• I haven’t had a chance to try out the feature myself yet, but it looks as though you first enable the feature, then ‘opt in’ to the feature on individual apps. I don’t yet know whether that means it would work on browsers such as Safari and Chrome. If it does, this could be a game changer, as it might allow the user to navigate previously inaccessible websites.

Are your Anchor Links Accessible?

• Amber Wilson describes the HTML structure she came up with for turning headings into ‘linkable headings’, whose links can be used as anchor links to that specific part of the page. It can be tricky to implement these without making it a noisy or confusing experience for screen reader users. Here is the markup she ended up with:
• <h2 id="introduction">Introduction</h2><a href="#introduction"><span aria-hidden="true">#</span><span class="hidden">Section titled introduction</span></a>
• You could also wrap your link inside your heading, which is simpler but arguably has usability issues (e.g. makes it harder to select heading text):
• <h2 id="introduction"><a href="#introduction">Introduction</a></h2>

A placeholder is not a label

• This is your regular reminder from HTMHell that <input type="text" placeholder="First name"> is not accessible and requires an associated <label>. Some screen readers will fall back to using the placeholder if a label is missing, but it can’t be relied upon.
• There are various UI issues with a placeholder-only approach. Contrast is often too low to read the text easily (though this can be tweaked by styling with the ::placeholder rule, at the risk of making the user think the input is already filled in). Placeholders get cut off if the input is too small, and get removed as soon as you start typing, straining your short term memory.

Alexa Makes Shopping Lists Sharable as Accessibility Feature

• Alexa allows you to create lists such as shopping lists and todo lists, adding and removing items with your voice. And now, users can ask Alexa to send a given list to a specific contact. Once Alexa confirms it has identified the right person, the recipient gets a message on their Alexa account through the app. This feature is designed to help those with limited access to a grocery store connect with those who can help get them supplies in the ongoing COVID-19 situation.

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

frequent11y is now 1 year old! 🎉 Since the first issue of dai11y on 28th October 2019, I’ve published well over 200 posts covering design, technology, science and ethics in the world of accessibility. I’ve been really enjoying reading so many articles and sharing them with you, and I’ve really appreciated the nice comments and encouragement from you. Please continue to share the newsletter with your friends and colleagues.

Looking to the future – would you like me to cover any topics I haven’t covered yet? Is there a way I can improve the format? Let me know your comments by emailing me at chris@ashton.codes or reaching out to me on Twitter. Thanks in advance! Without further ado…

Intro to Web Accessibility (see video)

• What could be a more appropriate 1-year anniversary post than this excellent presentation by Michele A. Williams? In just 16 minutes she explains accessibility in great detail, starting with no assumed knowledge, and bringing the audience up to a good level of understanding about WCAG, WAI, HTML standards, Assistive Technology and team responsibilities. I learned something too – that JAWS stands for Job Access With Speech. A highly recommended watch for anyone new to accessibility!

Google Slides – Present slides with captions

• When you present Google Slides, you can turn on automatic captions to display your words in real time as you speak them (this only works with Chrome devices set to U.S. English). After you click “Present”, click the “CC” button or use CTRL + SHIFT + C (use CMD instead of CTRL on Mac). As you speak, captions appear at the bottom of the screen (but they won’t include punctuation). To change text position or size, click the drop-down menu Down arrow next to the “CC” button.

:focus-visible Is Here

• Matthias Ott writes about the situation where clicking on an element activates its :focus styles – something that can be perceived as ugly. With this new property, you can style elements if they receive keyboard focus, while avoiding styling if they receive focus via mouse click. Example: :focus:not(:focus-visible) { outline: 0 } paired with :focus-visible { outline: 3px solid blue }.

Games are being remastered with little thought to accessibility

• This article came out in June in response to a slew of remastered games being released around May. Many of these games from circa 2010 lacked accessibility features at the time, and haven’t been given any accessibility love in the remaster, lacking basic things like controls mapping. The author shows lots of screenshots and provides a quick overview of games including Mafia 2 and Minecraft Dungeons. Worth a read to remind ourselves how generally terrible in-game subtitles are.

How we recruited people with low/no digital skills on Carer’s Allowance

• A GOV.UK blog from 2015. They wanted to find people on the lowest end of the digital inclusion scale for user research, to ensure a service they were building could be used by anybody. Asking people “How would you rate your computer skills?” wasn’t a reliable indicator of digital literacy as people tend to underestimate their skills and subsequently complete tasks with ease. Making people score themselves against explicit criteria, e.g. “How comfortable are you finding stuff using a search engine such as Google”, was a much better way of finding participants on the lower end of the scale.

ARIA in CSS

• Jeremy Keith writes about a technique (prompted by Sara Soueidan) that ‘forces’ you to create accessible experiences. You can use ARIA attributes as CSS hooks to ensure your component only looks/functions properly if said attributes are used in the HTML.
• Consider this CSS: aria-hidden['true'] { display: none }. It ensures you’re properly hiding content from both sighted and screen-reader users; the aria-hidden hides from the screen readers, and the display: none hides from sighted users*.
• *Jeremy seems to imply that display: none doesn’t hide content from screen reader users, which would indeed make this approach really clever. But display: none does hide from screen readers, so I think there’s been a misunderstanding somewhere. However, I still think the ARIA-in-CSS approach is more semantic, and could be marginally beneficial…
• Imagine if your CSS fails to load for some reason. With ARIA-in-CSS, at least screen reader users will still ignore the content. If you’d used a class instead (.hide { display: none }), then a CSS load failure would be a broken experience for everybody.

Math, schizophrenia and the story of a life saved by the Internet

• A US podcast sent in by frequent11y subscriber Nick. It’s an anonymous interview with someone who has schizophrenia. Whilst studying to become a mathematician, they were faced with severe anxiety attending the face-to-face lectures, so asked if they could just do the assignments and skip the classroom parts. They were told “no”. After dropping out of school and reaching suicidal lows, they enrolled in an online-only degree, graduated, and now have a lucrative full-time job. They hope that the pandemic leads to academia becoming more remote-friendly and accommodating of mental health.
• (The relevant portion is about 31 minutes into the podcast, or you can switch to the Transcript tab and search for “coming up, math” to find the relevant portion.)

Developing Real-Time, Automatic Sign Language Detection for Video Conferencing

• Google intern Amit Moryossef writes about a research paper on real-time sign language detection using human pose estimation. The model, called PoseNet, reduces input from a HD image to a small set of landmarks on the user’s body, which can be analysed frame-to-frame to predict whether a user is signing, to an accuracy of 83-92% – you can try this for yourself in the demo or watch the video.
• As conferencing software tends to focus on someone who is speaking verbally, it is hoped sign detection could be used to move focus to someone communicating via sign language. The researchers found a clever way of triggering the focus: when the model determines that a user is signing, it passes an ultrasonic audio tone. The audio is transmitted at 20kHz, which is outside the hearing range for humans, but fools any video conferencing application into thinking the user is speaking. This research could be used to better include those who communicate via sign language.

That Time I Tried Browsing the Web Without CSS

• Jon Kantner describes his experience with some popular sites after turning off CSS. 12.5% of users with low vision (who use assistive technology) browse the web with custom stylesheets, so sites need to have good structural markup to build upon. The most common issues Jon encountered were: images/SVGs with no width/height attributes, so appeared massive on the screen; lack of whitespace between elements (sites rendering <a>Link 1</a><a>Link 2</a>, not marked up as a list); unlabelled buttons (which would also be a huge problem for voice input or screen reader users); and missing images (e.g. logos applied with CSS background-image).
• Did you like this article? I’ve written a number of similar posts on Smashing Magazine.

The Robot That Gives Humans a Job (video, 3 minutes)

• At the “Avatar Robot Cafe” in Tokyo, all of the servers are robots – but this isn’t the typical story of automation taking peoples’ jobs. These robots are controlled by people outside of the cafe who would never be able to physically do the job otherwise. Massa – the avatar that serves Alice Levine in the clip – has severe physical disabilities that confine him to his bed. But he can control the robot waiters using sophisticated eye tracking technology, and can talk to customers to take their orders and have a conversation. The arrival of 5G could soon mean he can send his robot to any location, indoor or out. It provides Massa “a huge amount of hope”.
• Watch the full episode of Kevin McCloud’s Rough Guide to the Future on Channel 4 (47 minutes).

Use feature flags to make your website more accessible

• Interesting idea from Heidi Waterhouse: allow users of your app to set their preferences for things like font size, contrast, and font family, and persist these preferences in a database [or cookie]. Then, when rendering the page for the returning user, retrieve their preferences and give them a personalised, accessible display. Heidi recommends building in these flags for every new feature, even if you haven’t built the part that lets users configure it yet (just return the default value). When you do come to implement it, your UI will already be set up to give the personalised view.

Sony Outlines PS5 And DualSense Accessibility Features

• Sony has released a blog post describes the PS5’s new accessibility features, such as built-in screen reader, and voice dictation software. Gamers will be able to adjust colour contrast on subtitles/closed captions, and reduce or disable haptic feedback in the DualSense controllers. Well done to the lucky few who have managed to pre-order one so far (I haven’t, and it baffles me why it’s so difficult)! PS5 is released on November 19th in the UK.

Accessible Routing in JavaScript Frameworks

• A Deque article by Mark Steadman, describing how to handle transitions between page loads in Single Page Applications. Ideally the focus would go to a <h1>, or failing that, it should go to the body of the page. In either case, the focussed element needs a tabindex="-1" so that JavaScript can assign focus. As a last resort, you could instead shift focus to the “skip to main content” link if you have one, but should also use aria-live to announce to the screen reader that the page has changed.

6 Ways Travel Has Become More Accessible During the Pandemic

1. Flexible booking & cancellation policies (to encourage people to book flights etc; those who have bouts of debilitating medical symptoms have long requested more flexibility).
2. More accessibility fixes on websites (due to suffering businesses trying to market to more customers).
3. A move toward contact-free (e.g. more automatic doors, less paperwork, less face-to-face check-in).
4. Public spaces easier to navigate (lack of crowds, increased spatial awareness).
5. Increased local offerings (some hotels & tour operators are extending discounts to residents, in the absence of out-of-town visitors).
6. Events with virtual access (business conferences, concerts etc, which prior to the pandemic would not have allowed participation from a distance)

What is ARIA even for? (video, ~8 mins)

• A quirky, almost NSFW video by Heydon Pickering, explaining when and why to add ARIA roles and attributes to your HTML. It is best used when there is no good native HTML solution to your problem. For example, a ‘toggle button’ could be achieved with checkboxes, but is difficult to style and would be announced as input to the screen reader: better to use <button aria-pressed="false">Toggle</button> and use JavaScript to change the aria-pressed value. And <button> already has an implicit role="button", so there is no need to add it here.

Atkinson Hyperlegible Font

• A font has been designed to be read more easily by people with low vision. It differentiates commonly misinterpreted letters and numbers, such as capital I and lower-case l, using exaggerated forms including angled spurs and differentiated tails. It comes in four variants (regular, bold, italics, italics bold), supports 27 languages, and is available for free on Windows, Mac and the web.

Accessible Fonts: Please, STOP Using PX For Screen!

• A very ranty article that nevertheless explains quite well the reasons for using em (rather than px) for your font sizes, media queries, margins and padding. It dispels the myth that the ‘default’ font size is always 16px (the author’s default is 20px). rem is argued against as theme changes have to be applied in more places. pt, mm, cm and other ‘real-world’ metrics have their place only in your print styles.

Soccer players’ head injury risk could be reduced with simple adjustments to the ball, study finds

• Football governing bodies FIFA/NCAA govern the size, weight limit and inflated pressure of footballs. Purdue University engineers have concluded that when footballs get wet, they quickly breach the weight limit, so should be swapped out mid-game. Inflating balls to the lowest allowable pressure can reduce its force by 20%. Adopting these measures could reduce concussion risk, which account for 22% of all soccer injuries. A professional player heads the ball 12 times in a single game and 800 times in a season.

GIFS and prefers-reduced-motion

• Some people find animations nausea-inducing or distracting. They might well configure their browser to indicate that they prefer reduced motion. This CSS Tricks article highlights a really neat trick from Manuel Matuzović: display a static image by default, or play an animated gif if users have no preference for reduced motion, using <picture> / <source> elements combined with a media query (see screenshot above). The article goes on to describe how you can use a <details> element to allow gifs to be ‘paused’ (see the demo).

This $1 hearing aid could treat millions with hearing loss

• Saad Bhamla, a bioengineer from India, wanted to buy his grandparents some hearing aids. He was shocked to find that they can cost $500 to $5000 per pair, so set out to build his own. He soldered a microphone to a circuit board, then added an amplifier, a frequency filter and a volume control, as well as on/off switch and audio jack. His makeshift product, LoCHAid, passes five out of six of the World Health Organization’s recommendations for hearing aids, and cost around $15 to build. This could be reduced to $1 if produced at scale. It needs clinically testing before it can be legally sold as a hearing aid in most countries.

---

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Here’s your frequent11y newsletter for the month of October, brought to you by @ChrisBAshton:

How do the new iOS 14 accessibility features stack up?

• Deque reviews the new a11y features in iOS 14. It supports widgets on the home screen, e.g. for at-a-glance weather reports, which makes it easier for everybody to find out pertinent information quickly. Back Tap (tapping 2-3 times on the back of the phone) can be mapped to do things such as take screenshots, and seems beneficial as another ‘shortcut’ alongside the existing triple-click-home button. VoiceControl can in theory be used with VoiceOver, but it’s hard to make a voice command when so much content is being read out on screen; Deque recommends delaying supporting the VoiceControl/VoiceOver combination in your applications until Apple has ironed out a few issues.

WAVE 3.1 Release

• Version 3.1 of the accessibility evaluation tools has been released, with improvements including: YouTube videos are identified as an Alert (prompts users to verify it has captions), better ARIA and title support, reduced false errors for contrast testing, and identifying structures that could be lists (but are not marked up as such).

As diabetes increases in sub-Saharan Africa, so will blindness

• A large number of people arriving at a health organisation in Tanzania have developed diabetic retinopathy – a complication of diabetes that can cause permanent blindness and is the leading cause of blindness in working age adults globally. Many patients are unaware they’re diabetic and are arriving too late for early stage treatment (lasers and injections) and so up to 20 patients per week are being referred for eye surgery at a private hospital, where surgery costs $2,500-$4,000. Many patients cannot afford this. A 143% increase in diabetes is expected in Africa by 2045. It is also on the rise globally, particularly in low and middle income countries. The article suggests that AI could be used to make screenings for diabetic retinopathy more affordable.

Gutenberg Accessibility Costs WordPress the W3C Work

This is a story that has taken up a lot of headlines, and many articles assume a fair bit of background knowledge, so I’ll be giving a longer TLDR than normal (though still largely based on Adrian Roselli‘s article above):

• The World Wide Web Consortium (WC3) are redesigning their rather clunky site, w3.org, with the help of digital agency Studio 24, whose progress you can monitor on w3c.studio24.net.
• In choosing a CMS for the new site, Studio 24 indirectly announced that it was no longer considering using WordPress. WPTavern – a site dedicated to WordPress – took issue with this, and Studio 24 clarified that the decision is due to accessibility issues in Gutenberg (WordPress’s block-based WYSIWYG interface).
• It’s now turned into a bit of a battle of Free and Open Source Software (FOSS) vs Accessibility, as Craft CMS – the platform Studio 24 eventually chose – is not open source.
• Adrian goes a little bit into the history of Gutenberg and its pained relationship with accessibility, but it boils down to accessibility not being a focus for the platform. In contrast, Craft has made a public commitment to WCAG.
• Adrian concludes that the W3C has made the right call (as do other people in my echo chamber) in prioritising accessibility over what kind of license something has.

Sound thinking: BBC helps audience to hear the details

• Article about how the BBC used ‘object-based media’ when recording Casualty (Series 34, Episode 36), which features a character with a hearing impairment. Object-based media samples sounds from different parts of the scene – the main dialogue, a heart rate monitor, background noise – and allows the viewer to adjust the levels (or stick to the default ‘broadcast mix’) so that they can hear the most important things clearly.
• The article claims viewers watching on “an internet-connected device” should see a “slider… which enables them to adjust the level of the audio to suit their own particular needs”. Regrettably, I could not see a slider on BBC iPlayer at time of writing.

a11yresources

• A curated list of a11y resources by Hannah Milan. Browse browser extensions, bookmarklets, checklists, colour picker tools, articles, and even other accessibility focused newsletters (I won’t be offended 😉).

Tech volunteers develop new online tool to help visually impaired access COVID-19 data

• The ‘Scottish Tech Army’ have created a dashboard of COVID-19 statistics in Scotland, which, in a ‘world first’ uses ‘sonification’ to interpret visual data as sound. This enables screen reader users to get an idea of the general trend of a chart, without having to keep track of every data point like they would in a table. I’m not a screen reader user myself, so don’t know how useful this is, but it is certainly an interesting experiment. To try, turn on your screen reader and navigate to the visually hidden “Listen to audio representation of daily cases for Scotland” button.

Work In Progress: Tabbing Order in the Accessibility Panel

• Firefox are adding a devtools feature which highlights all focusable elements and the order in which they will be tabbed. To view, download the Nightly version of Firefox, open the devtools, switch to the Accessibility panel, and check the “Show Tabbing Order” option. It’s not yet clear when or if it will make it into the mainstream browser.

VoiceOver on iOS 14 Supports Description Lists

• This isn’t the first time I’ve talked about iOS 14, but Adrian Roselli highlights a lesser known improvement the update brings: support for <dl> description lists. Now, in some contexts, terms and definitions are read sensibly, e.g. “louche, term. ‘not reputable or decent’, definition”. In other contexts, such as in VoiceOver’s ‘read-all’ mode, it still fails to parse properly, garbling the entire list as one sentence.

How studying fruit flies might help us prevent age-related hearing loss in humans

• Fruit flies are prone to age-related hearing loss – just like humans, whose molecular pathways of hearing are very similar – maintaining their sensitive hearing for about 85% of their 58 day lives. The article goes into more scientific detail than I’m able to summarise here, but the TLDR is that gene therapies have been applied to fruit flies such that older flies had hearing capabilities similar to younger flies. The same approach could in theory be applied to humans.

Virusdogs

• On BBC Radio 4 this morning, they were talking about how dogs can be trained to detect coronavirus in humans, and could be used for mass screenings at places like airports and train stations. Each dog takes around 8 weeks to train, and can process 250 people per hour. This initiative is still at the early feasibility study stage, and is asking for volunteers who have recently tested positive for coronavirus to apply for a training pack. The pack contains a mask and a T-shirt to wear for a few hours, and a prepaid envelope to return the worn contents to ARCTEC for training. A successful program could re-enable global travel.

Here are a couple of interesting articles focused on accessibility law suits in the USA, but well worth a read wherever you live: Expert witnesses in web accessibility cases (Part 1) and Expert witnesses in web accessibility cases (Part 2).

• In Part 1, Ken Nakata describes the Daubert standard of expert witness testimony, which requires that a scientific methodology is followed (peer-review, standards followed, widespread acceptance within the community, etc). Testimonies fail because they’re too high level, describing a general audit, which is “not a sufficient replacement for a proper explanation of overall methodology and process” [pertaining to this specific case].
• In part 2, Ken gets more specific. Many testimonies fail because they’re too broad, describing all the WCAG issues encountered, as that’s what accessibility specialists are used to doing in their reports. They should instead concentrate solely on issues that caused the plaintiff to “suffer injury”, where the “injury can be traced to the defendant’s illegal conduct”. So a blind person can sue a site where they were unable to purchase a product (the injury) if the site has not been built to be accessible to a screen reader (the illegal conduct). On the other hand, a blind person couldn’t sue a site for having a video missing captions because lack of captioning alone should not injure the blind plaintiff; a deaf plaintiff would have more grounds.

Accessible HTML toggle buttons

• Erik Kroes describes his accessible toggle switch, which makes use of a <button> with role="switch" and aria-checked="true" attributes. He chose <button> because “I want something to change instantly which a checkbox really should not be doing. In my experience, checkboxes that change things often clash with WCAG Criterion 3.2.1: On Focus. A aligns better with the goal of instant change”. It’s always interesting to see how different devs approach this problem.

webhint.io

• Webhint is an OpenJS Foundation project backed by Microsoft, that lints your website for accessibility, speed and cross-browser compatibility. It can be installed as a CLI tool, a browser extension, or run directly from the webhint scanner page. I tried it on one of my sites and though it didn’t find any accessibility issues, it found a lot of redundant meta tags which I should consider removing. A talk by Rachel Weil includes a live demonstration of the usage.

Renting while disabled: ‘Being in a wheelchair means I pay double the rent’

• 93% of the UK’s 8.5 million rental properties are inaccessible. It’s up to local authorities to set and enforce accessibility targets, but just 5% are requiring developers to construct wheelchair-suitable housing.
• Finding an accessible home is difficult as property websites lack accessibility filters, and estate agents are often useless. Habinteg Housing Association are hoping to launch an ‘online accessible property directory’, but it’s unclear from the article what scope it will have. There’s certainly a business opportunity here for someone to build the Rightmove of accessible housing.
• The Equality Act 2010 gives wheelchair users the right to make adaptations to their rented homes, but changes must be ‘reasonable’ (giving room to landlords to say no) and they must intend to live in the property for at least 5 years, making this unviable for many young renters.
• These adaptations cost on average £9,000, with a means-tested Disabled Facilities Grant covering only some of that cost. Life costs £583 per month more on average if you are disabled.

Alternative Text for CSS Generated Content

• An Adrian Roselli post about the new “CSS generated content alternative text” syntax, which allows you to specify alt text for CSS background images. For example: .new::before { content: url("./star.png") / "New!"; }. Browser support is very patchy and this should not be relied on yet, but it is a promising step as currently background images are not accessible to screen readers nor to sighted users using Windows High Contrast mode. It’s worth noting that the alt text won’t display if the image fails to load, so it’s still generally best to use a normal <img>.

The new normal — its something of a strain

• David Banes writes some tips on looking after your eyes now that many of us work from home and don’t have an office-like environment to work in. Some are obvious but need stating: take eye breaks, limit screen time where possible, remember to blink, etc. Try to reduce glare on your screen by turning lights behind you off, but aim for a softly lit environment. Try to keep your screen at arm’s length from you, with the top of the screen roughly at eye level. Finally, consider installing f.lux (for desktop and mobile) – software that adds a tint to your screen, getting gradually darker as the evening draws in, reducing blue light. It helps reduce eye strain and can also have a positive impact on your sleep.

The most useful accessibility testing tools and techniques

• Artem Sapegin describes how he tests a11y as a frontend developer. FastPass mode in the Accessibility Insights browser extension highlights the two most common issues to fix. He also uses axe. For contrast checking, he uses Chrome DevTools’ built-in contrast checker and Spectrum. He manually tests navigating the site with a keyboard (focus states etc), using a screen reader, and attempting to zoom in 200%. Finally, he checks the site in ‘browser reading mode’ and in dark mode.

Cursor Pro Mouse Highlighter

• This popped up in my inbox and it looks like a useful tool for people with mild/moderate visual impairments. Through a global toggle in your Mac’s native menu bar, it can be turned on to provide a highlight ‘orb’ around your cursor so that it is easier to keep track of, and a built-in magnifier such that if you hold a particular key while hovered over something, you zoom in slightly. It’s a paid app ($7.99), so a free alternative would be to go to Settings -> Accessibility -> Display -> Cursor and increase the ‘Cursor Size’, though this doesn’t have the highlight orb or zoom functionality.

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

How to Create Accessible Cooking Videos

• Article describing what to do as a content creator to make your videos accessible. It pertains to cooking, but could equally be applied to most videos. 1: provide captions, either via sidecar caption file or embedding directly into video. 2: describe visual elements via a separate audio description track, which is difficult because many players don’t natively support it. For cooking videos, describing while you go should be sufficient. Here’s a good example.

These volunteers are making Black Lives Matter videos accessible to deaf activists

• A group of volunteers on Twitter noticed that many Black Lives Matter videos were missing captions, so they set up @ProtestAccess. Users can tag this account to ask for transcriptions of a video, which over 250 people are on hand to transcribe. Since starting in June, they’ve posted over 500 captioned videos, whilst encouraging the original uploaders (especially large organisations) to provide captions from now on.

44×44 Pixel Cursor Bookmarklet

• This tool by Jared Smith is well worth bookmarking. Click it to turn your cursor into a 44×44 pixel square, to make it easier to test your site against WCAG’s Target Size and Pointer Target Spacing rules.

How Animal Crossing: New Horizons Players Use The Game’s Customization To Make It More Accessible

• Blind athlete Ross Minor navigates the Animal Crossing world by hearing; the sound of your character’s footsteps stops if you walk into an obstacle, and you can use noisy waterfalls and tiki torches to signpost areas of your village. Shannon Natale set up a sign for her aunt, asking players to come close to her aunt’s character before attempting to chat, so that messages are centered in the most visible part of the screen. Some features are still inaccessible, such as insects making no noise: there is a petition to get these fixed.

Autonomous vehicles should benefit those with disabilities, but progress remains slow

• An MIT report estimates that autonomous vehicles might not hit the streets for another decade. The benefits when they arrive, however, will be massive for the disabled community. In the USA alone, it would enable employment for 2 million people with disabilities, while saving $19 billion annually in missed medical appointments. It could also have resulted in 3 million more people voting in the 2012 US election. Anthropologist Megan Strickfaden is advocating for a standard, universally designed autonomous vehicle with side entry ramp so that everybody can access it regardless of ability.
• “This is a unique opportunity in history to vastly improve the lives of millions of people with disabilities. All of us will grow old, if we are fortunate to live long lives, and many of us will need, either permanently or temporarily, the assistance that [autonomous vehicles] afford” ~ Sheryl Gross-Glaser, director of the nonprofit Community Transportation Association of America.

Operating System and Browser Accessibility Display Modes

• Eric Bailey summarises several global settings users might use to change their display, the reason for their existence and the effect they can have on your website. The modes are Dark, Increased Contrast, Inverted Colors, Reduced Motion, and High Contrast. He also describes how to target them in code, so that you can better tailor your site to your users. A very useful resource.

When there is no content between headings

• This is a question that often comes up: are you allowed to have a heading immediately followed by another heading, with no content in between? Hidde de Vries gives us a useful rule: “Always have content between headings of the same level.” I.e. a <h2> immediately followed by a <h3> is fine, but a <h2> followed by a <h2> is not.

upyoura11y.com

• Suzanne Aitchison created this site to help share the a11y knowledge she has curated over the years as a software developer. It covers fundamentals, but also there’s a specific section covering a11y in Single Page Applications, which can otherwise be quite hard to find resources for. Well worth a look.

Decoding Label and Name for Accessibility

• Consider the following HTML: <label>Name: <input aria-label="First name" placeholder="e.g. Chris" title="Enter a name"></label>. What gets read out by screen readers?
• Answer: the aria-label always takes priority. In its absence, it would be the label, and in the absence of that, the title, or if nothing else, the placeholder. These rules are defined in the HTML Accessibility API Mappings’ Accessible Name and Description Computation. Browsers have built-in tools to allow you to inspect an element’s accessibility properties.

6 webinars from GDS to improve accessibility within your organisation

• A curated list of videos from the Global Accessibility Awareness Day (21 May 2020): Introduction to the Public Sector Bodies accessibility regulations (34m), How to make your PDFs accessible (17m), How to engage your workforce on accessibility (16m), How to avoid common accessibility statement fails (42m), How to carry out basic web accessibility checks (58m), How to build digital services that work for everyone (30m).

Typing With One Hand on Your iPhone Just Got a Little Easier

• As iPhones get bigger, it can be harder to reach certain keys on your keyboard when using just one hand. Apple have built a “One-Handed Keyboard” mode, which squashes the keys together and makes it easier to reach any given key with your thumb. To enable: when using the keyboard in any app, press and hold the globe icon in the bottom left corner and choose “Keyboard settings”, then switch to right-handed or left-handed keyboard.

What to look for in an accessibility audit

• A blog post by Glenda Sims, describing Deque’s different audit offerings. Clients need to choose the browsers and assistive technologies included in the audit, though this needs to be balanced against the cost of testing. Pragmatically, Glenda claims that using Chrome with NVDA will catch >90% of accessibility issues. Clients also need to choose which pages to test, which should include the site’s entry points, core paths and highest traffic pages. Lastly, they must choose what standard to test against: usually WCAG 2.1 Level A (lowest level of conformance) or AA.

Five Things I Use My Phone For On A Daily Basis

• Luke Sam Sowden, who is “Severely Partially Sighted”, describes how he uses the accessibility features of his iPhone XR, and apps. He uses Microsoft Seeing AI, Tap Tap See and Digit-Eyes to use his phone’s camera to recognise objects, people and text in his surroundings. Google Maps gives good directions. The built-in Camera App is VoiceOver-compatible and tells him where his face is on the screen if he’s trying to take a selfie. Finally, he finds Twitter and Instagram quite accessible – the latter is improving with “Photo descriptions” and Instagram Stories.

AudioEye Sues AccessiBe for Patent Infringement

• AudioEye is suing accessiBe for allegedly using tech that AudioEye has a U.S. patent on (patent no. 10,762,280). Both companies are involved with accessibility. accessiBe announced 12 million dollars of funding in May 2020. The article laments the fact that one a11y-focussed company is suing another, and wishes the money was spent improving the lives of disabled people instead. You can read the legal filing by AudioEye, but I’m inclined to agree that it’s a waste.

GDS updates its Government Service Standard requirements for assistive technology (AT) testing

• Other than updating version numbers of AT and browser combinations, the main changes are: adding TalkBack (Android screen reader); reducing magnification level to test in from 10x to 4x; swapping ZoomText with Windows Magnifier or Apple Zoom; and specifying VoiceOver should be tested in iOS (testing in macOS is in a new ‘optional’ list for further testing).
• There’s also a helpful note about it being good to test with any screen reader, speech recognition tool or screen magnifier in your development environment, but that you should test against the full list prior to launch.

alt attributes like paragraphs

• Developer and accessibility expert Dave Rupert came to a realisation recently: “alt text is like a paragraph”. To clarify, Dave isn’t talking about the length of the alt text here, but the order in which it appears, and its contextual relevance. A lot of designs have images appearing before headings, but screen reader users who navigate by headings would miss the image (and alt) entirely. If the image is important (e.g. “Sale” or “New”), it should probably be moved below the heading in the source order, but then perhaps rendered above the heading using something like the CSS order property.

Duet Date Picker

• This is a WCAG 2.1 compliant date picker, from the Duet Design System, that also allows you set a minimum and maximum allowed date. It can be used standalone or incorporated into any JavaScript framework, and weighs 10kb minified and Gzip’ed. It supports modern browsers and screen readers, and has limited support for IE11.

10 Things to Know About Twitter’s Alternative Text for Images

• Article by Deborah Edwards-Oñoro, summarising a few things you may not know about alt text for images in tweets. Alt text is now enabled by default on the web and apps (no need to turn on image descriptions in settings). Alt text cannot be added to already published tweets. It can be added to animated GIFs. You can use up to 1000 characters for alt text. If you leave it blank, Twitter will add “Image” as the alt text.

Are clear masks the way to clearer communication? The deaf community isn’t so sure.

• Yahoo! article by Abby Haglage, explaining that clear face masks may not be the panacea we think it is for the deaf community. The masks can fog up, reducing visibility – and even if that is put aside, lip reading is only about 30% effective. Many advocates are encouraging people to learn some BSL (British Sign Language) instead. However, Abby acknowledges that clear masks are a step in the right direction.

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

How Alexa has change the life of a disabled person

• Colin Hughes describes how his muscular dystrophy can make it difficult to use remote controls. He now uses Alexa to control thermostats, lights and blinds with his voice. Taking inspiration from a video showing how a garage door can be opened/closed with a cheap wireless switch, Colin retrofitted his front door to be voice-powered for £150. This contrasts with a £5000 quote he received from a company, highlighting the financial burden people with disabilities are put under. His command of ‘open sesame’ has to be regularly changed in case passers by figure out how they can enter his home.

Accessibility Best Practices for Classes Using Zoom

• PDF from The University of Texas. Tips include: don’t require people to turn on their webcams (anxiety, physical tics etc); read screen shared contents and any chat content aloud; use Show/Hide Non-video participants to hide names and profile pictures if recording; do not force mute participant audio (required for deaf students to pin the sign language interpreters); post materials before or after class for students to review.

Accessible Font Sizing, Explained

• The WCAG does not define a minimum font size for the web: just that fonts should be resizable and of a sufficient contrast. Contrast should be 4.5:1 for small text, 3:1 for larger text (defined as text that is a minimum of 18 point or 14 point with bold), though different screen densities and alphabets mean the pixel size will vary. Browser font sizes are accessible by default, so avoid using px and instead make your font sizes relative to the base font size (usually 16px) using rem/em. About 3% of users change their default font size in the browser settings, and some will override the font-family too (e.g. to OpenDyslexic, which increases readability for users with dyslexia).

Control your iPhone with your voice (and leave Siri out of it)

• iOS 13 brings ‘Voice Control’, which allows you to use commands like ‘swipe left’ or ‘scroll up’, open apps or take pictures. You can also dictate text messages or notes, and delete text you’ve typed without having to touch your phone. It’s also highly customisable: you can set up shortcuts for inserting your email rather than saying it out loud, or have Voice Control perform custom gestures, e.g. touch-and-hold. This article explains how to set that all up.

Disabled Nurses Find Covid-19 Silver Lining; Hope For More Inclusive Future

• A Forbes article about three nurses with disabilities, and the opportunities the current pandemic has afforded them. Andrea Dalzell interviewed for 76 hospital jobs and was rejected from them all once they realised she was in a wheelchair. The desperate plea for nurses since March has now meant employers look past her disability, and she’s found a job. All three nurses in the article strongly state that they work as effectively as other nurses.
• On a semi-related note, #DisabledAndCute is trending on Twitter. I came across this image in a New York Times article, showcasing an ‘accessible party dress’ on manikin positioned in a wheelchair, amongst other manikins. It’s not something you usually see and I liked that the visibility of wheelchairs in social/fun settings is being normalised.

Making Facebook.com accessible to as many people as possible

• A Facebook Engineering article describing how the site redesign in React provided opportunities to improve accessibility. Using React Context, heading levels automatically increase as they are nested (i.e. <Heading /><section><Heading /></section> automatically creates a h1 followed by a h2). They use the same mechanism for contextual keyboard commands, to perform actions relevant to the thing that is in focus. Components such as FocusList are wrapped around lists to handle focus and to define up/down arrow key behaviour. A static analysis tool errors when it encounters a form control without a label, and a runtime tool monitors the DOM in real time and visually alerts devs to any inaccessible components.

YouTube Axes Community Captions Feature, Citing Low Usage

• A feature allowing viewers to contribute subtitles to a channel’s videos will be discontinued on 28th September 2020. YouTube says less than one-thousandth of a percent of channels approved a community captions track in the last month, and only 0.2% of watch time had a community caption track selected. Subtitles ranged in quality, and it is known that some contributors were exploiting the tool to spam or troll its users. Content providers can still provide captions on their own videos, and YouTube is improving its automated captions service.

Going Colorblind: An Experiment in Empathy and Accessibility

• Sara Novak writes about her three-day experiment using Chrome extension See, to emulate deuteranomaly and better understand the needs of one of her colleagues. This is the most common type of colour blindness, making it difficult to differentiate green and red. She realised that the way she’d been highlighting her emails in different colours was not accessible, and switched to using italics or bold for differentiation. A site Sara used wouldn’t let her fill out a form because it used red and green borders to indicate whether the fields passed validation, which she couldn’t distinguish between.

Diamond: Strides Made in Website Accessibility This Year, But More Work Needed

• A report from May, which I’ve only now found time to read: accessibility for the Alexa Top 100 websites has improved from 2019 to 2020. 40% are ‘fully accessible on all platforms tested’, vs 29% last year. And 39% of sites are ‘fully inaccessible’, down from 43%. 21% were accessible ‘with difficulty’, down from 28%. An example of ‘accessible with difficulty’ includes triggering a login button but then needing to search for form elements because focus was not given to the modal.

Equal Entry Website Called Out as Inaccessible

• A bit of a clickbaity headline, describing how Equal Entry responded to a complaint that one of their web pages had 2 accessibility errors, which was the result of an automated tool and turned out to be all false positives. For example, one of the errors was that an input was missing a label, but it was a textarea used for visual spacing only. It had aria-hidden="true", so it didn’t need a label. The post has a useful overview of how the consultancy conducts an accessibility test, with a reminder that aiming for a 100% pass rate can be a false prophet.

Why Deaf People Oppose Using Gene Editing to “Cure” Deafness

• Article suggesting that people who are deaf view themselves through the social model, rather than medical model, where societal barriers are the source of disability. It argues that an inaccessible society causes more harm than being deaf itself, and that there can be biological advantages to being deaf. ‘Deaf gain’, as it is known, includes being better able to accurately recognise faces, having faster peripheral vision reaction times, and perhaps some protection against Alzheimer’s. A gene that causes hereditary deafness may actually offer improved wound healing.

What’s New in WCAG 2.2

• Another excellent Adrian Roselli round-up, detailing the latest WCAG v2 proposal (deadline for comments by 18th September). There are 4 new Level A success criteria: 2.4.13 Fixed Reference Points, 3.2.6 Findable Help, 3.3.7 Accessible Authentication, 3.3.8 Redundant Entry, and existing criterion 2.4.7 Focus Visible has been ‘promoted’ from level AA to A. There are also 4 new Level AA criteria and one new Level AAA.

New TfL app to help Londoners travel safely round capital

• The TfL Go app for iPhone (with an Android version landing this autumn) shows real-time train times for the London Underground, with information aimed to enable travel at quieter times to help customers maintain social distancing. It includes ‘step-free mode’ which shows all the stations with street-to-platform wheelchair access. It also has dynamic text sizes and is VoiceOver-compatible – read more on tfl.gov.uk.

Amazon Expands Accessibility Features With New Text Banner for Fire TV

• Amazon has launched ‘Text Banner’, aimed at assisting users who struggle to read the onscreen text. This text banner appears in a fixed location on the screen and works across the Fire TV UI, but also Prime Video and other applications on your Amazon device. It can be enabled within Settings under Accessibility.

a11y is web accessibility

• Eric Bailey provides a comprehensive summary of why the term ‘a11y’ is useful, to address the common ironic adage “the term ‘a11y’ is itself inaccessible”. It is easier to type and to say, it allows more room for content inside tweets, and, crucially, it is more specific than ‘accessibility’ as it pertains to digital accessibility rather than something physical like wheelchair ramps for libraries. It is no different than using terms like i18n, 3D or WWII, and to suggest it is a problem is arguably a sign of ableism.

Is Twitter Trolling Us? Why Voice Tweets Are Already Problematic

• A few weeks ago, Twitter introduced a new feature to a limited group of test users: the ability to tweet audio memos instead of text. It quickly received a backlash from the deaf community, who complained that these tweets have no caption support. The feature has also been called out as potentially harmful, especially to users already suffering harassment on the platform. Twitter was quick to apologise and has since been recruiting more accessibility specialists.

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.