Category: fortnight11y

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

Myths about Web Accessibility

• This got shared around the work chat recently. A blog post by Álvaro Montoro that busts 10 myths about accessibility:
  • Accessibility is difficult – “Accessibility is not difficult. Do you know what’s difficult? Running at an Olympic level. A Web Developer can learn at least the basics of Web Accessibility within hours”.
  • Accessibility is expensive – “Something that they could have avoided if they had implemented accessibility at the start”.
  • Accessible websites are ugly – “Nothing could be further from the truth”.
  • Accessibility is for blind people/screen readers – “The people who require Web Accessibility are not a homogeneous group”.
  • Accessibility is for people with disabilities – “There are invisible and situation disabilities that impair people and limit what they can do temporarily (or even permanently)”.
  • Automatic tests are enough for accessibility – “automatic tests only detect ~30% of the issues.”.
  • Accessibility overlays are enough to ensure Web Accessibility – “The consensus in the Accessibility community is almost unanimous: overlays don’t work”.
  • HTML is accessible by default – “elements like <video> or <audio> have controls that are not fully keyboard-accessible and that differ considerably from browser to browser and cause frustration. ‘Mostly accessible’ looks much better.”
  • No ARIA > Bad ARIA – the equation should be “Good ARIA > No ARIA > Bad ARIA”. Otherwise we “perpetuate a false dichotomy. We can learn ARIA, practice ARIA, improve ARIA”.
  • Prefers reduced motion means no motion – “We don’t need to cancel every motion on a website. Instead, we need to think through them, check what’s appropriate and not”.

Have Single-Page Apps Ruined the Web? (video, 19m)

• Talk by Rich Harris, creator of Rollup and Svelte, for Jamstack Conf.
• He explains what a Single Page App (SPA) is, then starts off critical. “SPAs are terrible because”:
  • Bloated JS framework, complex tooling, poor performance.
  • It will be buggy. Expectations of the web are broken, e.g. CMD + Click should open links in new tabs, but often won’t work in SPAs.
  • Accessibility issues: focus management, scroll management, navigation announcements, etc.
  • Less resilience. Rich shares a webpage he often points people to when they assume that everyone has JavaScript. It is a long flowchart of all of the reasons why JS may not load for someone. Rich also points out that these users are underrepresented in analytics, because analytics typically require JS to run.
• But then he highlights the benefits:
  • SPAs allow you to do things you can’t do ‘natively’, e.g. transitions between pages.
  • Only need to load third party scripts once, whereas multi-page apps (i.e. the traditional server-rendered sites) have to at least evaluate the JS on each page load, even if the scripts themselves are already cached.
  • Single codebase of JS (rather than 1 for client, and 1 for server, which may be, for example, PHP).
• Rich proposes a new direction for the web, and coins the term “transitional apps” (from “transitional design” in the interior design industry), which are apps that take the best of both worlds. There is a lot happening in this space, including:
  • Hotwire
  • React Server Components
  • Marko partial hydration
  • qwik aggressive lazy loading
  • astro islands architecture
  • …and SvelteKit, which Rich gives an impressive demo on.

Stark, a hub for accessible software design, launches a Mac app in beta

• Stark is a suite of tools for the world’s most popular design apps. “Companies can upload their design files, which then identifies accessibility issues and suggests changes.”
• It “offers checks and suggestions to make sure that visual materials meet accessibility standards for visually impaired people”. More than 500,000 people have used Stark’s integrated plug-ins for apps like Adobe XD, Figma, Sketch and Google Chrome.
• Stark have now released Stark for Mac, a standalone app that works with Sketch and will soon work with Figma and Adobe XD. It allows you to detect accessibility issues at scale, rather than on a per-file basis as is the case with the plugins.
• Stark has a limited free plan, after which it costs $60 per year for the current suite of tools. The private beta version of Stark for Mac is currently free, with pricing yet to be announced.

Easy read is hard to get right

• This is a GOV.UK blog from the Inclusive Design team at UK Health Security Agency.
• It is about the “easy read” format – something I’d never actually come across before.
• The format, intended for people with learning difficulties, has a very specific template and definition:
  • wide margins
  • images on the left (to help convey meaning to the text on the right)
  • large text (14 to 16pt)
  • bigger spaces between lines (1.5 spacing)
  • 1 idea per image
• The nature of these requirements mean that ‘easy read’ content is often published as a PDF. This comes with its own accessibility issues, described in the article.
• The intended audience often has a ‘support person’ that they share this kind of content with, so it is important that they are easily able to print off the information and keep it together.
• Some users preferred text-only versions of the content, as they found the use and choice of images patronising.

Xbox reveals a huge new accessibility feature that puts Sony and Nintendo to shame

• A clickbait headline, no doubt, but an interesting announcement: Xbox are introducing a classification system to their stores (Xbox.com, PC, Game Pass), ‘tagging’ games with information related to their accessibility. This is to make it easier for disabled gamers to know whether a game supports their needs.
• “Testing of the feature is currently underway in the public Xbox Accessibility Insider League (XAIL) branch on all modern Xbox consoles. XAIL is free for all Xbox owners to join and is a group specifically designed for testing accessibility features in games and the Xbox operating system. It currently has around 60,000 enrolled members.”
• Microsoft has made this system quite strict. For example, for a game to be tagged as having accessible “subtitle options”, the game needs to do more than just ‘have subtitles’, as it must allow the subtitles to be customised and resizable to a minimum of 200% of their original size.

Accessibility overlays are a hot topic in the a11y world, so it’s worth keeping on top of all legal proceedings in this space. In her blog post below, accessibility consultant Julie Moynat writes a cautionary tale of how an accessibility overlay company have started legal proceedings against her, off the back of a single tweet.

Help for my lawyer’s fees in the FACIL’iti lawsuit against me

• In November 2020, the French Secretary of State to Digital Transition and Electronic Communications tweeted positively about the use of FACIL’iti to make sites accessible. (You can see the accessibility overlay in action on https://www.facil-iti.com/).
• Julie responded to the tweet, “expressing disapproval”. Her response ended up getting 9 retweets and 32 likes.
• At the end of December 2020, FACIL’iti sent a formal notice to Julie’s employer, demanding that the tweet be deleted. NB, Julie had tweeted from her personal account, outside of working hours.
• Julie deleted the tweet within two days of being informed of the letter, on 28th December.
• On 21st May 2021, a subpoena letter was served to Julie’s home address, intending to press charges to the tune of €10,500.
• Julie reached out for help via the blog post above, asking the community to donate to cover her legal fees. She raised almost €6,000, which has fulfilled her target.
• She updated her blog post on 12th October: the proceedings are still ongoing, and no trial date has yet been set.

Blaming Screen Readers 🚩×5

• There is, apparently, a trend going around on Twitter (example tweet): to state something that raises red flags for you, followed by a number of ‘red flag emojis’, i.e. “🚩”.
• Except that this isn’t a red flag emoji, other than by coincidence. It could just as easily have been yellow or green. What screen readers actually announce when they reach that emoji is “triangular flag on post”. So the meaning is lost on screen reader users.
• The great Adrian Roselli gives a detailed write-up of the problem – and plenty of places where it’s cropped up in the past – in this blog post. He’s heard a number of responses from people along the lines of “the screen reader is the problem”; Adrian argues otherwise, stating that screen readers don’t use natural language processing and do not ‘see what you see’. Nor can screen readers be updated overnight, to suddenly understand these short-lived trends and memes.
• The onus is on us to write our content in an accessible way. The blog post summary is frustratingly vague on answers: “Techniques to make your content accessible abound. They are no more than a quick search away should you care to try”, which doesn’t explain what you should do if you want to participate in a trend but the trend is inherently inaccessible. My personal recommendation would be to write an ‘alt text’ “reply” to your tweet, to clarify the original tweet for screen reader users.

And finally… a spooky-themed game for you, just in time for Halloween!

HOCUS :FOCUS – A keyboard accessibility horror game.

• A game that highlights issues caused by missing focus styles, unexpected tab orders, and so on.
• I completed the game in 1 minute and 16 seconds. Can you beat my time?

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:

Surface Adaptive Kit makes Microsoft’s laptops more accessible

• Microsoft is creating a “Surface Adaptive Kit” for its range of laptops/tablets, to better accommodate people with disabilities.
• The kit includes “keycap labels, bump labels, port indicators and device openers”.
• For example, a device opener includes a pull tab and ring, to make it easier to open the laptop lid.
• There’s no pricing information yet, but it is expected to launch this year.

Tips for Making HTML Lists Accessible

• This article is a quick reminder on HTML list markup.
• First of all, decide whether you actually need a list; sometimes it is better to format your content as paragraphs with headings instead. This way, assistive technology users can easily skip to the heading that they want to read.
• If you do use a list, decide whether it should be unordered (<ul>), ordered (<ol>) or a description list (<dl>). The latter is useful for glossaries or recipes, e.g. <dl><dt>Chicken</dt><dd>A small bird that lays eggs</dd>...</dl>.

10 Video Games That Have Great Accessibility Options

There are some really interesting accessibility options in the games in this article:

• Uncharted and The Last Of Us Part II are famously accessible, and are called out here.
• A Blind Legend is a game that “can be played entirely through sound and only asks for touch screen or mouse input”. It does not incorporate visuals.
• Grounded has the player shrunk to the size of an insect and having to find their way home across their back yard. The developers have considered arachnophobia – the intense fear of spiders – and thus offer an Arachnophobia Safe Mode Slider, allowing players to edit in-game spiders to have no legs, no eyes, or even no textures or sounds at all, without sacrificing the enemies’ difficulty.
• Hyperdot is a game “where the player avoids incoming attacks by darting around the screen”. The game can be played on any controller, including eye trackers.

Does WAI-ARIA even work with WebXR?

As someone who has recently bought an Oculus Quest 2, this is really exciting technology that has come a long way in a very short time. It’s crucial that we address accessibility needs as this technology matures.

• Thomas Logan writes about his experiment with ARIA and Web XR (“Web Extended Reality”, or VR).
• He uses aframe-gui, a GUI component framework for A-Frame, which is a web framework for making 3D experiences. Here is Thomas’s demo.
• Using ARIA to add the necessary role and aria-label to elements, as well as tabindex and onfocus handlers, Thomas has made an XR experience that is navigable via keyboard and by some assistive technology (AT) such as voice assisted navigation and screen readers. The full list of tested AT is in the article, which describes the usability issues encountered. For example, “Voice Control” on iOS/Safari does not detect the link or button in the demo.

This Brazilian pianist uses ‘bionic gloves’ to play

• Pianist João Carlos Martins lost the use of his right hand in a mugging in Bulgaria in 1995.
• Industrial designer Ubiratan Bizarro invented the “Bionic Extender Gloves”, which have rods that make the fingers spring back up after they depress the piano keys, allowing the pianist to continue playing.
• The first pair of these gloves for Martins cost less than $100 to make, and are made by a 3D printer.
• It has meant that Martins has been able to play his favorite Bach sonatas once more.

Twitter thread about “presentational list heuristics” by James Craig. The whole thing is worth a read, but here are the highlights:

• There used to be a problem with too many lists for assistive tech users: “all I hear when reading news sites is ‘list, two items … end of list, list 4 items…’ and I don’t care about all the lists.”
• This was caused by developers marking too much content up as lists, even when not appropriate.
• Therefore, WebKit now applies some heuristics to these lists, to decide whether or not to expose the list semantics to the accessibility tree.
• It considers whether the list has any bullet points. After all, if a sighted user doesn’t need to know it’s a list, then why should a screen reader user?
• Similar principles are applied to table markup, which was regularly used for layouts in the early web.
• “Many people think it’s only display: none; and visibility: hidden; but dozens, if not hundreds, of style characteristics contribute [to computing the accessibility tree].”
• False positives are extremely rare. That said, developers can force the list semantics to be obeyed by applying role="list" to the <ul>/<ol>.

5 False Claims 1-Line “AI” Accessibility Script Vendors Make (video, 13m, or read the transcript)

• Eric Eggert disputes five claims that companies [such as accessiBe] make about their products:
  1. “Accessibility can be fully automated”. Human judgement is required to determine what kind of alt text is appropriate in a given context.
  2. “AI solutions are effortless”. For you maybe, but the effort is simply shifted to the user, i.e. they now have to use the screen reader widget on your site rather than the native screen reader they’re used to.
  3. “These tools protect you from lawsuits”. Eric says that this is a scare tactic, and a poor motivator for implementing accessibility. Only 11,000 ADA Title III lawsuits happened in 2019, despite 98% of all websites not meeting WCAG 2.1, so the chance of being sued is statistically low.
  4. “It’s cheap”. These services cost $1,500 to $5,000 over a three year period of coverage. If you don’t renew, you lose those ‘benefits’, whereas if you pay an accessibility consultant to fix the problem at the source, the fix is permanent.
  5. “WCAG conformance. AA! 100%!”. Eric cites numerous examples of websites using these widgets, and still having accessibility violations. He summarises “I cannot fathom how they claim WCAG 2.1 AA accessibility.”

Colorblind Accessibility Manifesto

• colorblindaccessibilitymanifesto.com lists 10 rules developers/designers should follow to not exclude the 350 million colourblind people in the world; nearly 8% of men and 0.4% of women.
  • Start with “Why?” [you are making the change in the first place]
  • Don’t communicate only with colors
  • Design with shapes
  • Choose the right copy
  • Test your designs in black and white
  • Rethink button states
  • Use contrast
  • The smaller the item, the bigger the problems
  • Less fancy, more usable
  • More than you think [have colourblindness]

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:

Don’t Believe the Type! (video, 50m)

• I discovered this axe-con 2021 video via Richard Morton’s tweet. I thought it would be good to follow-up on the piece I wrote about the Hyperlegible font.
• The presentation, by Gareth Ford Williams, David Bailey and Bruno Maag, talks through the data they’ve gathered from around 7,000 hours of user research. They conclude that some so-called ‘accessible’ fonts such as “Open Dyslexic” actually perform worse than standard fonts like Helvetica. However, some accessible fonts perform better, including Atkinson Hyperlegible and BBC Reith Sans.
• That said, the poor performing fonts “may have fallen into the ‘I hate Comic Sans’ trap”, as they all look quite exaggerated. The top performers were all sans serif fonts.
• The presenters admit that the survey raises lots of questions, rather than giving lots of answers! But TLDR: that ‘accessible’ font you’re using may not be as accessible as you think.

Audio killed the video call

• An interesting article talking about the progression from, pre-pandemic, video-calls happening once or twice a week, to mid-pandemic, where video calls happen for several hours per day. The video fatigue has led to an explosion in popularity for audio-based apps, such as Clubhouse, where users can drop into chatrooms and participate in discussions with strangers.
• They’re able to “recreate serendipitous moments like chance encounters and coffee machine conversations”, in a way that Zoom doesn’t. But they are ableist by nature, offering poor or zero experience for the Deaf community.
• The article touches on an interesting point: that this “levels the playing field”; insofar as many blind people “have little interest” in social media apps such as Instagram. The implication is that by the nature of these apps, they’re not going to offer much to certain segments of the disabled community, and there are usually other options to cater to everyone.
• That’s a difficult line to take, in my opinion. But it does make me wonder how everyone’s needs can be met without fundamentally changing the offering of these apps.

Some questions on accessibility in email — answered

• Some interesting nuggets of information here, resulting from a survey of 162 respondents (yes, the sample size is too small to have a lot of confidence in these results).
• 98% of people find a font size of 16px easy to read, compared to 70% for 14px (a font size that is “often cited as being accessible”). Participants generally did not find 12px easy to read.
• 88% of participants found a line height of 1.5em easy to read; it was the best performing line height out of the options available (various options from 1em to 2em).
• There was a clear preference for “accessible text links” (links using border-bottom for their underline), rather than the standard text-decoration: underline links. This approach is to “benefit people living with dyslexia, for whom underlining can cause text to run together, or collide”. I don’t remember coming across this before, so the Accessible Text Links article is worth a read too.

In Quest of Search

• Sara Souedian gives her thoughts on why we need a native <search> HTML element. This would be syntactic sugar for <div role="search">, like we already have for <main> / <div role="main">.
• The first rule of ARIA is to not use it if there is a native HTML element with the semantics of the required behaviour already built in. It could be argued that ARIA should be phased out, “with HTML replacing ARIA bit by bit until its services are no longer required”.
• Search is such a common feature on websites that making it easier to apply accessible semantics can only be a plus. With it, it should be even easier for users of assistive technologies to jump to the search section of the page.
• There is a related GitHub issue on the whatwg/html repository, calling for a HTML search element.

Axe-core vs PA11Y: Which one should you choose?

• GitLab now offers Pa11y as part of its CI pipeline, with no configuration needed. Craig Abbott compares it to axe-core, which is used by Deque for its acceptance tests. Out of 142 issues tested:
  • axe-core found 39 issues in total, or 27%. 36 were violations and 3 were potential issues which required a user to check manually.
  • pa11y found 29 issues in total, or 20%.
  • 19 issues (13%) were found by both tools.
  • 20 issues (14%) were found by axe-core but not Pa11y.
  • 10 issues (7%) were found by Pa11Y but not axe-core.
  • Combined, 49 issues (35%) were found.
• Craig recommends using both tools. He also notes that axe-core isn’t necessarily ‘better’ than pa11y; the issues in the set that Craig tested with might just happen to play to axe-core’s strengths.

An update on the accessibility of conditionally revealed questions

• A GOV.UK blog about the ‘conditional reveal’ option in the GDS Design System’s radio and checkbox components.
• The GOV.UK Accessibility Team discovered that the implementation failed WCAG 2.1 Success Criterion 4.1.2: Name, Role, Value, as the act of conditionally revealing content would not notify some screen reader users.
• This came down to the use of aria-expanded, which the team later realised was “not supported for the role of a radio button or checkbox in the ARIA specification.”
• Further user research found that some users were in fact notified of changes, despite it not being supported. Additionally, the notification did help users; so they brought their findings to the ARIA Working Group for consideration.
• The team then prototyped a few different ways of improving the relationship between the question and the revealed content. The conclusion was to avoid using “multiple fields or text content (like warning text) within reveals”. Simple questions with a single input were fine.

Facebook Rolls Out News Feed Change That Blocks Watchdogs from Gathering Data

• An update to Facebook, which has not yet been rolled out to all users, obfuscates the page content in the markup of the HTML DOM, potentially excluding disabled users. It adds “superfluous text to news feed posts in the form of ARIA tags” (“junk code”) to make it more difficult for people and bots to “scrape” the content, which this article says includes legitimate users such as researchers and journalists.
• These junk characters have made similar moves in the past to reduce the efficiency of ad-blocking software.
• Facebook claims that its new update has been designed not to reduce accessibility. However, the article contains a video demonstrating that the Microsoft Narrator screen reader reads aloud a string of junk characters on at least one occasion.
• There is a dissonance between making content accessible and building in anti-scraping / anti-ad-blocking measures. It’s difficult, impossible even, to do a good job at both.

Improving The Accessibility Of Your Markdown

Another excellent Smashing Magazine article by Eric Bailey. Despite the title, there aren’t many Markdown-specific accessibility tips here, but it is packed with information and I challenge you not to learn something new from it!

• Markdown is a text to HTML conversion language, created in 2004. It has no editor and therefore no Clippy-esque experience to warn you if you’re introducing anything inaccessible.
• The main advice is to use headings to structure your content, as this is by far the most popular method assistive technology users use to navigate your page. Eric doesn’t use assistive tech, but he also navigates by headings via the headingsMap browser add-on.
• Write good alt text for your images, using the W3C alt decision tree if in doubt. And make sure you use punctuation!
• When linking to SVG images, add the “img” role to it, to prevent assistive tech from skipping it or announcing it as a group. E.g. <img src="foo.svg" role="img" alt="Sunflower" />.
• Whilst it is possible to write Markdown for opening links in new tabs ([text](url){:target="_blank"}), avoid it, as it can be a WCAG failure and a security risk.
• Skip links aren’t limited to the main site navigation; you can also use skip links to skip over, say, your Table of Contents, or to avoid keyboard traps.
• Beware libraries which automatically turn your headings into anchor links, as the markup is tricky to make accessible. I’ve covered this already in dai11y 23/12/2020.

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 start off with a Twitter special! I’ve already recently written about how Twitter’s new design has been giving users headaches. But there have been a flurry of other articles about Twitter, so I thought I’d round them up for you.

• What’s Really Wrong With the New Twitter Font
  • An interview with Frederick Brennan, who designs open source fonts, though is better known for founding and then trying to shut down the imageboard site 8chan.
  • “[Twitter’s newly commissioned font] Chirp is extremely similar to GT America, which is itself based on Franklin Gothic. They changed the spacing ever so slightly and changed the square dots over i and j, and then the period and comma to be circular”
  • Frederick says that typeface readability is cultural; “in the Middle Ages, people found Gothic lettering to be extremely readable”. Given enough time, people would get used to the new font.
  • There’s a problem with the hinting, causing some letters to look one pixel too tall or short on particular screen sizes. “This is something really fundamental and basic to type design. This definitely points to [Twitter] cheaping out.”
• Twitter’s web redesign isn’t as accessible as it should be, experts say
  • This TechCrunch article explains that the new high-contrast design, whilst generally making things more legible for those with low vision, is causing ‘strain’ for some users.
  • In September last year, Twitter introduced two dedicated accessibility teams, after previously relying on employees to volunteer to do accessibility work on top of their regular jobs. Whilst this was a positive move, some experts suggest that Twitter did not include disabled people in the design decisions early enough; Twitter disputes this.
  • Twitter has made a11y improvements in other areas, including SRT subtitle file support for videos, and live captioning.
  • The article calls out a saturation slider that Discord added to its desktop app accessibility settings.
  • “Web accessibility isn’t one-size fits all — while some users may need a high-contrast display, others who suffer from chronic migraines might require a more muted experience”. It’s odd that Twitter did not offer an option to reduce contrast or change font, as it already has customisation options for dark/light modes, font size and link colours.
• Twitter’s new font and Last of Us 2: an accessibility lesson to be learned
  • Continuing the customisation theme, this UX Collective article suggests Twitter should give users more choice over their UI settings, taking inspiration from Last of Us 2, which has over 60 different accessibility settings. It is possible to play the game entirely by sound, or one-handed.
  • The game’s designers initially broke the settings down into ‘accessibility modes’ for hearing impaired gamers, or for those with motor control issues. But users wanted to really be able to fine tune their settings, so the designers had to “give up their nice, tidy menus in favour of something a little messier”.

In other news…

How to use the Accessibility Checker in Microsoft Office

• Perhaps obvious if you know how, but as someone who has used Office tools a fair bit over the years, I don’t think I’d ever known about the Accessibility Checker!
• To use in Microsoft Word, Excel, OneNote, or PowerPoint:
  • click on the “Review” tab
  • then the “Check Accessibility” menu trigger
  • then the “Check Accessibility” option
  • It will display accessibility information in a panel on the right
• The article is very light on detail, but I imagine this tool captures issues like text being too small or obscured, and colour contrast issues.

HTMHell Issue #12 – crossed out content

• The good person behind HTMHell describes the two ways to represent crossed out text in HTML: <del></del>, and <s></s>. They clarify in the article that “crossed out” has semantic meaning that doesn’t necessarily have to manifest itself as crossed out text.
• The <s> element should be used for highlighting contents that are no longer accurate or relevant. Think “Original price: £10, Special offer: £8″.
• The <del> element should be used for highlighting a removal from the document, to retain an edit history. Example:
  • The man's name was <del datetime="2021-09-03T17:42:36">Mrak</del> <ins datetime="2021-09-03T17:42:40">Mark</ins>.
• Different screen readers announce the deletions/insertions in different ways. The article goes into some detail around how to use CSS pseudo elements to add your own textual prefixes/suffixes.

Google Announces Seismic Change to Docs

• A WebAIM article talking about the May announcement by Google that it would switch to canvas-based rendering for Google Docs. The “current HTML-based rendering approach” has inconsistencies across platforms, and performance issues, which can be addressed by switching to canvas.
• Google claims “compatibility for supported assistive technologies such as screen readers, braille devices, and screen magnification features, will not be impacted by the canvas-based rendering change”. No technical approach is outlined in the announcement, but there have been discussions of leveraging a “hidden” DOM through the Accessibility Object Model (AOM).
• The WebAIM article has a section on “Accessibility Community Feedback” which highlights concerns from the community. An interesting point is that developers look up to Google and try to emulate how they do things, so this change could cause third party sites to switch to canvas based rendering with little regard for the screen reader experience.
• As of mid August, there is no update on a timeline for when the changes will be rolled out. The proof of concept released by Google has only “rudimentary assistive technology support” and “significant improvements” will be needed before it is up to par.

FlickType gives up on accessible iPhone keyboard after ‘abuse’ from Apple

• “FlickType, maker of the accessible iPhone keyboard that has become popular among those with vision impairment, has confirmed it is discontinuing its app after years of obstacles and “abuse” from Apple’s App Store approval team.”
• “The announcement comes after FlickType submitted an update to fix bugs related to iOS 15 and got “incorrectly” rejected by Apple. The team says Apple has ignored repeated requests for clarification and support.”
• “FlickType was designed to make iPhone easier to operate for blind users — and it worked. A 2018 report from the American Foundation for the Blind found the keyboard greatly increased typing accuracy and speed, and was significantly easier to use than Apple’s for those with vision impairment.”

a11y-automation.dev

• A useful reference of a11y fails, describing at a glance whether or not each failure can be linted, tested, or manually tested.
• For example “Autoplaying media” has a “Linting status” of “Could Exist”, a “Testing status” of “Exists”, and a “Manual testing status” of “Should Exist”.

Doctor’s orders: ‘Nature prescriptions’ see rise amid pandemic

• A really interesting article about how a growing number of doctors – particularly pediatricians – in the USA are prescribing walks in the park. The prescriptions are “specific, just like an antibiotic”, with patients told how often they should go, and where.
• One doctor gave their patient “a one-year pass to Washington’s state park system”, telling her to “go for walks, go camping, do what you need to do”. Patients see weight loss and decreased anxiety. “More than half of my patients who receive a ‘prescription’ for time in nature go ahead and do so successfully,” said one doctor.
• The prescriptions do face issues of access, where parks in low-income neighbourhoods tend to be smaller and more crowded.

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:

A Deep Dive on Skipping to Content

• Paul Ratcliffe describes a “2021-friendly” implementation of a skip link. It looks something like this (note that the text is hidden visually until it is focused – I’ve omitted this from the code below):
  • <a href="#skip-link-target">Skip to main content</a>
  • <a href="#skip-link-target" id="skip-link-target">Start of main content</a><main>the content</main>
• Paul points out that the use of <main> markup means savvy screen reader users can skip straight to the main landmark. For those that rely on skip links instead, he recommends a link in the <header> which refers to a link just above the <main> (not inside it, as it would impact SEO).
• I hadn’t seen an <a> element as the target of a skip link before; Paul says this is to give users feedback that the skip link worked. If the page content is too short, the browser wouldn’t scroll and it could be difficult to show that the focus has moved otherwise.
• Susanna Celso left some comments for Paul before writing a follow-up blog post, arguing that the proposed implementation could confuse users (linking to a link that links to itself, and also stating that you’ve reached the “start of main content” when technically you’re still outside that landmark. Susanna makes the case for linking to the <main> element directly, though concedes screen readers will automatically start reading all of the text in that element, which can be an awkward experience.
• Susanna concludes that the best link target would be a <h1>, provided it’s the first element inside the <main> landmark.
• An interesting and healthy discussion between two clearly knowledgeable developers – worth reading both posts!

Writing great alt text: Emotion matters

• Jake Archibald describes how he was trying to decide what alt text to use for his avatar, which would appear alongside his name, in a list of conference speakers. His (and my) instinct was that it should be nullified (alt="") because it would otherwise be repeating information elsewhere in the page.
• However, in his avatar, Jake is pulling a pose and aiming to inject a bit of humour. It’s not right that screen reader users miss out on that context. So Jake opted for the following alt text: “Jake, cheekily peering from behind a plant”.
• Léonie Watson has written about this in her blog post, Text descriptions and emotion rich images. Context matters. Developers sometimes worry that descriptive alt text will make the page too ‘noisy’, but as Léonie points out, screen reader users will skip over large swathes of the page in the same way as sighted users would.
• This seems to be a bit of a trending topic at the moment; I recently covered a similar article by Eric Bailey which concludes that most images nowadays are not purely ‘decorative’ and do require alt text.
• Jake adds that “if you’re trying to do the right thing, you’re almost certainly improving the experience for real people”. Most of the time, your alt text won’t be worse than no alt text at all.

Twitter’s new design to get fix after headache complaints

• BBC article from 16th August. Highlights:
  • “Twitter is making changes to its new redesign, after users complained of headaches and discomfort.”
  • “Unveiled only last week, the redesign mainly involved high-contrast colours and a custom-designed font, Chirp.”
  • Its aim was to “improve content consumption and clean up ‘visual clutter’. But many, especially with accessibility needs, found it confusing, hard to read and uncomfortably bright.”
  • Users have reported the font being smaller and denser, so are having to strain their eyes more to read.
• Twitter Accessibility have confirmed that fixes are on the way.

It is time to ditch the title “Evangelist” from Accessibility

• Ronise Nepomuceno explains why she hates the term ‘Accessibility Evangelist’:
  • It reinforces the idea that accessibility is a ‘nice to have’ that can be deprioritised
  • It has its roots in tech in the 1980’s, when Apple put together a team to ‘evangelise’ developers to develop for the Macintosh platform without the financial incentive compared with their competitor IBM. Ronise feels this is exploitative.
  • It has religious connotations: “they think we are coming for them, to judge for their sins and condemn them all to eternity in Hell”.
  • “It is also essential to respect the boundaries between Digital Accessibility and Disability Rights. They are two different things”.
  • Ronise points out that the term is applied in other parts of tech, e.g. “Cloud Evangelist”.

What people should know BEFORE writing articles or creating products about accessibility

• Sheri Byrne-Haber writes about getting disabled users involved in your product development early on. It is possible to build a product that is technically accessible but is inefficient and unusable in practice. “You cannot retrofit lived experience”.
• Some products don’t support an intersectionality of disabilities. Sheri gives the example of an accessibility overlay that offered profiles for motion sensitivity, and for vision loss, but not for both at the same time.
• Language is important when it comes to writing about accessibility. Terms that are out of favour include “suffering”, “wheelchair bound”, “high / low functioning”, stigmatizing the individuals being labelled and “conveying nothing about the strengths that individual might possess”.
• Sheri bemoans the use of “headcounts” to make disability inclusion decisions. “How many people is this going to benefit?” is irrelevant; accessibility is a civil right.
• Sheri ends with this: “Accessibility is a program, not a project”. If you work from a checklist, or are working to an end date, that is a warning sign.

‘May be an image’: What it’s like browsing Instagram while blind

• Kait Sanchez writes about the experience of screen reader users on social media. The auto generated alt text for photos on Instagram and other sites is often poor: “two brown cats lying on a textured surface” turned out to be a woman in a wedding dress.
• Kait says that technology can’t replace the human element; a computer is never going to know you posted an image of your dog because of its hilarious quizzical expression, rather than because he is a black-and-white pitbull mix.
• Alt text hasn’t always been possible to write on social media platforms, who often play catch-up to improve their accessibility only once they gain popularity. There’s an assumption that blind people aren’t interested in visual media. But as Kait points out, culture is moulded on social networks, and it’s not fair for people to miss out on a shared social language.
• It’s easy to blame the social media users for not providing alt text, or the tech platforms for not educating them. However, content such as memes – rapidly evolving iterations of undescribed images with tiny words in weird fonts – are particularly hard to write alt text for:
  • “The funniest images rely on comedic timing through careful visual composition, prior knowledge of a specific meme, or familiarity with several different cultural references.”
  • “Writing an image description for an esoteric meme can feel like explaining internet culture to your grandparents: you suddenly don’t know how to describe what exactly made you laugh.”
• We can educate against the simpler problems though. Kent Dodds demonstrates why special characters and emojis in usernames provide a terrible experience for some social media users. “A screen reader isn’t technically incorrect if it reads a character as “mathematical bold capital,” but most sighted people will read it simply as a letter with different formatting.”

Do not assume users turn off CSS or JavaScript

• I’ve seen this before, but Stefan Judis’ newsletter pointed it out to me again.
• This is the Government Digital Service’s “service manual” on “Building a resilient frontend using progressive enhancement”.
• It maintains that we don’t support no-JS / no-CSS browsers for the sake of a minority of individuals who may disable such features. Instead, we do so to account for all manner of other circumstances, including network errors, ad blockers, firewalls and proxies, all of which can interfere with the loading and execution of CSS/JS.
• Making services work without JS or CSS makes them more accessible to a wide variety of users.

Accessibility of the section element

• Scott O’Hara writes about the <section> element, designed for representing a group of content that has an “overarching theme”. Headings within each <section> are meant to be scoped semantically within that section (you could in theory put <h1> tags inside each <section>), but in practice, nothing different gets programmatically exposed to assistive technologies.
• The only thing <section> currently does in that regard is to define an implicit role="region". However, this does not get announced to screen readers unless it is given a name, either via aria-labelledby, aria-label, or title.
• Scott recommends naming <section> elements only when absolutely necessary: “if everything’s a landmark then there’s nothing really special about them, is there?”. Instead, Scott suggests using proper heading levels to indicate sections and sub-sections of content.

Hyperlegible: an approach to accessible type design (video, 10 minutes)

• Linus Boman, who I was lucky enough to have as a housemate a few years ago, is a design expert. Here, he talks about the new Atkinson Hyperlegible Font – which he helped to develop – and which is now freely available on Google Fonts for personal and commercial use.
• The font is designed to be as accessible as possible whilst still embodying harmonious design (avoiding the trap of becoming “some kind of ransom note”, as Linus puts it).
• Linus describes how each glyph’s apertures are widened to make it easier to distinguish, and walks through other techniques such as adding serifs to differentiate between homoglyphs (e.g. lowercase L and uppercase i).
• At around 7 minutes in, the video does a particularly good job of illustrating how conditions such as blurry vision or diabetic retinopothy affect the legibility of the characters.
• Linus has quite an active YouTube channel which is definitely worth checking out further!

Link shorteners: the long and short of why you shouldn’t use them

• A blog post by the Government Communication Service.
• In the old days of social media, URLs used to count towards the character limit, so using a URL shortener was often a necessity. This isn’t the case anymore.
• Whilst these URL shorteners provide insights into how often a link is clicked, they offer little more than the social media platforms and Google Analytics offer natively.
• Short URLs provide no clue as to the content, and can’t be trusted. Some link shortening tools threaten user privacy too, installing cookies when people follow our links.
• GCS go into more detail on creating accessible links for social media:
  • One link per post (as “people who navigate via keyboard shortcuts often find it frustrating to navigate to multiple links”)
  • Clear calls to action (“Read guidance on applying for a driving license + LINK”)
  • Use capital letters at the start of each word in a hashtag, e.g. #AccessibilityAwareness. These tags are often turned into links, and assistive technologies reading the link text should read the words correctly when capitalised.

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:

Your Image Is Probably Not Decorative

• Eric Bailey explains why most images nowadays need some form of alternative text.
• You can ‘nullify’ images – removing them from the screen reader experience – by adding an empty alt text, i.e. <img alt="" ...>. This should only be used when the image doesn’t convey information that is important to understanding the purpose of the page or view.
• You might nullify your images in the following scenarios:
  • Old layout techniques requiring ‘spacer’ images
  • Where the image repeats content that is already in the page (though this could still be confusing for screen reader users who have partial vision)
  • Supplemental icons (e.g. <button><img alt="" src="icon.svg"> Print</button>).
• Eric also explains how you can provide alt text when using CSS background images (hint: it uses the spacer gif!)

The accessibility stalemate

• Chris Heilmann talks about how the accessibility community holds back the accessibility movement by setting the pedestal too high.
• There are plenty of great talks about accessibility, but, apparently, many speakers don’t release their slides afterwards. Why? Because people “call out any accessibility problems with the materials”. If the content isn’t 100% accurate, or the platform has one or two of its own accessibility issues, then the materials don’t get released and people aren’t able to benefit from them.
• Chris says “I saw many conferences not release any of the materials or videos as they couldn’t caption them or host them on a platform that allows for it.” He says that some people enjoy criticising articles for the platform they are published on, e.g. “Isn’t it ironic that I can’t read your article on mobile best practices on my mobile device?”
• “On the surface, it seems to be valid criticism to call out when [presentations] fail to provide alternatives for each image and video in them. Except, it is a cheap shot and feels like a distraction from the problems the materials talked about.”
• Controversially, he suggests that not all content needs to be accessible. “What do we gain by ensuring that a presentation about how people use screen readers is accessible by a screen reader? Is that the audience? The one who already knows this information?”

From A Colourblind Designer To The World: Please Stop Using Red And Green Together

• A designer with deuteranopia – red/green colourblindness – writes about how the use of green and red in web design is problematic. Namely:
  • Using colour to indicate validation status in forms. Adding other visual indicators such as icons would help to differentiate.
  • Using green and red to indicate primary and secondary actions, e.g. “OK” and “Cancel”. Using fill colour just for the primary action helps to disambiguate.
  • Red and green used to convey meaning in charts – literally unusable for people with colourblindness.
• If you have to use red and green in your design, choose different luminosity (i.e. make either the red or the green darker and saturated). UK traffic lights look quite similar between red and amber, but the green is very distinct because its saturation is different from the other two.
• Colourblindness affects 1 in 12 men and 1 in 200 women.

New in ARIA 1.2: ARIA IDL attributes

• Scott O’Hara writes about the new ARIA IDL (Interface Definition Language) attributes, allowing you to set element attributes succinctly in JavaScript via foo.role = 'checkbox' and foo.ariaChecked = false. Until now, we’ve had to use setAttribute, i.e. foo.setAttribute('aria-checked', 'false').
• This is supported in all Chromium browsers, but currently not in Firefox.
• It’s not yet possible to set attributes in this way if they take multiple IDREFs. For example, aria-labelledby="id1 id2 id3" has no new corresponding IDL attribute yet.

Tech platform devises new system to simplify process of booking rail travel for disabled travellers

• Whoosh Media have created a system, “The Real-Time Journey Dashboard”, that allows you to scan QR codes on your train seat, to view information such as location of toilets on the train, as well as a live dashboard demonstrating journey progress and delays.
• “Travelling by train is very often a hazardous lottery for wheelchair users and those with restricted mobility, simply because rail companies have failed to keep up with the way people research their journeys.”
• The article above is light on details – I found more information at Onboard Hospitality:
  • Currently found on Northern Rail and Grand Central Rail, with more operators to follow in the coming months.
  • The system is currently receiving around 1500 scans per day.
  • The system can also be used to report antisocial behaviour to the British Transport Police.
  • The system is not an app, though it’s not clear what it is. Presumably it’s just a website that gets loaded via the QR code.

Move the pointer using head pointer on Mac

• This is a macOS user guide for how to enable the ‘head pointer’ on your Mac, using your built-in camera to follow your head movement and move your cursor. I was pointed to this via Stefan’s Web Weekly newsletter.
• It’s quite effective and worth experimenting turning it on to get a feel for what it is like. You may need to adjust the pointer speed as otherwise the cursor may not move enough in sync with your head.

A day in the life: What it’s like to travel through an airport and on a plane as a wheelchair user

• An interesting read about just what a wheelchair user goes through on a typical flight. These users must be transferred into a narrow aisle chair (designed to be able to fit in the aisle of the plane) and then transferred into an airplane seat. Their wheelchair is put in the hold.
• Going through security is difficult as the wheelchair makes the metal detector check redundant, so these passengers have to have a pat-down, which can slow the process down considerably. TSA PreCheck is an option for American fliers to skip the security check.
• In May, Gabrielle deFiebre travelled from New York to Phoenix on a Delta flight. Her wheelchair was damaged by employees in an incident recorded in a now-viral video. In 2019, airlines damaged more than 10,000 wheelchairs. All Wheels Up is an organisation advocating for allowing wheelchair users to be able to stay in their own wheelchairs during flight.
• deFiebre doesn’t eat or drink much at all on flights, knowing the difficulties of transferring into the aisle chair and then into the cramped airplane bathroom.

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:

Coursera accessibility courses

• A recommendation by my colleague Stephanie Hill: “Top Web Accessibility Courses” by Coursera. Some interesting ones highlighted below.
• Design:
  • An Introduction to Accessibility and Inclusive Design
  • Web Design for Everybody Capstone
  • Foundations of User Experience (UX) Design
  • Basics of Inclusive Design for Online Education
• Testing:
  • Test Accessibility of your Design with A11ygator
  • Testing for Web Accessibility With Accessibility Insights
• Miscellaneous:
  • Disability Awareness and Support
  • Introduction to Accessible Web Development

Managing focus in the shadow DOM

• Web developer Nolan Lawson writes about the difficulties of managing focus on a web page which makes use of the shadow DOM; parts of the page that are encapsulated and unable to be interacted with programmatically in the same way as regular DOM elements.
• If you’re implementing a modal dialog, you need to manage focus and prevent the user from tabbing outside of the modal window whilst it’s active. This is easier said than done; a common implementation is to use querySelectorAll to find all interactive elements in the page, finding the first and last focusable elements within the modal, and then using a listener to hook into the tab key and overriding where it triggers the focus. But document.querySelectorAll won’t return any shadow DOM elements, so the browser could still allow you to tab into a shadow DOM area outside of the modal.
• Nolan proposes a new API; element.getNextTabbableElement() and element.getPreviousTabbableElement(), delegating this heavy lifting to the browser. For now, we’re left manually traversing through the DOM and inspecting each element recursively to see if it has a shadow DOM child, to create our list of all interactive elements in the page.
• My old team at the BBC also wrote about how they migrated away from iframes to the shadow DOM.

Coronation Street highlights the challenges faced by disabled people working from home during the pandemic

• This story focuses on Izzy Armstrong, played by Cherylee Houston. The storyline goes that Izzy is clinically vulnerable and has been shielding and working from home throughout the pandemic. Her job is now at risk as her boss insists she returns to the office.
• The actor Cherylee has in real life been shielding since March 2020, as when she was 23 she was diagnosed with a rare condition called Ehlers-Danlos syndrome.
• This will be the first time viewers will see Izzy in her real-life home environment. The scenes were filmed by Cherylee and her partner at their Manchester home.
• “Izzy Armstrong’s upcoming storyline on Coronation Street highlights the reality of many disabled people’s struggles across the UK.”

Why debate non-text contrast of UI elements?

• An article by Dave House, describing how WCAG 2.1 Non-text contrast has enough wiggle-room in it that designers often dismiss it, saying “UI elements don’t need to meet this requirement”. He explains: the success criterion states “if the visual indicator of the control is the only way to identify the control, then that indicator must have sufficient contrast”. Therefore, for example, a “Submit” button whose background colour has low contrast is still recognisable with the background colour removed, provided it is in the context of a form, and thus doesn’t fail the criterion.
• Dave suggests a simple test: for every interactive UI element with a contrast of less than 3:1, remove the thing that is low contrast (be it the text, the background colour, the border, etc). Then review the page and see if it still makes sense. The argument is hard to swallow when Dave uses the Facebook and Google landing pages as examples – if they can’t get it right, what chance do the rest of us have? – but it’s a good rule of thumb nonetheless, and a useful design tip to keep in your arsenal.

Blind York student wins £5k claim over ‘inaccessible’ loan form

• Disability rights activist Holly Scott-Gardner, has won a settlement after being unable to fill in a student loan disabled students application form, because it was inaccessible to her (as someone who is blind). Holly had to fill in the form over the phone, after several failed attempts online, and successfully sued the company for a breach of the Equality Act 2010.
• Holly wrote a long Twitter thread about her interaction with the company, pointing out that they offered to “work with” her on making their services accessible, but this a) isn’t her area of expertise to be a consultant on, and b) they weren’t offering to pay her for her time. The thread is full of great quotes:
  • “In what world is it acceptable to expect the person who has had their rights violated to come and educate you out of the goodness of their heart?”
  • “I am not a token minority. I do not exist as an educational tool for non-disabled people.”
  • “It’s frustrating that everyone seems to view disabled people as experts on every aspect of being disabled. I know I can’t access something, that doesn’t automatically mean I can fix it.”

Experimental Brain Implant Lets Man With Paralysis Turn His Thoughts Into Words

• A fascinating article describing how a paralysed man has had a device implanted into his brain, which decodes signals in the brain that once controlled his vocal tract. After several months of training, the system has a vocabulary of 50 words and the man can communicate at a rate of 15 words per minute. Normal speech is in the region of 120-150 words per minute. A professor at Stanford University acknowledges the 50-word vocabulary as a “huge achievement”, but also feels the vocabulary “could easily become 500 or 5,000 words.”
• The anonymous patient in question is in his 30s, and has been unable to speak since a stroke 15 years ago. His arms, legs and vocal tract are paralysed, but the areas of the brain that once issued speech commands are intact. There was initially some doubt that the speech commands in the brain would still work after 15 years without use.
• An ethical dilemma raised in the article is that it will be possible to “eavesdrop” on the brain. We need to ensure that such devices “allow people to be able to think their private thoughts without anything just being broadcast to the world”. This “may be easier with devices that rely on brain signals that control muscles, because these signals generally aren’t sent unless a person makes a conscious attempt at movement”.

Microsoft: Accessibility is a focus in Windows 11

• Windows 11, announced at the end of June, is being designed “with accessibility in mind”.
• The OS will include dark, light and customisable themes, and the improved Closed Captions will be more customisable too.
• Microsoft have rebranded the old “Ease of Access” setting to the more idiomatic “Accessibility”, to make it easier to find your settings.
• Like Windows 10, the new OS will include assistive tech including Narrator, Magnifier, Closed Captions, Windows Speech Recognition and Windows Voice Typing.
• Finally, Windows 11 will support Linux applications via something called WSL (Windows Subsystem for Linux), which is being carefully developed to integrate with assistive technologies.

Will Accessibility Become Increasingly Important for SEO?

• A deque blog post, with no clear answer – but an interesting topic nonetheless.
• Google has for years made mobile usability and speed a factor in SEO – Search Engine Optimisation – meaning that they favour websites which work well on mobile and load fast, and in turn, rank the website more highly in search results.
• Google states that “everyone should be able to access and enjoy the web. We’re committed to making that a reality”. Google’s Lighthouse tool, which measures website performance and accessibility, provides accessibility scores which could very well lend themselves to an SEO ranking algorithm in the foreseeable future.
• The article acknowledges that there is already a coincidental link between accessibility and SEO. Accessible pages tend to be well marked up pages, containing metadata, descriptive link text and headings, and alt text.

Accessible Overflow

• A fascinating insight into browser behaviour by Marcus Herrmann. When navigating ‘overflow’ content, i.e. text that doesn’t fit inside its container, this requires us to scroll through the content. Many of us would simply use the mouse wheel to scroll within those containers, but how about users who navigate by keyboard? Keyboard users use the up and down arrows to move up and down the page, but what about the overflow content within the page?
• Firefox automatically puts such content in the tab order, making it reachable and its contents scrollable. In Chrome, Edge and Safari, however, overflow content is not scrollable with a keyboard by default. There is a Webkit issue and a Chrome intent to ship, but otherwise developers are stuck using the following workaround:
  1. Add tabindex="0" to the container
  2. Apply focus styles to the container, e.g. .my-owerflowing-div:focus { outline: 2px solid; }
  3. Add role="region" and supply an accessible name using, for example, an aria-label.
• Adrian Roselli wrote about this in more detail in Keyboard and Overflow.

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:

What Happens When a Blind Person Test Drives VoiceOver Recognition?

• An article by Rhea Althea Guntalilib, describing her experience of using the new “VoiceOver Recognition” features of iOS 14. It is a collection of tools including “Screen Recognition” (which I’ll talk about below), “Text Recognition” (which detects text found in images) and “Image Descriptions” (which describes image contents). These features are accessible via Settings > Accessibility > VoiceOver and can then be quick-selected via the VoiceOver rotor.
• I covered Screen Recognition in dai11y 22/12/2020: “It uses AI to detect interactable elements on the screen, even when such elements aren’t properly labelled / exposed to assistive technology. It has the potential to allow blind users to use apps that are otherwise inaccessible.”
• Rhea found the Image Descriptions improved her experience of the Facebook and Instagram apps, and also Text Recognition was great at describing her screenshots of captured text messages. Screen Recognition came in handy for her banking apps, which otherwise have no accessible way of transferring funds or paying bills. But she did find she had to turn off Screen Recognition in places, e.g. to properly access the list of available banks, as it would interfere with how VoiceOver worked. Other apps, such as email, had attachments that could not be processed by VoiceOver Recognition.
• In summary, whilst it has some glitches and limitations, it has “delivered many improvements in the user experience of a blind iOS customer”.

Accessible SVGs

• Think you know SVGs? This article is worth a read – you just might learn something.
• SVGs have an implicit WAI-ARIA role of “graphics-document“. You should only change this if the SVG only contains an image; an attribute of role="img" or role="graphics-symbol" would be appropriate.
• Hide decorative SVGs from screen readers using aria-hidden="true" – not role="presentation", as this doesn’t hide the contents of the SVG from screen readers.
• SVGs can have a <title> attribute which acts like an alt attribute on a normal image. It has to be the first child element within the <svg>. There is also an optional <desc> element which can follow this, and should be used to present more detailed textual information. Browser support for both of these is good but not 100%; aria-label can be added for wider support.

Practical accessibility, part 2: Name (almost) everything

• It’s not enough to just use semantic markup to, say, create a list in HTML (the “what”), and mark it up with a role="menu" (the “how it’s supposed to work”). We also often need to label the list, to explain “why” it’s there. For example, an aria-label="Main menu" to give some extra context to screen reader users.
• This article describes how and when you should name things in HTML. It covers the basics, such as associating a label with an input, which effectively gives the input a name, but it also covers the stuff that is more easily omitted, such as applying a label to your ARIA regions.
• Not every landmark needs a name, but any navigation, form and region should, as well as main (it’s good practice to associate the H1 element with the main content in your page via aria-labelledby). Landmarks that appear once per page, such as banner, should not have a name.

Online Instruction Did Not Make Things Easier for Disabled Students

• An interesting article, worth reading as it goes against the current narrative that the disabled community have benefited from the move to online tuition. It covers university undergraduates and graduates in America.
• “Only 20% of [American] undergraduate students with disabilities reported enjoying online learning, and over one third of students with disabilities reported no increased satisfaction with online learning in general”.
• The story changes slightly for graduate students with disabilities, who liked online learning more than those without disabilities, but also felt less productive and more disconnected from professors.
• That said, there were some areas where “disabled students did describe a greater satisfaction than non-disabled students”, such as “comfort levels in speaking up in class” and “connection with other students”.
• Learning from home rather than university “meant being removed from the protective factor of the university”. Shockingly, only 40% of undergraduate students with multiple disabilities have a “place to live that is free from physical or emotional violence or abuse”.

Kellogg’s: a game changer in accessible packaging

• In partnership with RNIB, Kellogg’s has trialled including NaviLens codes on its packaging, giving visually impaired customers a way of scanning products to find out their ingredients, allergen and recycling information.
• NaviLens codes work in a similar way to QR codes, but can be detected “in a fraction of the time, from up to three metres away”. RNIB and Kellogg’s deduced that NaviLens catered to more people with sight loss, rather than those with specific requirements (such as braille users).
• 97% of the trial’s participants agreed they’d like to see more of these accessibility features available on grocery packaging.
• There’s a 5 minute video explaining more about the project.

Screen Reader User Survey #9 Results

• The famous WebAIM survey this year had 1568 responses, mostly from North America and Europe, with a pretty even age split. 92.3% of respondents said they have a disability, almost 80% of which was blindness.
• 57.5% of respondents class themselves as “advanced” screen reader users, versus 37.4% “intermediate” and 5.1% “beginner”. This roughly correlates with their self-assessed levels of “Internet Proficiency”.
• JAWS is the primary screen reader for over half of respondents, followed by NVDA on around 30%. VoiceOver counts for just 6.5%. This is a decline for NVDA and VoiceOver compared to previous years. Windows Narrator is the primary reader of less than 1% of respondents, but is “commonly used” by 41% of them, compared to 30% in 2019.
• Chrome is the browser of choice for 53.6% of respondents, followed by Edge at 18.4% and Firefox at 16.5%. Chrome and Edge usage has increased notably. JAWS with Chrome is by far the most common screen reader & browser combination, at 32.5%. 91.1% of respondents use Windows, vs 6.5% on Mac.
• 72% use iOS mobile devices, vs 25.8% on Android. This corresponds roughly with mobile screen reader usage of 71.5% on VoiceOver and 29.1% on TalkBack, and with choice of browser (Safari: 61.6%, Chrome: 24.2%).
• 99.4% of respondents have JavaScript enabled.
• Almost two thirds of screen readers report that they are “very satisfied” with their primary screen reader, and almost a third “somewhat satisfied”.
• When asked how often they use “skip links” when available, 17.5% said “Always”, 15% said “Often”, 29.7% said “Sometimes”, 22.7% said “Seldom” and 15% said “Never”. Whilst very mixed results, these are largely unchanged from the 2017 survey.
• Around 39% say web content has become more accessible this year, but around 42% say there has been no change, and 18.5% say content has become less accessible.
• The majority of screen reader users navigate pages by working through the headings first. About 85% of users find the use of heading levels either very useful or somewhat useful.

Accessible design: How much motion is too much motion?

• Heather Waroff, Senior Designer at Microsoft, writes about interaction design. The most useful part of the article for me was the list below, developed “in conjunction with Accessibility specialists”. It describes the types of motion that are considered safe (good), risky (‘it depends’), and non-compliant (bad).
• Safe Motion:
  • Motion under 5 seconds, of the following types:
    • Show/Hide
    • Glowing
    • Color Transitions
    • Slides
    • Scaling
    • Fading
    • Glyph Transformations
• Risky motion
  • Any motion longer than 5 seconds
  • Background Parallax
  • Object Parallax
  • Bouncing Effects
  • Fast Effects
  • Image Masking on Scroll
  • Full Width Mask on Scroll
  • Zoom on Scroll
  • Scale on Scroll
• Non-compliant motion
  • Any motion longer than 5 seconds without a pause button
  • Strobe Effects
  • Rotate on Scroll
  • Fast exit on Scroll
  • Horizontal Directional Scrolling

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:

Emojis and accessibility: How to use them properly

• Ryan Tan shares some tips for accessible emoji usage, mostly in terms of screen reader support, and covering a mixture of ‘design tips’ vs ‘everyday content’:
  • Design: on buttons, don’t use emojis to replace words. E.g. use “Like” rather than “👍”, which could be ambiguous.
  • Don’t use repeated emojis, e.g. “Flight plans ✈️✈️✈️” as each emoji has alt text read out by a screen reader, and this is unnecessarily noisy.
  • Put your text / call to action first, then emoji, i.e. “Let’s go 👊” vs “👊 Let’s go”.
  • Put your emoji at the end of the sentence, not mid-sentence.
  • Use widely-known emojis to cater for as many users as possible, e.g. “Hello 👋” vs “Hello 🖖”.
  • Avoid emoticons, i.e. :) vs 🙂. Some emoticons are particularly difficult to understand as a screen reader user, e.g. the ‘shrug’ emoticon ¯_(ツ)_/¯.
  • Controversially, Ryan suggests you “avoid dark or light skin colour in emoji use” and use the ‘default’ yellow for emojis that have a high contrast on both light and dark backgrounds. There’s a linked article in one of the comments that goes into this topic further, suggesting using emojis that don’t communicate race or gender at all, such as “😸”, or to always use the full range of skin tones such as “✋🏿✋🏾✋🏽✋🏼✋🏻”.

Our development approach for accessible front-end code

• This guide by the BBC walks through their approach for implementing front-end changes, e.g. implementing a component.
  1. Look at the screen reader UX; ask the UX designer for the required documentation if it is missing. It should cover the focus order, the announced content for screen readers, etc.
  2. Read accessibility acceptance criteria
  3. Write the HTML
  4. Check with supported assistive technology (AT). You should do this before adding CSS, and then again before and after adding JavaScript. They advise against doing all your testing at the end, as this “may be more time consuming to debug”, since you won’t necessarily know which layer caused the bug.
  5. Write automated tests for accessibility
  6. Get it reviewed (code review by engineers, design review by designers)
  7. Hold an accessibility swarm, resolve any bugs, then the component is ready for Test.

Whose nine is it anyway? (Feedback on the WCAG 2.2 working draft)

• This article – which I read mostly for the terrible headline – was written by TPGi, an “accessibility solutions provider”, working with a consortium of big names in a11y. TPGi feel that the 9 new Success Criteria recently proposed for WCAG 2.2 all need some clarification and improvement (with the exception of 2.5.7 Dragging Movements, which TPGi are pleased with).
• It’s a long article of recommendations, each linking to separate GitHub issues raised by TPGi. But to take an example, some feedback for “3.3.7 Accessible Authentication” includes ensuring copy-paste is not blocked: “The “Intent” section of the non-normative Understanding document mentions that copy-paste must not be blocked, but this is not in the text of the SC. We feel it would need to be in order to ensure that it’s a requirement.”.
• It’s fascinating to watch the community shape the WCAG standards of the future, and inspiring that any one of us has the power to propose improvements.

This individual shows how he lives his everyday life as a blind person

• A colleague shared this in our work Slack. Anthony S. Ferraro (asfvsion) demonstrates how he completes everyday tasks as a blind person. He covers the very basics (how to pour a cup of water; by keeping one finger over the rim of the cup and stopping pouring when he feels liquid), to the extreme (how to skateboard on a half-pipe; by mapping out the area with his cane and then basically going for it). He shows just how important tactile controls / labels are on products, e.g. the oven and washing machine, which would be extremely difficult to use otherwise.

TikTok Adds New Accessibility Overview To Provide Additional Support for Users

• TikTok adds photosensitivity warnings to its videos, and allows viewers to opt out of viewing them. It’s also educational; warning labels are shown to creators on the specific effects that may trigger photosensitive epilepsy.
• TikTok also offers auto captions and text-to-speech tools, and the ability to switch between animated and static thumbnails.
• These features are described on TikTok’s Accessibility Overview page, which serve as a handy reference point.
• Anecdotally, TikTok is often seen as very accessible compared to other social media platforms, so it’s always worth noting the improvements they’re making in this area.

Overview of accessibility testing using DevTools (Microsoft)

• A guide by the Microsoft Edge DevTools team, though almost all of it applies to any modern browser.
• This mammoth article is a 23 minute read, and covers how to use DevTools for automated accessibility testing, by working through the accessibility ‘warnings’ in the console. It then describes how you should manually test your page by:
  • Resizing the viewport to simulate a zoomed in or mobile device.
  • Attempt to interact with the page with a keyboard, and keep an eye out for focus styles.
  • Inspecting the Accessibility Tree to check for elements with a “generic” role (usually attributed to being encoded as a div or span rather than a button), which won’t be available to users of assistive technology.
  • Simulating hover/focus states on interactable elements and checking their contrast.
  • Testing with dark and light themes.
  • Emulating vision deficiencies with things like blur filters.
  • Verifying that the page respects the prefers-reduced-motion media query.
• It’s worth at least a skim through – chances are you’ll learn something!

fingerspelling.xyz

• This is a website that gamifies teaching you sign language. It uses your webcam to recognise sign language hand gestures, and works extremely well! You gradually progress through different levels of difficulty, eventually covering the entire alphabet.
• The game is an initiative by digital creative studio Hello Monday and the American Society for Deaf Children.

Why your brain loves closed captioning

• 18% of the UK population regularly uses closed captioning, of which only 1 in 5 actually have hearing difficulties. Why?
• The article cites lots of reasons, such as helping with learning a new language. It can also be useful for people with autism and ADHD by providing “deeper context clues”. It also covers situational impairments, such as when sirens or other noises from outside drown out the sound of the movie. And of course, captions allow you to catch up on content on your phone, without disturbing the person next to you.
• “We can read faster than we can speak,” says Dr. Stephen Christman, a cognitive psychologist and professor of psychology at The University of Toledo. “With closed captioning on, the viewer can quickly read the current dialogue and then turn their attention back to the visual action and use their knowledge of what is being said — and what is about to be said — to enhance their appreciation of the nonverbal/visual aspects of what is happening on the screen.”
• The article cites some downsides, however: “It can really wreck a great punchline or suspenseful twist, making it ill-suited to anything that relies on surprise. It can be irritating when it’s poorly executed and riddled with errors.”

Accessibility Advocates Sign Open Letter Urging People Not To Use AccesiBe and Other Overlay Products

• Over 400 accessibility advocates and developers have signed an open letter calling on the industry to avoid using controversial “accessibility overlay products”, the most famous of which is accessiBe. These ‘widgets’ you can install on your website often claim to make your site WCAG compliant, by pulling in third party scripts to ‘fix’ problems such as missing alt text.
• The document lists first-hand accounts from people with disabilities struggling to use websites that have implemented overlays.
• It also describes the privacy issues of such overlays, which detect when assistive technology is running on the device, exposing the fact that the end user has a disability, with no option for them to choose whether or not to disclose it themselves.
• The document recommends that people fix the underlying accessibility issues at source, and abandon use of quick fixes such as these, as they are not effective.

Blind Accessibility Tips

• blindaccessibilitytips.com is a resource for visually-impaired people to learn how to use assistive technology. It covers tasks like navigating the web, editing content in Microsoft Word, and using Windows File Explorer. The site is focused on Windows users using JAWS or NVDA. Though still clearly in early development, it’s a nice attempt to consolidate tutorials in one place.

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:

How anyone can make Maps more accessible

• Google relies on its community of Local Guides to update Google Maps information by, for example, inputting whether a restaurant has tables suitable for people who use wheelchairs. These guides share some actionable tips for crowd-sourcing information to benefit everyone, particularly people with disabilities:
  • An accessibility checklist can be useful when writing reviews. For example, having a template covering ramp access, wheelchair-accessible toilets, wheelchair-accessible parking etc, where you just have to provide ‘YES’ or ‘NO’ next to each item.
  • You can indicate accessibility features by answering questions about a business you visited, within the Google Maps app. If you’re the business owner, better yet – add these attributes yourself in your “Business Profile on Search and Maps”.
  • Create and share public lists of accessible places, e.g. accessible restaurants in your neighbourhood.

How to open a budget Accessibility Simulation Lab

• Andreea Vlad shares how the NHS Business Service Authority built its “budget” Accessibility Simulation Lab.
  • Whilst the article was published in May 2021, it’s not clear when the lab was actually put together. By its nature, it is very “hands on”, and Andreea also recommends having a fruit & candy bowl on site to encourage participation, so it certainly hearkens back to pre-Covid times…!
• The lab is a single Chromebook, pre-configured with personas that simulate certain disabilities, alongside a mouse, keyboard and headphones. Someone bought several sets of cheap protective glasses, and then applied masking tape, nail polish and permanent markers to try to simulate visual conditions such as glaucoma, central field loss, and low vision. Finally, there are three very old phones, though no reference is made as to how these are used.
• Andreea suggests that it’s hard to find lab session times that suit everybody; the implication is to let people use the lab in their own time. Try to get structured feedback from people, by asking them “I think we should…”, “I think we should not…”, and “[x]… stops me from caring about accessibility”. This encourages visitors to reflact, and increases their buy-in.

7 Accessibility FAQ on the Winn-Dixie ADA Appeal Decision (2021)

• I like to keep an eye on accessibility legislation in the USA, even when it can feel quite far removed from the UK/EU legal system. Here’s a useful write-up of one of the most important web accessibility cases in recent history:
• In April 2021, a single U.S. Court of Appeals ruled that the Americans with Disabilities Act (ADA) did not apply to the website of supermarket Winn-Dixie, because at the time of filing it did not sell anything online and the plaintiff could access physical stores. In other words, the ADA could not be used to force Winn-Dixie to make their website accessible to blind users.
• 3 judges were on the panel, and they were split 2-1 on the ruling. The decision only applies in 3 states: Alabama, Florida and Georgia. There have been 3 formal requests for a rehearing since the ruling was made, so a rehearing is quite possible and the ruling could change.
• Since the case was filed, Winn-Dixie does now offer online shopping, which would likely have changed the ruling, were it not for court rules stopping new facts from being added to the case on appeal.

Resident Evil Village Has An Accessibility Problem

• I’ve had a number of bookmarks on the theme of Resident Evil Village, which has been a hot topic in a11y newsletters of late. This article berates Capcom for not providing any accessibility options in the menu of the game, meaning that:
  • The camera is stuck on a zoomed in view, which can lead to motion sickness. There are mods available to configure this.
  • Subtitles are small, and often have terrible contrast on the game background. There’s a Twitter thread with a screenshot. Subtitles don’t specify who is speaking, leaving hard of hearing players to guess. There’s also a lack of subtitles overall, as none of the ambient sounds are conveyed in text.
  • There are no controller remapping options.
  • Can I Play That wrote an accessibility-focused review of Resident Evil Village, rating it just 3/10.
• This article makes a special call-out to Ratchet & Clank: Rift Apart for its advanced a11y options.

Accessibility and outdoor socialising: ‘I feel unwelcome in my own city’

• A BBC article from mid May. As the UK gradually opens up and people are able to dine outside, this must not happen at the expense of wheelchair users. Restaurants are filling pavements and roads with tables for customers, leaving very little (if any) room for wheelchair users to get past.
• Some wheelchair users are reporting that they can’t use their old bus routes, as the roads to get to the bus stop are “covered with tables and chairs”. They now face arriving 20-30 minutes late, or many hours early.
• The article references Katie Penick’s videos on Twitter, demonstrating how difficult it is for her to get through the available gaps in public spaces. This is despite the fact that hers is a 23-inches-wide ‘teenagers’ wheelchair, so smaller than most.
• Holly Greader reflects: “I think the hope was that lockdown had given people an insight into what it can be like for disabled people – the isolation and everything else. I feel like now we’re coming out of the restrictions, we’re forgetting all these things that we’ve learned, and there is a lack of understanding.”

DWP Accessibility Manual

• The Department for Work and Pensions’ Digital team has written an Accessibility Manual, off the back of some user research the department conducted. The accompanying blog post by Head of Accessibility Craig Abbott describe how they hope it will consolidate key information in one place. It is open source and accepting contributions.
• The website has sections describing the different accessibility laws and public sector regulations, and has accessibility guidance broken down by role (e.g. Delivery Manager), as well as a section on best practices concerning common objectives like automated testing.

WebAIM Screen Reader User Survey #9

• One of the most important surveys on the web is back, with a close date of June 15th. The survey is aimed at all screen reader users, including those who just use screen readers for evaluation and testing.
• The last survey of this kind was in September 2019: Screen Reader User Survey #8. It received 1224 responses – it would be great to get this number higher this year.

The perfect link

• Rian Rietveld tackles all the common questions around links:
  • It is usually better to stick with the browser default behaviour, i.e. don’t open links in new tabs/windows. However, it’s OK to do so if you make it clear (“Opens in new window” in the text of the link).
  • Link text should be meaningful and understandable on its own. “Click here” is about the worst link text there is. Proper link text is much easier to scan.
  • For emails, use mailto:someone@example.com as your href. For telephone numbers, use tel:+31108429259; these will open emails in email clients and make phone calls respectively. For the link text, it’s a good idea to repeat the email and phone numbers, rather than using “email” and “call us”.
  • For linking to files such as PDFs, but the filetype and size in brackets, e.g. “Web Accessibility Principles (PDF, 327 Kb)”.
  • When embedding images in a link, use alt text that makes sense as link text, e.g. “Wikipedia page on cherry blossoms” rather than “A cherry tree in full bloom”, as the image alt text will get read out by screen readers as part of the link.
  • Links in the body should generally be underlined – relying on colour difference alone isn’t distinguishable for colour-blind or visually impaired users. Links in navigation need not be underlined, as these are more obviously links.
  • As always, ensure your links have hover and focus styles. Rian recommends not removing the browser’s default outline.
  • For internal links, your href attribute should point to an ID – not to another link with a name attribute, which has been obsolete since HTML5.

We need to talk about WCAG

• This article is written by Rian Rietveld (my second article in a row by this author, by pure coincidence!)
• 97.4% of home pages have detectable WCAG 2 failures. Rian concludes that this is a failure in the way we communicate and teach WCAG, which she thinks is partly down to the information architecture of the WCAG docs. When arriving at a W3C page from a search engine, it can be hard to know if a document is a draft, if it is outdated, and whether it is WCAG 2.0 or 2.1. A lot of old W3C content is indexed by search engines, and sometimes it is the old page that is the one at the top of the search results.
• Rian describes a real world example; searching for “title attribute WCAG”, clicking on the first result, and copying the code example results in code that is bad practice, though not technically a WCAG violation as it is a “Technique” rather than a “Success Criterion”. Rian expects many developers won’t know the difference between the two.
• Some new Success Criteria will be added in WCAG 2.2; Rian suggests this is counterproductive while so many existing Success Criteria are ignored. She has raised a GitHub issue, and invites you to add a comment.
• Rian proposes:
  • Adding a message to the top of every out-of-date page saying that it has been superseded, and link to the latest page. Add noindex to these pages to prevent search engines from continuing to index them.
  • Consolidate content about Techniques, Success Criteria and Understanding, so that each topic only has one page. Use the WAI website for education and tutorials.

Testing fonts for accessibility

• Colin Shanley shares the 3 things to bear in mind when choosing a font:
  • Imposters: specific letter shapes that look similar to other shapes can be difficult or impossible to differentiate. For example, lowercase L, uppercase i and the number 1. The image below shows Gill Sans on the left (bad) vs Assistant on the right (good):
  • 
  • Mirroring: letter pairs (such as lowercase P and Q) should never be the mirror image of one another, as some people flip letters back to front in the brain shape translation process. The image below shows Helvetica on the left (bad) vs Raleway on the right (good):
  • 
  • Discernibility: looking at the apertures of shapes (the openings, e.g. the right-hand gap at the opening of the letter “c”), are they close enough that they could be confused with another letter (e.g. “o”)? The image below shows Public Sans on the left (bad) vs Commissioner on the right (good):
  • 
• There is also WCAG SC 1.4.12 to consider. When a user overrides any of the following style properties, your page text should not disappear or overlap other page content:
  • Line height (leading) to at least 1.5x the font size;
  • Spacing following paragraphs to at least 2x the font size;
  • Letter spacing (tracking) to at least 0.12x the font size;
  • Word spacing to at least 0.16x times the font size.

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.