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.