Category: week11y

Accessibility themed newsletter released every week.

  • week11y issue 97

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

    Accessibility inception: sharing your knowledge (video, 46m)

    • This is a Mischa Andrews talk from #ID24 in November 2017. I’ve had it in my bookmarks for a while, and am so pleased I’ve finally managed to watch it.
    • Mischa talks openly and candidly about how you can effect accessibility change in your organisation, whilst overcoming the inevitable office politics that come with the territory.
    • I liked the idea of creating a “decoy audience”. Let’s say you have a colleague who feels they have nothing to learn about accessibility – they “know it all already” – but they consistently make accessibility mistakes. You can teach them how to do things properly, without bruising their ego, by arranging a talk or workshop about accessibility, and inviting them to present part of it. The theory is that they can continue to feel good about their own knowledge, whilst also opening up to learning from your side of the talk.
    • A common tactic used by organisations is to have a ‘gatekeeper’ for accessibility, e.g. someone doing accessibility testing as part of the acceptance tests at the end of a project. Mischa warns that you have to tread carefully here, as it’s often too late or difficult to do much about accessibility issues if they’re left until the end of the process. You may also find people try to work around you, such as go to your manager or try to argue that their project shouldn’t go through the normal process. It is best to only use this ‘gatekeeper’ tactic if your organisation is already practising good accessibility.
    • Make it as easy as possible to do the right thing, e.g. by adding accessibility information directly as code comments, or embedded in Word templates, rather than expecting people to seek out and find the guidance independently.
    • Practice what you preach. You may be seen as the a11y expert in the organisation, and people will reuse your resources, such as colour choices, etc, on the assumption that they’ve already been accessibility tested.
    • It is useful to memorise a handful of things that can be used as opportunities to motivate people – and to convince people to listen to you. If you know statistics around how many people have particular kinds of disabilities, or how much money the organisation loses through being inaccessible, or what accessibility laws your country has to abide by, or the difference between different versions of WCAG, you’ll look knowledgeable enough for your words to carry more weight. You can also slip these facts into conversations, which can help to inspire the next generation of accessibility advocates in your organisation.

    Next is a two-article special, covering accessibility advances by Android and Apple!

    Google Improving Smartphone Accessibility

    • Two new features are coming to Android smartphones: “Camera Switches“, and “Project Activate”. These features will allow users to use gestures like smiling, raising eyebrows, or looking in a particular direction, to issue a command such as returning to the homescreen or opening notifications.
    • The gestures are configurable: users can set how long to hold the gesture for, or how big the gesture must be, to issue the command.
    • “The updates are aimed at people with motor and speech disabilities, Google said, and the new tools were developed with feedback from people who rely on alternative communication technology.”

    Apple is testing AirPods as possible hearing aids, posture improvers and in-ear thermometers

    • Apple is prototyping to see motion sensors inside AirPods can be used to tell users if they’re slouching. They’re also experimenting with measuring core body temperature, and perhaps most excitingly, whether or not AirPods can be used as “proper hearing aids” (they already come with a ‘conversation boost‘ feature).
    • Under US federal law, devices marketed as hearing aids must “be sold through licensed specialists, who adjust them to the specific user”. However, “in July, President Biden signed an executive order directing the Department of Health and Human Services to allow hearing aids to be sold over the counter and be adjusted by consumers”; promising news for Apple.

    Buttons vs. Links

    • Eric Eggert describes the difference between a link and a button:
      • A link changes what the URL in the browser points to; either a new page, or a file to download, or a frame to update the source of.
      • A button performs an action. Originally only available as an <input type="submit" />, with the sole purpose of submitting forms, then along came the <button> element which allowed more versatility. It’s great for creating things like calculators, where the end result URL is not an important thing to be able to share.
    • Links and buttons have different roles. Assistive technologies announce them as “link” and “button” respectively, and this sets a user expectation as to the behaviour.
    • Screen readers have a way of easily presenting all the links in the page; buttons are harder to surface.
    • Links can be activated with the return key, whereas buttons can be activated with return or space.
    • Context is important. You can style a link to look like a button, and that’s fine, if the button says something like “Read the full story”, which hints that it will take you to another page.
    • Eric concludes that the link vs button debate is a grey area. He’s surprisingly unopinionated in the close: “there is no one true way to code or design something”.

    As a bonus for the above article, I also read THE BUTTON CHEAT SHEET (buttoncheatsheet.com). It compares different ways of marking up buttons and button-like things. I don’t really see how useful it can be, but it’s worth a quick look through, if only to see how many different ways it can be done.

    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.

  • week11y issue 96

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

    Image split into two columns. Left column has 'sad face' smiley, right column says 'Coronavirus is a virus that makes some people very ill. People also call it COVID-19.' On the next row, left column has a happy smiley face with little virus icons over it. Right column says 'It is possible to have Covid-19 without knowing.'
    Example screenshot of an “easy read” format.

    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.

  • week11y issue 95

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

    Myths about Web Accessibility

    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:

    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.

    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.

  • week11y issue 94

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

    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.

  • week11y issue 93

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

    Picture of bump labels for keyboard. There's a bumpy red X over the right arrow key.
    Image: Microsoft

    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.

    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.

  • week11y issue 92

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

    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.
    Three radio buttons. One is selected. The selected one has a text input associated with it; hence "conditional reveal".
    Screenshot of the ‘conditional reveal’ behaviour.

    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.

  • week11y issue 91

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

    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.

  • week11y issue 90

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

    This frequent11y issue is 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…

    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.

  • week11y issue 89

    Hello! After a week off work, your weekly frequent11y newsletter returns…

    How to use the Accessibility Checker in Microsoft Office

    Screenshot showing where to click to enable to accessibility checker in Word. Source: thewindowsclub.com
    • 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.”

    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.

  • week11y issue 88

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

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