Category: week11y

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

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 weekly frequent11y newsletter, brought to you by @ChrisBAshton:

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

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 weekly frequent11y newsletter, brought to you by @ChrisBAshton:

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

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 weekly frequent11y newsletter, brought to you by @ChrisBAshton:

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.

And now back to our regularly scheduled newsletter-ing:

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.

Hello! Welcome to your weekly frequent11y newsletter, brought to you by @ChrisBAshton (who has just returned from a week off work!):

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.

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 weekly frequent11y newsletter, brought to you by @ChrisBAshton:

Hello! This week I 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 weekly 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.

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 weekly frequent11y newsletter, brought to you by @ChrisBAshton:

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.