Category: fortnight11y

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

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

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

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

Introducing Editoria11y: Accessibility Autocorrect

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

Modern CSS Upgrades To Improve Accessibility

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

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

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

EyeMine V2 is here!

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

An opinionated guide to accessibility testing

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

WebAIM Million – 2021 Update

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

Accessibility devices at CES 2021 reflect growing focus on inclusive tech

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

iOS 14 review: access all areas?

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

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

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

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

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

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

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

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

In Praise of the Unambiguous Click Menu

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

Wearable tech helps this blind runner compete in ultramarathons

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

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

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

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

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

Next up is a two-article WCAG special:

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

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

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

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

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

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.

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

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

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.

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

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

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!

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

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

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.

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.

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

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

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.

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

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

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

---

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