06 Jan

dai11y 06/01/2021

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

WordPress adds support for video captions and subtitles

  • WordPress v5.6 “Simone” introduces WebVTT support for its videos. This is a big deal considering WordPress powers around 4 out of 10 websites. It means you can upload .vtt files containing subtitles, to enable closed captions on the video. The article gives a nice example of a VTT file, which is just text formatted in a particular way.
  • Many WordPress hosting providers aren’t actually well suited for streaming videos, so the author Jon Henshaw recommends uploading the video itself to a CDN, even if you self-host the VTT file.

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.

05 Jan

Point custom Netlify subdomain to S3 via CloudFront

I work on a hobby site, https://peepshowquot.es, which lets you search for your favourite quotes (in gif form) from Peep Show. Check it out!

I use Netlify for hosting the site, as it’s free, fast, and has great CLI tooling and GitHub integrations. But I use AWS S3 for hosting the gifs, as there are many gigabytes of them and they don’t need regular re-deployment.

I wanted to have these gifs available on the subdomain https://images.peepshowquot.es, rather than expose an obscure bucket URL in my application. It took a bit of wrangling – so here’s how I did it.

Create an S3 bucket

I already had an S3 bucket, but it needed to have the same name as the intended subdomain*. So I created one called images.peepshowquot.es and re-uploaded all my gifs into that. I also made it Public and readable by the world, though I can tighten up this security later.

* It’s possible this isn’t needed if you’re going down the CloudFront route – I originally just planned to point my subdomain to the S3 bucket directly, and this is a restriction I’d run into. But for SSL to work, I had to use CloudFront, which sits between my DNS and my S3 bucket, so possibly isn’t opinionated about the name of the bucket. Let me know in the comments if it wasn’t needed!

Create a certificate

Use AWS’ Certificate Manager to create your SSL certificate – you’ll need this to be able to connect via HTTPS. There’s some talk on the internet about this costing $600 per month, which gave me a heart attack, but that’s actually for private SSL certificates. All we need is a (free) public one.

Note that you MUST set your region to US East (N. Virginia) first, or you won’t be able to link it to your CloudFront distribution.

I used DNS for validation, taking the random code it gave me and appending .images to it, as my DNS provider would automatically append .peepshowquot.es to the end of that. So the Name ended up being _some-random-string.images.peepshowquot.es, and the Value was _some-other-random-string.jfrzftwwjs.acm-validations.aws. (note that there is a . at the end of the value – this may or may not be important so I made sure I kept it in).

It didn’t take long for the SSL certificate to go from Pending to Issued.

Create a CloudFront distribution

Go to CloudFront and create a new distribution, using mostly the default settings, but obviously selecting your S3 bucket for the Origin Settings, and your custom SSL certificate in the SSL section.

I also switched away from a couple of the defaults where it seemed to make sense, e.g. allow ‘Compress Objects Automatically’ (reduces data sent over the wire, which is what you’re charged for, so why wouldn’t you?) and ‘Use only U.S., Canada and Europe’ for Price Class (I don’t expect much traffic outside these countries).

Check it works

I visited https://my-random-distribution-ID.cloudfront.net/s1/e1/gifs/1.gif and verified that a) it connected over HTTPS and b) I was looking at a gif. 🎉

Now all that was left was to hook it up to a custom domain.

Point domain to CloudFront

This was surprisingly simple in the end – create a CNAME record with Name images.peepshowquot.es and Value my-random-distribution-ID.cloudfront.net. After waiting a few moments, I loaded up https://images.peepshowquot.es/s1/e1/gifs/1.gif successfully.

05 Jan

dai11y 05/01/2021

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

State-Switch Controls: The Infamous Case of the “Mute” Button

  • An article exploring the design of ‘mute’ buttons on the iPhone ‘call’ screen, on Zoom, and on WebEx. Two of the three use fill colour alone to denote state: the universal microphone icon has a dash through it, regardless of what state you’re in, making it difficult to know whether your microphone is currently muted. Zoom is the one that gets it right, as it removes the dash from the microphone when your mic is active, and has a label on the button to indicate what will happen when you press it.
  • Aside: I still struggle with Zoom’s implementation, and have yet to find one that doesn’t confuse! Perhaps the best I’ve seen is Google Hangouts’ version, but that could just be down to familiarity as I use it every day.

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.

04 Jan

week11y issue 57

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

Lists

  • A Jeremy Keith entry from his journal. Lists are helpfully announced to screen readers when they are navigated to (e.g. “List: six items”). However, Webkit browsers such as Safari don’t announce lists if the lists’ bullets have been removed using CSS (just like it doesn’t announce content that has been visually hidden with display: none). There’s a Twitter thread explaining why, but it boils down to this: “If a sighted user doesn’t need to know it’s a list, why would a screen reader user?”
  • If you’ve removed bullets but your content is a list (you may have used some visual replacement for bullets, e.g. image markers), you can force screen readers to treat your content as a list by adding role="list".
  • There’s an interesting point about “pixel perfection” across browsers, too. It’s widely considered to be an unattainable or undesirable goal nowadays; why should we demand the aural equivalent? Websites don’t need to sound identical in every screen reader.

VoiceOver Preview for macOS Firefox

  • Mozilla have worked hard over the past year to deliver VoiceOver support for Firefox on macOS – something that had been lacking for 15 years. It’s now ready to try in the Firefox 85 Beta and Mozilla are calling on volunteers to try it out and report any bugs they encounter. Other than a few known issues, it is hoped to be fairly stable.

Equal Entry Guidelines for Describing 360-Degree Video

  • An interesting set of guidelines describing the challenges of audio-describing a 360 degree video (which will become more prevalent as VR grows). You should divide the video into scenes, write a brief introductory description for each scene, then write audio descriptions for each direction a viewer could face during the scene. Consider ‘forward’, ‘left’, ‘right’, ‘backward’, ‘up’ and ‘down’ views. See the demo on YouTube.

Finally, below I summarise not one, not two, but three articles. It’s my attempt to clarify what seems quite a contradictory issue: whether you should ‘try on’ a disability to build empathy, and/or build better products and services. As someone who has written a series of articles on using the web under various constraints, it’s a subject close to my heart and an important conversation to have.

Article 1: Why I won’t “try on” disability to build empathy in the design process (and you should think twice about it.)

  • Amelia Abreu describes how accessibility workshops that, for example, have able-bodied participants trying to navigate a high street with wheelchairs to gain awareness of shortage of ramps, can be counter-productive. A research paper concluded that short-term mimicking of the effects of a disability can a) result in fear, apprehension and pity, b) fail to account for diverse coping mechanisms people develop over time, and therefore, c) cause participants to underestimate the true capabilities of persons with disabilities.
  • Instead, Amelia suggests we build relationships with real people with disabilities. Get to know their diverse interests and accessibility concerns, and ask how you can be an ally for disability rights. Also, to draw upon your own experiences. In the wheelchair example, Amelia developed an awareness of the inaccessibility of infrastructure when she had to take her daughter around in a stroller.

Article 2: Going Colorblind: An Experiment in Empathy and Accessibility

  • This article appeared a month before the first, and on the same website! Sara Novak describes her colleague Peter’s deuteranomalous colour blindness, affecting 5% of men. It means he has a hard time differentiating greens from other colours. Sara admits she was sympathetic, rather than empathetic, so talked to Peter and decided to see what it’s like to be colourblind for three days, using Chrome extension See.
  • Sara realised she’d been colour-coding her responses in emails, and that this was difficult to decipher. She realised why Peter bolded important info in emails rather than rely on colour, and she started to do the same. She also encountered inaccessible web forms which used colour alone to convey error state.

Article 3: Get the Funkify Out: A Neat Accessibility Tool/Disability Simulator

  • Michael Larsen writes about the “Funkify Disability Simulator” Chrome extension, which attempts to simulate what it’s like to browse the web with dyslexia, astigmatism, jittery hands and high distraction (much like GDS’s own accessibility personas). With it, Michael was able to create a custom profile that makes a page look “very much like it would without my reading glasses”.

In conclusion, I’m not convinced I have a definitive answer. These were all useful articles and I learned something from each, but this is still a topic on which I’m uneasy and am keen to keep learning about.

Can I use a screen reader and know exactly what it’s like to be a blind person? No, of course not – there are all manner of lived differences.

Can I use a screen reader to test my product? Yes, of course – without testing, we’ve no hope of finding and fixing accessibility issues.

Can I use a screen reader to build empathy? This is more complex. In Sara’s case, it seems she did build empathy for her colourblind colleague through use of a simulator. Perhaps the key is that she didn’t empathise in isolation; she was engaged with Peter and able to ask questions and compare her simulated world view with his. In contrast, I can see how a first time screen reader user with no point of reference could be overwhelmed and unable to navigate, and in turn develop a misguided view of what a blind person is capable of doing.

These articles were hand-picked from various accessibility newsletters I’m subscribed to. If there are other articles that you recommend, please do send them my way!

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.

04 Jan

dai11y 04/01/2021

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

In a New Year special, I’m summarising not one, not two, but three articles today. It’s my attempt to clarify what seems quite a contradictory issue: whether you should ‘try on’ a disability to build empathy, and/or build better products and services.

As someone who has written a series of articles on using the web under various constraints, it’s a subject close to my heart and an important conversation to have.

Article 1: Why I won’t “try on” disability to build empathy in the design process (and you should think twice about it.)

  • Amelia Abreu describes how accessibility workshops that, for example, have able-bodied participants trying to navigate a high street with wheelchairs to gain awareness of shortage of ramps, can be counter-productive. A research paper concluded that short-term mimicking of the effects of a disability can a) result in fear, apprehension and pity, b) fail to account for diverse coping mechanisms people develop over time, and therefore, c) cause participants to underestimate the true capabilities of persons with disabilities.
  • Instead, Amelia suggests we build relationships with real people with disabilities. Get to know their diverse interests and accessibility concerns, and ask how you can be an ally for disability rights. Also, to draw upon your own experiences. In the wheelchair example, Amelia developed an awareness of the inaccessibility of infrastructure when she had to take her daughter around in a stroller.

Article 2: Going Colorblind: An Experiment in Empathy and Accessibility

  • This article appeared a month before the first, and on the same website! Sara Novak describes her colleague Peter’s deuteranomalous colour blindness, affecting 5% of men. It means he has a hard time differentiating greens from other colours. Sara admits she was sympathetic, rather than empathetic, so talked to Peter and decided to see what it’s like to be colourblind for three days, using Chrome extension See.
  • Sara realised she’d been colour-coding her responses in emails, and that this was difficult to decipher. She realised why Peter bolded important info in emails rather than rely on colour, and she started to do the same. She also encountered inaccessible web forms which used colour alone to convey error state.

Article 3: Get the Funkify Out: A Neat Accessibility Tool/Disability Simulator

  • Michael Larsen writes about the “Funkify Disability Simulator” Chrome extension, which attempts to simulate what it’s like to browse the web with dyslexia, astigmatism, jittery hands and high distraction (much like GDS’s own accessibility personas). With it, Michael was able to create a custom profile that makes a page look “very much like it would without my reading glasses”.

In conclusion, I’m not convinced I have a definitive answer. These were all useful articles and I learned something from each, but this is still a topic on which I’m uneasy and am keen to keep learning about.

Can I use a screen reader and know exactly what it’s like to be a blind person? No, of course not – there are all manner of lived differences.

Can I use a screen reader to test my product? Yes, of course – without testing, we’ve no hope of finding and fixing accessibility issues.

Can I use a screen reader to build empathy? This is more complex. In Sara’s case, it seems she did build empathy for her colourblind colleague through use of a simulator. Perhaps the key is that she didn’t empathise in isolation; she was engaged with Peter and able to ask questions and compare her simulated world view with his. In contrast, I can see how a first time screen reader user with no point of reference could be overwhelmed and unable to navigate, and in turn develop a misguided view of what a blind person is capable of doing.

These articles were hand-picked from various accessibility newsletters I’m subscribed to. If there are other articles that you recommend, please do send them my way!

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.

01 Jan

dai11y 01/01/2021

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

Equal Entry Guidelines for Describing 360-Degree Video

  • An interesting set of guidelines describing the challenges of audio-describing a 360 degree video (which will become more prevalent as VR grows). You should divide the video into scenes, write a brief introductory description for each scene, then write audio descriptions for each direction a viewer could face during the scene. Consider ‘forward’, ‘left’, ‘right’, ‘backward’, ‘up’ and ‘down’ views. See the demo on YouTube.

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.

31 Dec

dai11y 31/12/2020

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

VoiceOver Preview for macOS Firefox

  • Mozilla have worked hard over the past year to deliver VoiceOver support for Firefox on macOS – something that had been lacking for 15 years. It’s now ready to try in the Firefox 85 Beta and Mozilla are calling on volunteers to try it out and report any bugs they encounter. Other than a few known issues, it is hoped to be fairly stable.

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.

30 Dec

dai11y 30/12/2020

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

Lists

  • A Jeremy Keith entry from his journal. Lists are helpfully announced to screen readers when they are navigated to (e.g. “List: six items”). However, Webkit browsers such as Safari don’t announce lists if the lists’ bullets have been removed using CSS (just like it doesn’t announce content that has been visually hidden with display: none). There’s a Twitter thread explaining why, but it boils down to this: “If a sighted user doesn’t need to know it’s a list, why would a screen reader user?”
  • If you’ve removed bullets but your content is a list (you may have used some visual replacement for bullets, e.g. image markers), you can force screen readers to treat your content as a list by adding role="list".
  • There’s an interesting point about “pixel perfection” across browsers, too. It’s widely considered to be an unattainable or undesirable goal nowadays; why should we demand the aural equivalent? Websites don’t need to sound identical in every screen reader.

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.

28 Dec

month11y issue 14

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!

What would an ethical overlay look like?

  • Karl Groves writes about the ‘overlay widgets’ offered by companies such as accessiBe, and how their claim that including their product on your website will make it fully WCAG compliant is simply untrue. Many a11y issues, such as missing alt text, can only be fixed by a person. Moreover, the extra features an overlay often provides (e.g. screen magnification) are poor imitations of what’s already available to the user on their computer. The only ‘ethical’ overlay is a temporary one, Karl says: it should only be used as a discovery tool to find accessibility problems, which you should then spend time fixing the root cause of.

Accessible Game Design / Accessible Player Experiences

  • I came across accessible.games while watching the 2020 Video Game Accessibility Awards. It lists the basic “access design patterns” to follow when developing your games. Examples include “second channel” (such as captioning that alerts you to incoming attacks; not just relying on sound) and “improved precision” (allowing gamers to adjust sensitivity of mouse/controller input). There are also “challenge design patterns”, which are patterns to follow once you’ve got the basics sorted, which go beyond core access into the realm of inclusion, so that people can fully enjoy your game. Examples include “slow it down“, allowing gamers to adjust game speed or reduce enemy damage so that they can successfully progress through the game.

PlayStation 5: The Accessibility Review

Pros:

  • The integrated screen reader is available across the PS5 system and comes in multiple languages, which can be adjusted for speed, volume, and choice of male or female voice.
  • There are a number of global settings to accommodate different types of colour blindness.
  • You can set a ‘game preset’ for game difficulty ranging from Easiest to Hardest, which should map to the standard options in most games. Similarly you can indicate a preference for subtitles, inverted controls, and audio language, which games should obey automatically.
  • There are options to increase text size, and to remap your controller.
  • 3D Audio, alongside supported headsets, give surround sound to the player, enabling blind players to pinpoint with accuracy where enemies are (as well as improving the experience for everybody).
  • The new DualSense controller has a built-in microphone, which can be used for voice-to-text. Haptic feedback in the controllers is designed to immerse the player, but can be disabled if uncomfortable.

Cons:

  • The controller is larger and heavier than before, and the accessible ‘Back Button Attachment’ accessory for the PS4’s controller doesn’t fit on this one.
  • The ‘zoom’ option that allowed screen magnification on the PS4 has not yet been carried over.

Under-Engineered Responsive Tables

  • Adrian Roselli describes how to create an accessible table that scrolls horizontally on mobile. You need to put your <table> element inside a <div role="region" aria-labelledby="mycaption" tabindex="0">, where “mycaption” references the <caption id="mycaption"> that should be inside the table. The tabindex satisfies WCAG Success Criteria 2.1.1 Keyboard, and the aria-labelledby satisfies 4.1.2 Name, Role, Value. For the CSS, apply overflow: auto to the table, and don’t forget to apply a focus style.

Accessibility Testing is like Making Coffee

  • This article by Madalyn Parker was very popular back in August. Madalyn describes accessibility testing through different coffee brewing methods, with some nice illustrations. French Press is like automated testing: quick, easy, but doesn’t catch all of the grit. Aeropress, like semi-automated testing, is a step up from that, but requires more judgement. Pour Over is like manual testing, requiring the most time and attention but giving the smoothest brew. Going to a Café is like User Testing: you’ll learn things (either how to make coffee in new ways, or how users with disabilities use your site). a11y.coffee is kind of a sister site to this article and is also worth a look.

Survey of Web Accessibility Practitioners #3

  • This WebAIM survey, which was previously conducted in 2014 and 2018, is aimed at “everyone that implements accessibility, whether casually or as a primary part of your job”. It is open until January 20th 2021 and its results will be published in the same month. Please take 5-15 minutes of your day to complete the 36 short questions and help inform the web accessibility field.

Introducing the Accessibility VRCs

Almost 50% Got This #a11y Question Wrong! — WCAG Explained (8m video)

  • Eric Eggert asked Twitter if the following code fails WCAG:
  • <button aria-level="2">Action</button>
  • 49% thought it failed WCAG, but Eric explains why it doesn’t. This all may seem a bit hypothetical, but it’s actually quite a useful exercise in how to judge code against the WCAG criteria.
  • Eric admits the code is invalid ARIA, as buttons can’t have levels (level doesn’t appear on the button role documentation, nor does button appear on the aria-level docs), but that does not constitute a WCAG failure.
  • It doesn’t fail SC 4.1.1 Parsing, as the HTML can still be parsed. SC 4.1.2 Name, Role, Value also passes; it says that “states, properties, values that can be set by the user can be programmatically set”, but as aria-level is unsupported on the button element, it cannot be set by the user.
  • Eric explains a couple more WCAG criteria that people cited, and why they don’t apply. Worth a watch.

My watch told me I have a leak

  • An AbilityNet article describes how Google’s Live Transcribe app, which turns speech into text for live conversations, can also be trained with non-voice data. An update to the app can now identify environmental sounds such as “crying baby”, “door knocking”, “smoke alarm”, or as the title suggests, “running water”. The app can vibrate or flash for these noises, and Google announced in October 2020 that it will soon be able to notify your Android watch (Wear OS), though the ‘listening’ will still be done through a nearby phone. The next step will be to bring environmental noise detection natively to any devices that contain a microphone.

A plan for accessible maps

  • Benjy Stanton describes how he would design a map service from the ground up, considering the needs of all users. Maps are inherently inaccessible – they require digital and geographic literacy as well as visual methods of communication, so they should always be seen as an enhancement. Benjy’s tips can be largely summed up as follows:
  • The core content should be available outside of the map, e.g. as a data table or downloadable spreadsheet. Design your map in black and white first, to help prevent you relying on colour alone to convey meaning. Avoid pan & zoom interactivity unless they’re required. Ensure all interactive features (rivers, roads etc) are high contrast enough to see. Turn off background layers you don’t need. Test the map works on mobile and with a keyboard.

Here’s What It’s Like To Live With A Tracheostomy

  • Ginny Butcher describes her experience of living with a tracheostomy (or ‘trache’): a tube in her neck, connected to a ventilator to enable her to breathe.
  • She’s completed a master’s degree to become a lawyer, and has done many impressive things such as rock climbing, abseiling, canoeing and zip lining, all with a ventilator strapped to her body. She’s also flown a plane and completed a half-marathon.
  • The practical aspects are that she needs to carry three bags of machines and some spare batteries at all times. One of the machines is to assist with coughing and secretions. The tube needs changing daily, which Ginny likens to something as boring as “clipping your toenails”.
  • It has its upsides too – Ginny doesn’t breathe through her nose or mouth, which makes her “the absolute best at downing pints”. Worth a read!

Accessible Web Animation: The WCAG on Animation Explained

  • Val Head gives a detailed overview of WCAG animation recommendations. These include:
    • “Pause, Stop, Hide“: provide a way of pausing, stopping or hiding any autoplaying animation that lasts more than 5 seconds.
    • “Three flashes or below threshold“: avoid flashing more than 3 times in a one second period, to reduce chances of triggering seizures.
    • “Animation from interactions“: any animation triggered by the user, which gives the illusion of motion (so not including things like colour or opacity change) should have an option to be disabled, as they can cause people with motion sensitivities to become ill. You can implement this with a ‘toggle’ on your site, and also pay attention to the prefers-reduced-motion media query.
  • These recommendations come under different WCAG conformance levels. for example, the first two rules are level A rules – the bare minimum standard to be met. The “animation from interactions” rule is AAA, which is the highest level of conformance. In general most people aim for the middle level: AA compliance.

More Accessible Skeletons

  • Adrian Roselli describes – quite late on in his blog post – why he thinks skeletons (placeholder areas to display to the user while content is loading) are a bad idea. But he also describes how he would build one if he had to.
  • Some skeletons have aria-busy="true" markup, which is designed to be temporarily ignored by screen readers, though few screen readers support it. Adrian recommends pairing it with aria-hidden="true" for now at least. In practice, this means having two sibling nodes; one for the skeleton and one of the content.
    • When your content is loading, it should be hidden and have aria-busy="true", and the skeleton node should be visible. When it has loaded, it should be flipped to aria-busy="false" and the skeleton node should be set to aria-hidden="true".
    • You should have CSS which sets display: none on aria-hidden content, and on aria-busy="true" content.

How we made GOV.UK more accessible

  • A team on GOV.UK analysed a small subset of representative pages to identify any violations of the WCAG 2.1 AA standard. They prioritised each issue by its regularity / likelihood of occurrence and its impact on the user’s ability to use GOV.UK. These were either technical issues, content issues or a mixture. They could generally be fixed in one central place (the Design System or components) or by an improvement in the guidance. There’s a great video on how differently marked up tables are experienced by screen readers.

iPhones can now automatically recognize and label buttons and UI features for blind users

  • iOS 14 has a new feature, “Screen Recognition”, which is built into VoiceOver. It uses AI to detect interactable elements on the screen, even when such elements aren’t properly labelled / exposed to assistive technology. It has the potential to allow blind users to use apps that are otherwise inaccessible.
  • I highly recommend this GadgetHacks article which goes into more detail on the feature and includes screenshots demonstrating how to enable it.
  • I haven’t had a chance to try out the feature myself yet, but it looks as though you first enable the feature, then ‘opt in’ to the feature on individual apps. I don’t yet know whether that means it would work on browsers such as Safari and Chrome. If it does, this could be a game changer, as it might allow the user to navigate previously inaccessible websites.

Are your Anchor Links Accessible?

  • Amber Wilson describes the HTML structure she came up with for turning headings into ‘linkable headings’, whose links can be used as anchor links to that specific part of the page. It can be tricky to implement these without making it a noisy or confusing experience for screen reader users. Here is the markup she ended up with:
  • <h2 id="introduction">Introduction</h2><a href="#introduction"><span aria-hidden="true">#</span><span class="hidden">Section titled introduction</span></a>
  • You could also wrap your link inside your heading, which is simpler but arguably has usability issues (e.g. makes it harder to select heading text):
  • <h2 id="introduction"><a href="#introduction">Introduction</a></h2>

A placeholder is not a label

  • This is your regular reminder from HTMHell that <input type="text" placeholder="First name"> is not accessible and requires an associated <label>. Some screen readers will fall back to using the placeholder if a label is missing, but it can’t be relied upon.
  • There are various UI issues with a placeholder-only approach. Contrast is often too low to read the text easily (though this can be tweaked by styling with the ::placeholder rule, at the risk of making the user think the input is already filled in). Placeholders get cut off if the input is too small, and get removed as soon as you start typing, straining your short term memory.

Alexa Makes Shopping Lists Sharable as Accessibility Feature

  • Alexa allows you to create lists such as shopping lists and todo lists, adding and removing items with your voice. And now, users can ask Alexa to send a given list to a specific contact. Once Alexa confirms it has identified the right person, the recipient gets a message on their Alexa account through the app. This feature is designed to help those with limited access to a grocery store connect with those who can help get them supplies in the ongoing COVID-19 situation.

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.

28 Dec

fortnight11y issue 28

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

A plan for accessible maps

  • Benjy Stanton describes how he would design a map service from the ground up, considering the needs of all users. Maps are inherently inaccessible – they require digital and geographic literacy as well as visual methods of communication, so they should always be seen as an enhancement. Benjy’s tips can be largely summed up as follows:
  • The core content should be available outside of the map, e.g. as a data table or downloadable spreadsheet. Design your map in black and white first, to help prevent you relying on colour alone to convey meaning. Avoid pan & zoom interactivity unless they’re required. Ensure all interactive features (rivers, roads etc) are high contrast enough to see. Turn off background layers you don’t need. Test the map works on mobile and with a keyboard.

Here’s What It’s Like To Live With A Tracheostomy

  • Ginny Butcher describes her experience of living with a tracheostomy (or ‘trache’): a tube in her neck, connected to a ventilator to enable her to breathe.
  • She’s completed a master’s degree to become a lawyer, and has done many impressive things such as rock climbing, abseiling, canoeing and zip lining, all with a ventilator strapped to her body. She’s also flown a plane and completed a half-marathon.
  • The practical aspects are that she needs to carry three bags of machines and some spare batteries at all times. One of the machines is to assist with coughing and secretions. The tube needs changing daily, which Ginny likens to something as boring as “clipping your toenails”.
  • It has its upsides too – Ginny doesn’t breathe through her nose or mouth, which makes her “the absolute best at downing pints”. Worth a read!

Accessible Web Animation: The WCAG on Animation Explained

  • Val Head gives a detailed overview of WCAG animation recommendations. These include:
    • “Pause, Stop, Hide“: provide a way of pausing, stopping or hiding any autoplaying animation that lasts more than 5 seconds.
    • “Three flashes or below threshold“: avoid flashing more than 3 times in a one second period, to reduce chances of triggering seizures.
    • “Animation from interactions“: any animation triggered by the user, which gives the illusion of motion (so not including things like colour or opacity change) should have an option to be disabled, as they can cause people with motion sensitivities to become ill. You can implement this with a ‘toggle’ on your site, and also pay attention to the prefers-reduced-motion media query.
  • These recommendations come under different WCAG conformance levels. for example, the first two rules are level A rules – the bare minimum standard to be met. The “animation from interactions” rule is AAA, which is the highest level of conformance. In general most people aim for the middle level: AA compliance.

More Accessible Skeletons

  • Adrian Roselli describes – quite late on in his blog post – why he thinks skeletons (placeholder areas to display to the user while content is loading) are a bad idea. But he also describes how he would build one if he had to.
  • Some skeletons have aria-busy="true" markup, which is designed to be temporarily ignored by screen readers, though few screen readers support it. Adrian recommends pairing it with aria-hidden="true" for now at least. In practice, this means having two sibling nodes; one for the skeleton and one of the content.
    • When your content is loading, it should be hidden and have aria-busy="true", and the skeleton node should be visible. When it has loaded, it should be flipped to aria-busy="false" and the skeleton node should be set to aria-hidden="true".
    • You should have CSS which sets display: none on aria-hidden content, and on aria-busy="true" content.

How we made GOV.UK more accessible

  • A team on GOV.UK analysed a small subset of representative pages to identify any violations of the WCAG 2.1 AA standard. They prioritised each issue by its regularity / likelihood of occurrence and its impact on the user’s ability to use GOV.UK. These were either technical issues, content issues or a mixture. They could generally be fixed in one central place (the Design System or components) or by an improvement in the guidance. There’s a great video on how differently marked up tables are experienced by screen readers.

iPhones can now automatically recognize and label buttons and UI features for blind users

  • iOS 14 has a new feature, “Screen Recognition”, which is built into VoiceOver. It uses AI to detect interactable elements on the screen, even when such elements aren’t properly labelled / exposed to assistive technology. It has the potential to allow blind users to use apps that are otherwise inaccessible.
  • I highly recommend this GadgetHacks article which goes into more detail on the feature and includes screenshots demonstrating how to enable it.
  • I haven’t had a chance to try out the feature myself yet, but it looks as though you first enable the feature, then ‘opt in’ to the feature on individual apps. I don’t yet know whether that means it would work on browsers such as Safari and Chrome. If it does, this could be a game changer, as it might allow the user to navigate previously inaccessible websites.

Are your Anchor Links Accessible?

  • Amber Wilson describes the HTML structure she came up with for turning headings into ‘linkable headings’, whose links can be used as anchor links to that specific part of the page. It can be tricky to implement these without making it a noisy or confusing experience for screen reader users. Here is the markup she ended up with:
  • <h2 id="introduction">Introduction</h2><a href="#introduction"><span aria-hidden="true">#</span><span class="hidden">Section titled introduction</span></a>
  • You could also wrap your link inside your heading, which is simpler but arguably has usability issues (e.g. makes it harder to select heading text):
  • <h2 id="introduction"><a href="#introduction">Introduction</a></h2>

A placeholder is not a label

  • This is your regular reminder from HTMHell that <input type="text" placeholder="First name"> is not accessible and requires an associated <label>. Some screen readers will fall back to using the placeholder if a label is missing, but it can’t be relied upon.
  • There are various UI issues with a placeholder-only approach. Contrast is often too low to read the text easily (though this can be tweaked by styling with the ::placeholder rule, at the risk of making the user think the input is already filled in). Placeholders get cut off if the input is too small, and get removed as soon as you start typing, straining your short term memory.

Alexa Makes Shopping Lists Sharable as Accessibility Feature

  • Alexa allows you to create lists such as shopping lists and todo lists, adding and removing items with your voice. And now, users can ask Alexa to send a given list to a specific contact. Once Alexa confirms it has identified the right person, the recipient gets a message on their Alexa account through the app. This feature is designed to help those with limited access to a grocery store connect with those who can help get them supplies in the ongoing COVID-19 situation.

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