15 Sep

dai11y 15/09/2021

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

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

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

13 Sep

dai11y 13/09/2021

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

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

10 Sep

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.

10 Sep

dai11y 10/09/2021

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

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

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

09 Sep

dai11y 09/09/2021

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

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.

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

08 Sep

dai11y 08/09/2021

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

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.

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

07 Sep

dai11y 07/09/2021

Hello! After a week off work, your daily 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.

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

27 Aug

month11y issue 22

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

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.

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.

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

27 Aug

fortnight11y issue 44

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.

27 Aug

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.

Loading...