An article by Rhea Althea Guntalilib, describing her experience of using the new “VoiceOver Recognition” features of iOS 14. It is a collection of tools including “Screen Recognition” (which I’ll talk about below), “Text Recognition” (which detects text found in images) and “Image Descriptions” (which describes image contents). These features are accessible via Settings > Accessibility > VoiceOver and can then be quick-selected via the VoiceOver rotor.
I covered Screen Recognition in dai11y 22/12/2020: “It uses AI to detect interactable elements on the screen, even when such elements aren’t properly labelled / exposed to assistive technology. It has the potential to allow blind users to use apps that are otherwise inaccessible.”
Rhea found the Image Descriptions improved her experience of the Facebook and Instagram apps, and also Text Recognition was great at describing her screenshots of captured text messages. Screen Recognition came in handy for her banking apps, which otherwise have no accessible way of transferring funds or paying bills. But she did find she had to turn off Screen Recognition in places, e.g. to properly access the list of available banks, as it would interfere with how VoiceOver worked. Other apps, such as email, had attachments that could not be processed by VoiceOver Recognition.
In summary, whilst it has some glitches and limitations, it has “delivered many improvements in the user experience of a blind iOS customer”.
Think you know SVGs? This article is worth a read – you just might learn something.
SVGs have an implicit WAI-ARIA role of “graphics-document“. You should only change this if the SVG only contains an image; an attribute of role="img" or role="graphics-symbol" would be appropriate.
Hide decorative SVGs from screen readers using aria-hidden="true" – not role="presentation", as this doesn’t hide the contents of the SVG from screen readers.
SVGs can have a <title> attribute which acts like an alt attribute on a normal image. It has to be the first child element within the <svg>. There is also an optional <desc> element which can follow this, and should be used to present more detailed textual information. Browser support for both of these is good but not 100%; aria-label can be added for wider support.
It’s not enough to just use semantic markup to, say, create a list in HTML (the “what”), and mark it up with a role="menu" (the “how it’s supposed to work”). We also often need to label the list, to explain “why” it’s there. For example, an aria-label="Main menu" to give some extra context to screen reader users.
This article describes how and when you should name things in HTML. It covers the basics, such as associating a label with an input, which effectively gives the input a name, but it also covers the stuff that is more easily omitted, such as applying a label to your ARIA regions.
Not every landmark needs a name, but any navigation, form and region should, as well as main (it’s good practice to associate the H1 element with the main content in your page via aria-labelledby). Landmarks that appear once per page, such as banner, should not have a name.
An interesting article, worth reading as it goes against the current narrative that the disabled community have benefited from the move to online tuition. It covers university undergraduates and graduates in America.
“Only 20% of [American] undergraduate students with disabilities reported enjoying online learning, and over one third of students with disabilities reported no increased satisfaction with online learning in general”.
The story changes slightly for graduate students with disabilities, who liked online learning more than those without disabilities, but also felt less productive and more disconnected from professors.
That said, there were some areas where “disabled students did describe a greater satisfaction than non-disabled students”, such as “comfort levels in speaking up in class” and “connection with other students”.
Learning from home rather than university “meant being removed from the protective factor of the university”. Shockingly, only 40% of undergraduate students with multiple disabilities have a “place to live that is free from physical or emotional violence or abuse”.
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.
An interesting article, worth reading as it goes against the current narrative that the disabled community have benefited from the move to online tuition. It covers university undergraduates and graduates in America.
“Only 20% of [American] undergraduate students with disabilities reported enjoying online learning, and over one third of students with disabilities reported no increased satisfaction with online learning in general”.
The story changes slightly for graduate students with disabilities, who liked online learning more than those without disabilities, but also felt less productive and more disconnected from professors.
That said, there were some areas where “disabled students did describe a greater satisfaction than non-disabled students”, such as “comfort levels in speaking up in class” and “connection with other students”.
Learning from home rather than university “meant being removed from the protective factor of the university”. Shockingly, only 40% of undergraduate students with multiple disabilities have a “place to live that is free from physical or emotional violence or abuse”.
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.
It’s not enough to just use semantic markup to, say, create a list in HTML (the “what”), and mark it up with a role="menu" (the “how it’s supposed to work”). We also often need to label the list, to explain “why” it’s there. For example, an aria-label="Main menu" to give some extra context to screen reader users.
This article describes how and when you should name things in HTML. It covers the basics, such as associating a label with an input, which effectively gives the input a name, but it also covers the stuff that is more easily omitted, such as applying a label to your ARIA regions.
Not every landmark needs a name, but any navigation, form and region should, as well as main (it’s good practice to associate the H1 element with the main content in your page via aria-labelledby). Landmarks that appear once per page, such as banner, should not have a name.
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.
Think you know SVGs? This article is worth a read – you just might learn something.
SVGs have an implicit WAI-ARIA role of “graphics-document“. You should only change this if the SVG only contains an image; an attribute of role="img" or role="graphics-symbol" would be appropriate.
Hide decorative SVGs from screen readers using aria-hidden="true" – not role="presentation", as this doesn’t hide the contents of the SVG from screen readers.
SVGs can have a <title> attribute which acts like an alt attribute on a normal image. It has to be the first child element within the <svg>. There is also an optional <desc> element which can follow this, and should be used to present more detailed textual information. Browser support for both of these is good but not 100%; aria-label can be added for wider support.
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.
An article by Rhea Althea Guntalilib, describing her experience of using the new “VoiceOver Recognition” features of iOS 14. It is a collection of tools including “Screen Recognition” (which I’ll talk about below), “Text Recognition” (which detects text found in images) and “Image Descriptions” (which describes image contents). These features are accessible via Settings > Accessibility > VoiceOver and can then be quick-selected via the VoiceOver rotor.
I covered Screen Recognition in dai11y 22/12/2020: “It uses AI to detect interactable elements on the screen, even when such elements aren’t properly labelled / exposed to assistive technology. It has the potential to allow blind users to use apps that are otherwise inaccessible.”
Rhea found the Image Descriptions improved her experience of the Facebook and Instagram apps, and also Text Recognition was great at describing her screenshots of captured text messages. Screen Recognition came in handy for her banking apps, which otherwise have no accessible way of transferring funds or paying bills. But she did find she had to turn off Screen Recognition in places, e.g. to properly access the list of available banks, as it would interfere with how VoiceOver worked. Other apps, such as email, had attachments that could not be processed by VoiceOver Recognition.
In summary, whilst it has some glitches and limitations, it has “delivered many improvements in the user experience of a blind iOS customer”.
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.
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!
Google relies on its community of Local Guides to update Google Maps information by, for example, inputting whether a restaurant has tables suitable for people who use wheelchairs. These guides share some actionable tips for crowd-sourcing information to benefit everyone, particularly people with disabilities:
An accessibility checklist can be useful when writing reviews. For example, having a template covering ramp access, wheelchair-accessible toilets, wheelchair-accessible parking etc, where you just have to provide ‘YES’ or ‘NO’ next to each item.
You can indicate accessibility features by answering questions about a business you visited, within the Google Maps app. If you’re the business owner, better yet – add these attributes yourself in your “Business Profile on Search and Maps”.
Andreea Vlad shares how the NHS Business Service Authority built its “budget” Accessibility Simulation Lab.
Whilst the article was published in May 2021, it’s not clear when the lab was actually put together. By its nature, it is very “hands on”, and Andreea also recommends having a fruit & candy bowl on site to encourage participation, so it certainly hearkens back to pre-Covid times…!
The lab is a single Chromebook, pre-configured with personas that simulate certain disabilities, alongside a mouse, keyboard and headphones. Someone bought several sets of cheap protective glasses, and then applied masking tape, nail polish and permanent markers to try to simulate visual conditions such as glaucoma, central field loss, and low vision. Finally, there are three very old phones, though no reference is made as to how these are used.
Andreea suggests that it’s hard to find lab session times that suit everybody; the implication is to let people use the lab in their own time. Try to get structured feedback from people, by asking them “I think we should…”, “I think we should not…”, and “[x]… stops me from caring about accessibility”. This encourages visitors to reflact, and increases their buy-in.
I like to keep an eye on accessibility legislation in the USA, even when it can feel quite far removed from the UK/EU legal system. Here’s a useful write-up of one of the most important web accessibility cases in recent history:
In April 2021, a single U.S. Court of Appeals ruled that the Americans with Disabilities Act (ADA) did not apply to the website of supermarket Winn-Dixie, because at the time of filing it did not sell anything online and the plaintiff could access physical stores. In other words, the ADA could not be used to force Winn-Dixie to make their website accessible to blind users.
3 judges were on the panel, and they were split 2-1 on the ruling. The decision only applies in 3 states: Alabama, Florida and Georgia. There have been 3 formal requests for a rehearing since the ruling was made, so a rehearing is quite possible and the ruling could change.
Since the case was filed, Winn-Dixie does now offer online shopping, which would likely have changed the ruling, were it not for court rules stopping new facts from being added to the case on appeal.
I’ve had a number of bookmarks on the theme of Resident Evil Village, which has been a hot topic in a11y newsletters of late. This article berates Capcom for not providing any accessibility options in the menu of the game, meaning that:
Subtitles are small, and often have terrible contrast on the game background. There’s a Twitter thread with a screenshot. Subtitles don’t specify who is speaking, leaving hard of hearing players to guess. There’s also a lack of subtitles overall, as none of the ambient sounds are conveyed in text.
A BBC article from mid May. As the UK gradually opens up and people are able to dine outside, this must not happen at the expense of wheelchair users. Restaurants are filling pavements and roads with tables for customers, leaving very little (if any) room for wheelchair users to get past.
Some wheelchair users are reporting that they can’t use their old bus routes, as the roads to get to the bus stop are “covered with tables and chairs”. They now face arriving 20-30 minutes late, or many hours early.
The article references Katie Penick’s videos on Twitter, demonstrating how difficult it is for her to get through the available gaps in public spaces. This is despite the fact that hers is a 23-inches-wide ‘teenagers’ wheelchair, so smaller than most.
Holly Greader reflects: “I think the hope was that lockdown had given people an insight into what it can be like for disabled people – the isolation and everything else. I feel like now we’re coming out of the restrictions, we’re forgetting all these things that we’ve learned, and there is a lack of understanding.”
The Department for Work and Pensions’ Digital team has written an Accessibility Manual, off the back of some user research the department conducted. The accompanying blog post by Head of Accessibility Craig Abbott describe how they hope it will consolidate key information in one place. It is open source and accepting contributions.
One of the most important surveys on the web is back, with a close date of June 15th. The survey is aimed at all screen reader users, including those who just use screen readers for evaluation and testing.
The last survey of this kind was in September 2019: Screen Reader User Survey #8. It received 1224 responses – it would be great to get this number higher this year.
Rian Rietveld tackles all the common questions around links:
It is usually better to stick with the browser default behaviour, i.e. don’t open links in new tabs/windows. However, it’s OK to do so if you make it clear (“Opens in new window” in the text of the link).
Link text should be meaningful and understandable on its own. “Click here” is about the worst link text there is. Proper link text is much easier to scan.
For emails, use mailto:someone@example.com as your href. For telephone numbers, use tel:+31108429259; these will open emails in email clients and make phone calls respectively. For the link text, it’s a good idea to repeat the email and phone numbers, rather than using “email” and “call us”.
For linking to files such as PDFs, but the filetype and size in brackets, e.g. “Web Accessibility Principles (PDF, 327 Kb)”.
When embedding images in a link, use alt text that makes sense as link text, e.g. “Wikipedia page on cherry blossoms” rather than “A cherry tree in full bloom”, as the image alt text will get read out by screen readers as part of the link.
Links in the body should generally be underlined – relying on colour difference alone isn’t distinguishable for colour-blind or visually impaired users. Links in navigation need not be underlined, as these are more obviously links.
As always, ensure your links have hover and focus styles. Rian recommends not removing the browser’s default outline.
For internal links, your href attribute should point to an ID – not to another link with a name attribute, which has been obsolete since HTML5.
This article is written by Rian Rietveld (my second article in a row by this author, by pure coincidence!)
97.4% of home pages have detectable WCAG 2 failures. Rian concludes that this is a failure in the way we communicate and teach WCAG, which she thinks is partly down to the information architecture of the WCAG docs. When arriving at a W3C page from a search engine, it can be hard to know if a document is a draft, if it is outdated, and whether it is WCAG 2.0 or 2.1. A lot of old W3C content is indexed by search engines, and sometimes it is the old page that is the one at the top of the search results.
Rian describes a real world example; searching for “title attribute WCAG”, clicking on the first result, and copying the code example results in code that is bad practice, though not technically a WCAG violation as it is a “Technique” rather than a “Success Criterion”. Rian expects many developers won’t know the difference between the two.
Some new Success Criteria will be added in WCAG 2.2; Rian suggests this is counterproductive while so many existing Success Criteria are ignored. She has raised a GitHub issue, and invites you to add a comment.
Rian proposes:
Adding a message to the top of every out-of-date page saying that it has been superseded, and link to the latest page. Add noindex to these pages to prevent search engines from continuing to index them.
Consolidate content about Techniques, Success Criteria and Understanding, so that each topic only has one page. Use the WAI website for education and tutorials.
Colin Shanley shares the 3 things to bear in mind when choosing a font:
Imposters: specific letter shapes that look similar to other shapes can be difficult or impossible to differentiate. For example, lowercase L, uppercase i and the number 1. The image below shows Gill Sans on the left (bad) vs Assistant on the right (good):
Mirroring: letter pairs (such as lowercase P and Q) should never be the mirror image of one another, as some people flip letters back to front in the brain shape translation process. The image below shows Helvetica on the left (bad) vs Raleway on the right (good):
Discernibility: looking at the apertures of shapes (the openings, e.g. the right-hand gap at the opening of the letter “c”), are they close enough that they could be confused with another letter (e.g. “o”)? The image below shows Public Sans on the left (bad) vs Commissioner on the right (good):
There is also WCAG SC 1.4.12 to consider. When a user overrides any of the following style properties, your page text should not disappear or overlap other page content:
Line height (leading) to at least 1.5x the font size;
Spacing following paragraphs to at least 2x the font size;
Letter spacing (tracking) to at least 0.12x the font size;
Word spacing to at least 0.16x times the font size.
Ryan Tan shares some tips for accessible emoji usage, mostly in terms of screen reader support, and covering a mixture of ‘design tips’ vs ‘everyday content’:
Design: on buttons, don’t use emojis to replace words. E.g. use “Like” rather than “👍”, which could be ambiguous.
Don’t use repeated emojis, e.g. “Flight plans ✈️✈️✈️” as each emoji has alt text read out by a screen reader, and this is unnecessarily noisy.
Put your text / call to action first, then emoji, i.e. “Let’s go 👊” vs “👊 Let’s go”.
Put your emoji at the end of the sentence, not mid-sentence.
Use widely-known emojis to cater for as many users as possible, e.g. “Hello 👋” vs “Hello 🖖”.
Avoid emoticons, i.e. :) vs 🙂. Some emoticons are particularly difficult to understand as a screen reader user, e.g. the ‘shrug’ emoticon ¯_(ツ)_/¯.
Controversially, Ryan suggests you “avoid dark or light skin colour in emoji use” and use the ‘default’ yellow for emojis that have a high contrast on both light and dark backgrounds. There’s a linked article in one of the comments that goes into this topic further, suggesting using emojis that don’t communicate race or gender at all, such as “😸”, or to always use the full range of skin tones such as “✋🏿✋🏾✋🏽✋🏼✋🏻”.
This guide by the BBC walks through their approach for implementing front-end changes, e.g. implementing a component.
Look at the screen reader UX; ask the UX designer for the required documentation if it is missing. It should cover the focus order, the announced content for screen readers, etc.
Check with supported assistive technology (AT). You should do this before adding CSS, and then again before and after adding JavaScript. They advise against doing all your testing at the end, as this “may be more time consuming to debug”, since you won’t necessarily know which layer caused the bug.
Write automated tests for accessibility
Get it reviewed (code review by engineers, design review by designers)
Hold an accessibility swarm, resolve any bugs, then the component is ready for Test.
This article – which I read mostly for the terrible headline – was written by TPGi, an “accessibility solutions provider”, working with a consortium of big names in a11y. TPGi feel that the 9 new Success Criteria recently proposed for WCAG 2.2 all need some clarification and improvement (with the exception of 2.5.7 Dragging Movements, which TPGi are pleased with).
It’s a long article of recommendations, each linking to separate GitHub issues raised by TPGi. But to take an example, some feedback for “3.3.7 Accessible Authentication” includes ensuring copy-paste is not blocked: “The “Intent” section of the non-normative Understanding document mentions that copy-paste must not be blocked, but this is not in the text of the SC. We feel it would need to be in order to ensure that it’s a requirement.”.
It’s fascinating to watch the community shape the WCAG standards of the future, and inspiring that any one of us has the power to propose improvements.
A colleague shared this in our work Slack. Anthony S. Ferraro (asfvsion) demonstrates how he completes everyday tasks as a blind person. He covers the very basics (how to pour a cup of water; by keeping one finger over the rim of the cup and stopping pouring when he feels liquid), to the extreme (how to skateboard on a half-pipe; by mapping out the area with his cane and then basically going for it). He shows just how important tactile controls / labels are on products, e.g. the oven and washing machine, which would be extremely difficult to use otherwise.
TikTok adds photosensitivity warnings to its videos, and allows viewers to opt out of viewing them. It’s also educational; warning labels are shown to creators on the specific effects that may trigger photosensitive epilepsy.
TikTok also offers auto captions and text-to-speech tools, and the ability to switch between animated and static thumbnails.
Anecdotally, TikTok is often seen as very accessible compared to other social media platforms, so it’s always worth noting the improvements they’re making in this area.
A guide by the Microsoft Edge DevTools team, though almost all of it applies to any modern browser.
This mammoth article is a 23 minute read, and covers how to use DevTools for automated accessibility testing, by working through the accessibility ‘warnings’ in the console. It then describes how you should manually test your page by:
Resizing the viewport to simulate a zoomed in or mobile device.
Attempt to interact with the page with a keyboard, and keep an eye out for focus styles.
Inspecting the Accessibility Tree to check for elements with a “generic” role (usually attributed to being encoded as a div or span rather than a button), which won’t be available to users of assistive technology.
Simulating hover/focus states on interactable elements and checking their contrast.
Testing with dark and light themes.
Emulating vision deficiencies with things like blur filters.
Verifying that the page respects the prefers-reduced-motion media query.
It’s worth at least a skim through – chances are you’ll learn something!
This is a website that gamifies teaching you sign language. It uses your webcam to recognise sign language hand gestures, and works extremely well! You gradually progress through different levels of difficulty, eventually covering the entire alphabet.
18% of the UK population regularly uses closed captioning, of which only 1 in 5 actually have hearing difficulties. Why?
The article cites lots of reasons, such as helping with learning a new language. It can also be useful for people with autism and ADHD by providing “deeper context clues”. It also covers situational impairments, such as when sirens or other noises from outside drown out the sound of the movie. And of course, captions allow you to catch up on content on your phone, without disturbing the person next to you.
“We can read faster than we can speak,” says Dr. Stephen Christman, a cognitive psychologist and professor of psychology at The University of Toledo. “With closed captioning on, the viewer can quickly read the current dialogue and then turn their attention back to the visual action and use their knowledge of what is being said — and what is about to be said — to enhance their appreciation of the nonverbal/visual aspects of what is happening on the screen.”
The article cites some downsides, however: “It can really wreck a great punchline or suspenseful twist, making it ill-suited to anything that relies on surprise. It can be irritating when it’s poorly executed and riddled with errors.”
Over 400 accessibility advocates and developers have signed an open letter calling on the industry to avoid using controversial “accessibility overlay products”, the most famous of which is accessiBe. These ‘widgets’ you can install on your website often claim to make your site WCAG compliant, by pulling in third party scripts to ‘fix’ problems such as missing alt text.
The document lists first-hand accounts from people with disabilities struggling to use websites that have implemented overlays.
It also describes the privacy issues of such overlays, which detect when assistive technology is running on the device, exposing the fact that the end user has a disability, with no option for them to choose whether or not to disclose it themselves.
The document recommends that people fix the underlying accessibility issues at source, and abandon use of quick fixes such as these, as they are not effective.
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.
This issue comes a month too late – I’m so sorry! Looks as though I overlooked it. So please enjoy this month’s issue – which is really last month’s issue – and don’t be too surprised to see month11y issue 20 arrive soon after that!
The folks at Princeton University have released a tool, editoria11y, as a frontend module of JS and CSS (but also a Drupal module, and a WordPress plugin is in the works).
The tool aims to catch only editorial accessibility errors, rather than the “ALL the errors” approach used by other accessibility tools, which arguably flag too much. As noted in the article: “they do not just mark mistakes the author just made, they mark color issues the designer made, technical issues the developer made…”.
The demo shows editoria11y in action, warning the editor about common issues such as missing alt attributes, but also more nuanced things like when the alt text is too long or if ALL CAPS is used.
The article concludes with a vision for the future: what if authoring tools made it easier to make accessible content by default? “For example, the default table in most content management systems does not have headers. The onus is on the user to know to click ‘properties’ and add accessibility features; maybe it is time to reverse that?”.
Stephanie Eckles shares some useful CSS tips. I’ve cherry-picked some highlights:
The use of max() to ensure that a focus outline is always at least 1px wide, whilst allowing it to be relatively sized with em:
button:focus { outline: max(1px, 0.1em) solid red }
Use of focus-visible to only apply focus styles when you’ve tabbed in via a keyboard (not mouse click):
button:focus-visible { ... }
Use of CSS grid to maintain the correct tab list order across multiple columns:
This can’t be easily summarised in one line, so worth reading this section of the article.
Stephanie uses currentColor throughout her examples. I don’t remember coming across it before, but it’s a way in CSS of defining a colour throughout your component, so that you only have to set that colour in one place. That’s not explained in the article, but there’s a good write-up of currentColor on DigitalOcean.
Finally, I love this quick global rule for disabling animations for users who prefer reduces motion:
An Adobe announcement from September 2020, which I’ve somehow only just come across. Adobe Acrobat Reader on iOS, Android and Chromebook now has a ‘Liquid Reader’ mode, which is a button in the UI that processes the current PDF in the cloud and then renders a mobile-friendly version of the content. There’s a video showing how it works. It uses AI to identify headings, images, lists, tables etc, making otherwise inaccessible PDFs more usable on mobile. That said, this shouldn’t be used as an excuse to continue to churn out PDFs instead of good, accessible content.
EyeMine is free eye-control software for the game Minecraft. It allows players to navigate the world, mine resources, fight enemies, and essentially complete every in-game task using just their eyes. The source code is available on GitHub.
There is a 4 minute video demonstrating how it works: the screen is split into two panels, one containing the game view and one containing the EyeMine panel. Players shift their gaze to the EyeMine panel to change context, e.g. equip a pickaxe for mining, before shifting their gaze back to the game window.
EyeMine can also be used in conjunction with a switch for key selection or as a direct control for mining and building.
I think it’s worth celebrating that a relatively feature-rich game such as Minecraft can be played with just your eyes, given the right modifications. This is an accessibility success story that makes web accessibility look like a walk in the park in comparison!
Iain Bean shares his approach to accessibility testing a website:
First impressions (on page load) – are there auto-playing videos, etc? There may be a number of obvious a11y issues to fix right off the bat.
Tab around the page, checking if every interactable element can be focused, and has a focus state. Iain points out that Firefox and Safari don’t tab very well by default on OSX, so need to be configured. Iain shares a useful bookmarklet which, when pressed, hides your cursor, helping you to test by keyboard navigation alone. There’s also an unexpected shout-out to my article, I Used The Web For a Day With Just a Keyboard… thanks Iain!
The next step is automated testing: Iain clicks the tota11y bookmarklet, which brings up an overlay and highlights problems in the page such as low contrast, missing alt text, inputs without labels etc. He then runs Lighthouse, and a couple of the other tools mentioned on Web Accessibility Evaluation Tools.
Finally, Iain tests his site with a variety of screen readers.
This approach sounds similar to the Three Phase Attack approach to testing I wrote about in 2016: starting with the lowest effort testing and working your way to the more laborious steps, with gradually diminishing returns. There are only so many browsers, operating systems and assistive technologies you’ll have time to test in, but you’ll usually find most issues by testing your site with a small handful of distinct combinations.
This is an annual report that uses the WAVE web accessibility testing tool to analyse the homepages of the top 1 million websites. Compared to last year:
The number of detectable accessibility errors dropped from 60.9 to 51.4.
The number of DOM elements in the page has increased from 864 to 887.
97.4% of home pages had detectable WCAG 2 failures, down from 98.1%. These were most commonly missing alt text, empty links & buttons, missing language metadata and low contrast text. The latter affected 86.4% of all homepages.
Almost half of all form inputs are not properly labelled. However, more websites are properly using headings.
The presence of JavaScript libraries (and, counter-intuitively, the presence of ARIA) tends to correlate with a higher number of accessibility errors.
.ru (Russian) and .cn (Chinese) websites had twice as many accessibility errors as .us (American) and .ca (Canadian) websites.
And finally, a sign of the system working(?): web site categories that were subject to increased civil rights complaints and lawsuits in 2020 were among the most improved.
The entirely virtual CES in January 2021 saw a number of assistive technologies, as companies begin to realise the importance of inclusivity and the money that can be made. Some highlights include:
Mantis Q40 – a $2.5k QWERTY keyboard with built-in braille display.
Oticon More – a hearing aid with built-in neural network, trained on 12 million real life sounds, to help process speech in noisy environments.
Sravi – an app that uses AI based lip-reading technology to recognise specific phrases from lip movements. It is aimed at people with speech difficulties, or patients in critical care with ailments that render them incapable of speaking. The app is in trials within the UK’s National Health Service.
This is another one from the bookmarks that I’ve just gotten around to reading! Colin Hughes reviews the accessibility of iOS 14. He has muscular dystrophy and therefore relies on voice control.
Since iOS 11, iPhone users have been able to activate an auto-answer capability for incoming phone calls, but Colin notes that it requires you to touch the screen to set it up in the first instance. You can also make calls by saying “Hey Siri, call…”, but there’s no equivalent for ending the call, so if you go to voicemail you are stuck until the mailbox times out. This is still an issue in iOS 14.
Since iOS 13, the Announce Messages with Siri feature reads out your incoming messages and allows you to respond hands-free. Colin hoped this would be expanded to other apps like WhatsApp or Facebook Messenger, via an underlying API, but this has not happened in iOS 14.
Voice Control now supports UK English, which has improved the accuracy of Colin’s dictation, though the accuracy remains low and using the app is frustrating when compared with Voice Access in Android 11, which is “incredible” by comparison.
Colin also cites “improvements to the VoiceOver screen reader, a new Back Tap Feature, sign language in FaceTime calls, and Headphones Accommodations to help you hear better”. However, overall, Colin is disappointed that some of the the basics are still neglected.
A thorough investigation by Mark Robbins, looking at the state of webmail across a dozen different providers.
60% of screen reader users prefer pages containing just one <h1> with the document title, whereas 33.3% prefer two <h1> headings, for the site name and the title.
Given a preference for one <h1> tag per page, the question is: should you include a <h1> in the emails you send people, or would that conflict with a <h1> that already exists in the webmail client? In other words, when viewing an email on gmail.com, how many <h1> tags are there?
Mark found that most webmail clients don’t add a <h1> to the page when viewing an email. I verified this by opening an email on gmail.com and inspecting the subject line, which is marked up as a <h2>. A couple of webmail providers do include a <h1> in the page, but their market share is low, and leaving out <h1> tags would do more harm to the many users of the other webmail clients.
Mark’s advice is to therefore include a <h1> tag in your emails. That’s easier said than done, of course – it only really works for email designers using professional services such as Mailchimp. For one person sending an email to another person, it’s not so easy.
TechRadar Pro asked UK-based designer Kevinsdesign to improve the design of Wikipedia. The screenshots in the article are fun to look through, showcasing a useful ‘table of contents’ side panel, a homepage of discovery options, and accessibility and language options brought to the forefront.
Kevinsdesign interviewed four users to discover their friction points with the existing website, before mocking up the designs. He spent most of his time thinking through the accessibility options. He said:
“Wikipedia is accessed by billions worldwide with the common goal of consuming written articles, however reading isn’t a given for everyone, between 5-10% of the population are dyslexic (myself included), even more have visual impairments and so on. Things like colour contrast, font size, and even black text on white backgrounds can make content very hard to consume.”
“I asked the question: could I bake in accessibility options to the new design that would break down these barriers and make Wikipedia more accessible to people? The new accessibility option in the menu allows the user to customize the setting to their needs, be it making the font size bigger, making the content seizure safe, changing the font to child friendly and even adding a color overlay to the article which for many dyslexics massively helps them read.”
These options are captured in the screenshot above.
Wix is a popular platform for building and hosting websites, choosing from pre-built themes and customising the content. It has now launched its ‘Accessibility Wizard’, which is built into the CMS.
You can use the wizard to scan your site for accessibility issues, detecting things like images with missing alt text, improper heading orders, or insufficient colour contrast. The wizard provides detailed instructions on how to fix each issue.
The article above is frustratingly thin on detail, but you can find out more on Wix’s official blog post. It arose from a checklist which Wix created and asked website editors to follow, but users found this too heavy and time-consuming to follow.
Anthony Vasquez shares some things you may not know about how some people use screen readers. The article is a follow-up to a Screen Readers in the Wild seminar. Some video demonstrations from the seminar are linked below:
“Often, developers go too far treating images as decorative”, (perhaps because it’s easier to specify an empty alt="" attribute than to come up with good alternative text? ~Chris), leading Anthony to feel he’s missing out on something, and to try to derive context from the surrounding content. Anthony praises The Atlantic for getting alt text right, with a good mix of short and long descriptions.
Anthony mostly navigates pages using arrow keys, which can “reveal important information” that is otherwise missed by tabbing. However, computer science student Su Park – who also demonstrated in the webinar – navigates mostly with tabbing and shortcut keys. Anthony says it is important to test both interaction styles.
The article finishes with a little detail on what refreshable Braille displays are.
Sophie Beaumont writes about working on the BBC’s design system. A team had hoped to re-use one of the existing components in a new feature they were building, because it matched their visual design. However, on closer inspection, the underlying HTML semantics were unsuitable for the task, and they decided a new, separate component would be more appropriate. Sophie summarises: “Focus on what components achieve, rather than their appearance”.
They were able to catch the issue early because of a recent push for accessibility documentation during the design phase. In other words, designers talking to developers about what the structure of the content should be, including semantics such as headings, lists and landmarks. This is considered “shifting accessibility left”, i.e. embedding it earlier in the software development cycle, and in this case it exposed a requirements issue that would have been costly to fix later.
These are my notes, which I wrote while attending the BBC’s “Monday 17th May: Hearing” event to mark Global Accessibility Awareness Day (which is Thursday 20th May). There were a range of speakers in the 1-hour session:
Keynote from Jenny Lay-Flurrie, Chief Accessibility Officer at Microsoft:
Unemployment rate is approximately double for people with disabilities.
People with disabilities have asked to work from home for decades – COVID has removed that barrier, but the unemployment gap actually increased.
Microsoft is working with universities to level up accessibility skills in its undergraduates.
Nigel Megitt, Executive Product Manager for AV Accessibility at BBC:
We saw a demo of changing the size of subtitle text on the iPlayer TV app. Note that this was already a feature on the web version.
iPlayer received mixed feedback on the default size of the subtitles. Realised that there was a preference for different default subtitle sizes based on device type and size.
There was some technical detail around the standard of subtitle files that the BBC exports.
Kay Ashton MBE, Accessibility Project Coordinator at BBC:
We watched ‘Sing’ – BSL SignSong (“Fletch@rettes Signing Choir”, participants from BBC Children in Need projects, BBC Ability, BBC Philharmonic and BBC Singers, recorded in lockdown to raise awareness of BSL for Deaf Awareness Week 2021).
Panel discussion including Esmail Patel (of Interpreting Solutions), Fletch@ (of Fletch BSL), and Lewis Vaughn Jones (of BBC Global News):
Platforms such as TikTok are driving better accessibility on social media (though probably down to better engagement, rather than ‘for accessibility’). And people are becoming proud to show off sign language on social media, both British Sign Language and International Sign Language.
Automated transcriptions are improving all the time. Also a shout out for the Text to Speech app.
These are my notes, which I wrote while attending the BBC’s “Tuesday 18th May: Vision” event to mark Global Accessibility Awareness Day (which is Thursday 20th May). There were a range of speakers in the 1-hour session:
Talk by Molly Watt, founder of Molly Watt Trust:
Molly was born deaf. She had a good speaking voice and could lip read, so not many people even realised. In her teens, her vision started to deteriorate, and Molly was formally diagnosed with Usher Syndrome.
From the age of 3, Molly had analogue hearing aids, which were replaced with digital at the age of 9; Molly remembers hearing birds singing for the first time. Later on she was given a ‘smart’ hearing aid, where the quality of sound improved even further, and came with surround sound – essential for someone who is blind as well as deaf. It also has a smartphone app, where Molly can change the bass/treble/background noise levels.
Molly has an iPhone, which comes with lots of assistive technology built in. It has two screen readers – VoiceOver and SpeakScreen – and Molly uses mostly the latter. Molly also uses colour filters, rather than dark mode, to place a tint on the screen and reduce the glare. Finally, she uses Siri to send messages, meaning she doesn’t need to physically get her phone out in public. Molly now feels ready to move out of the family home, even during COVID, and says this is all down to technology.
Molly went to university but couldn’t access the intranet, due to its inaccessibility. She fought for change, but couldn’t get the university to make any changes, so left the uni in order to educate on a larger stage.
The Molly Watt Trust was founded to raise awareness of Usher Syndrome, and for people with Usher Syndrome to meet one another and boost morale and give the tech/tools needed to get by.
Talk by Natalie Curran, Assistive Technology Tester at BBC:
There has been a lot of movement on equality over the past few years, but disability equality seems to have been left behind.
Natalie has been an ATT for 8 months, and says she is still learning lots. She is looking forward to going into the office, where she’ll be able to use assistive technologies she hasn’t used before, such as ZoomText.
Natalie wants to help “bridge the gap”, saying “if only one person walks away and next time they [build] something, they think twice about [how to do it accessibly], then I’ve done my job”.
Talk by TV Platform Accessibility Guild at BBC:
Watched a presentation – ‘Screen Readers on TV’ – presented by “BBC Synthetic Voice”, which sounded very human. It’s challenging to build TV apps – older ‘smart’ TVs often don’t support new technology. The average person keeps their TV for 7-8 years – the equivalent of web developers having to support iPhone 5 today.
BBC Sounds was designed with basic screen reader support from the start, as it’s a relatively new app, but iPlayer has been slower going. It was, until recently, silent when using a screen reader, but new changes available in beta introduce support in some pages (though not all pages, notably the the sign-in screens).
The BBC are working with TV manufacturers, writing & providing automated tests to them so that they can identify issues prior to the device being released. The BBC are hoping this will improve the experience for ALL applications on the device, not just iPlayer.
Panel: Paul Smyth MBE of Barclays Accessibility, Robin Christopherson MBE of AbilityNet, Adi Latif of AbilityNet, Emma Tracey of BBC Journalism, and Sean Dilley of BBC News:
It was 2009 when Sean had his first accessible phone – the iPhone – which “opened up the world” to him. Prior to that he had some Nokia phones that spoke to him but weren’t particularly useful.
[What do you use for work every day?]
Paul uses ZoomText to avoid eye strain, and to reduce the reliance on (and noise of) his screen reader.
Robin uses a Bluetooth headset, joining with audio only, listening to the meeting but also having other earphones for their computer so that he can multitask.
Emma uses a Perkins Brailler – a metal braille typewriter for labelling her kids’ books, kitchen spices etc.
Adi loves his PenFriend – a pen shaped device to record voice notes associated with labels you can stick to things, such as food in the kitchen, and then wave the pen over it to play the voice note. It allows him to easily identify spices etc.
Sean has a barcode scanner app on his iPhone to tell him what tins he’s looking at, and also apps where he can ask a person what’s in front of the camera, which is very useful sometimes.
These are my notes, which I wrote while attending the BBC’s “Wednesday 19th May: Motion” event to mark Global Accessibility Awareness Day (which is Thursday 20th May):
Vivek Gohil, is a gaming accessibility consultant:
Vivek has muscular dystrophy. He started gaming at age 10 with a gameboy: “it helps to escape reality” and is “very important for mental health”.
At 15, Vivek first experienced accessibility issues with holding a controller. He managed to overcome it with a table and sponges for support.
The SpecialEffect charity uses technology to help people with physical disabilities to play games to the best of their abilities, using technology such as modified joypads.
Vivek started a YouTube channel to create accessibility reviews of new games.
The Last of Us: Part II is critically acclaimed for its accessibility options. It has slow-motion aiming, makes you invisible while prone, has an aiming toggle, and has full control remapping support.
Vivek would like to see these accessibility options as standard in future: alternate sprinting option, slow motion aiming, remap different actions to either button tap or hold.
Christopher Hills, video editor and founder of HandsOptional:
Christopher has cerebral palsy, and self-confessed technology geek. In 2012, Christopher studied information technology. He made a video showing how he uses technology to consume his lectures, which he sent to his lecturers and also uploaded to YouTube. It got shared by Chris Pirillo and overnight gained 50,000 views. Christopher now has a sizeable following on his channel.
It was at this moment Christopher realised “I had something valuable to share with the world, and the technology at my disposal is infinitely more powerful than I’d thought.” After studying film at university, Christopher became Apple-certified in Final Cut Pro, started a consulting business and co-wrote a book.
Christopher uses a lot of Apple technology, which supports a wide range of a11y features, including Switch Control. He uses Siri Shortcuts to configure his office to shut blinds, close the door, etc, all from one click interaction, and is comfortable completely redesigning his on-screen keyboard layout when it doesn’t suit him.
Christopher closes by sharing a video of how he flies drones to capture cinematic shots. It goes into detail on his assistive technology setup. Christopher created the music accompanying the video, using apps on his machine. It’s incredibly powerful and moving, and well worth watching.
“With today’s technology, it is not my body that limits me – it is my imagination.”
Panellists: Brannon Zahand of Microsoft XBox Accessibility, Andrew Bromilow of EveryoneCan, animation student Nu McAdam, and Allan MacKillop of BBC Diversity & Inclusion:
Nu: keen for us to return to the office – there’s a lot of loneliness in the disabled community that is being amplified by us all being remote.
Brannon: there is an increasing recognition that “we are not our user”, seen in things like customisation, e.g. allowing you to set your colour preference.
Andrew: when stuck on an a11y problem, reach out to the disabled community – they are experts. And be prepared to pay them for their time.
Allan: the current generation of elderly people need support with technology. But he expects the elderly people of the future will be much more tech savvy, playing video games, etc.
There’s also a shout out to Xbox for maintaining backwards compatibility between its consoles and controllers: good for sustainability, and less of a barrier to those with accessibility needs who have a particular setup.
And then, finally, it was Global Accessibility Awareness Day! There were lots of events all over the web, and it was hard to choose what to attend. Aside from a couple of internal work events, I mostly attended sessions at the very well run Festival of Accessibility:
Digital by Default: Baby Boomers and the impact of COVID-19:
“Over the past year the digital world has quickly evolved. This change has impacted older web users more than most.”
My takeaways from this session: of people who are over 50 years old, around 23% find an ‘increase font size’ option useful (according to, I think, YouGov). And the UK has an average reading age of 9, so it’s very important to use simple language. This became something of a theme in many of the talks I saw today.
Writing in Plain English – the inclusion challenge:
“Did you know that as many as 1 in 4 UK adults have very low literacy skills? And 10% have dyslexia, which can cause reading challenges?”
Think about your target audience before you write. Imagine how you would talk to your target reader if they were in front of you, and write that down – it won’t be quite right, but it’ll be a great starting point that likely sums up the most important things you have to say.
Use signposts throughout your content: headings, bullet lists, and frontloading of content (i.e. put the important content towards the beginning of your sentence). Personal, conversational language tends to read better, e.g. “your heart may beat faster” vs “the heart may beat faster”.
The Flesch Reading Ease scale looks at sentence and syllable length and arrives at a score of complexity from 0 to 100, where the lower the score, the more confusing the content. GOV.UK aims for a minimum of 70.
Digital Literacy & Accessibility in the Public Sector:
“Up to 1 million people in the UK cannot speak English well or at all.”
50% of the population are below primary school numeracy level.
Using clear communication (verbal, written, digital)
Creating easy-to-use digital tools/websites, printed information and premises
Involving users in the development of information as routine and inviting feedback
Training staff in health literacy
Commit to consider digital exclusion and the equalities impact when introducing new resources.
The Future of A11Y:
This panel session ended the day of events. It touched on lots of interesting topics.
There was talk of Public Sector Accessibility Regulations being a useful ‘stick’ to encourage compliance, where the ‘carrot’ of inclusivity doesn’t always work.
Advocating for accessibility at the highest levels requires different tactics: the threat of litigation (see above), the cost to the business (someone mentioned that accessibility costs 200 times more to retro-fit into an established product than to build in from the start). But empathy can work too: invite a disabled person into your board room to demonstrate the challenges they face using your product.
There was a shout-out to DIVERSish on YouTube, a skit which points out that whilst 90% of companies claim to “prioritise diversity”, it usually means focusing on LGBTQ, BAME and women, whereas disability regularly gets overlooked (“only 4% prioritise disability”).
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.
Ryan Tan shares some tips for accessible emoji usage, mostly in terms of screen reader support, and covering a mixture of ‘design tips’ vs ‘everyday content’:
Design: on buttons, don’t use emojis to replace words. E.g. use “Like” rather than “👍”, which could be ambiguous.
Don’t use repeated emojis, e.g. “Flight plans ✈️✈️✈️” as each emoji has alt text read out by a screen reader, and this is unnecessarily noisy.
Put your text / call to action first, then emoji, i.e. “Let’s go 👊” vs “👊 Let’s go”.
Put your emoji at the end of the sentence, not mid-sentence.
Use widely-known emojis to cater for as many users as possible, e.g. “Hello 👋” vs “Hello 🖖”.
Avoid emoticons, i.e. :) vs 🙂. Some emoticons are particularly difficult to understand as a screen reader user, e.g. the ‘shrug’ emoticon ¯_(ツ)_/¯.
Controversially, Ryan suggests you “avoid dark or light skin colour in emoji use” and use the ‘default’ yellow for emojis that have a high contrast on both light and dark backgrounds. There’s a linked article in one of the comments that goes into this topic further, suggesting using emojis that don’t communicate race or gender at all, such as “😸”, or to always use the full range of skin tones such as “✋🏿✋🏾✋🏽✋🏼✋🏻”.
This guide by the BBC walks through their approach for implementing front-end changes, e.g. implementing a component.
Look at the screen reader UX; ask the UX designer for the required documentation if it is missing. It should cover the focus order, the announced content for screen readers, etc.
Check with supported assistive technology (AT). You should do this before adding CSS, and then again before and after adding JavaScript. They advise against doing all your testing at the end, as this “may be more time consuming to debug”, since you won’t necessarily know which layer caused the bug.
Write automated tests for accessibility
Get it reviewed (code review by engineers, design review by designers)
Hold an accessibility swarm, resolve any bugs, then the component is ready for Test.
This article – which I read mostly for the terrible headline – was written by TPGi, an “accessibility solutions provider”, working with a consortium of big names in a11y. TPGi feel that the 9 new Success Criteria recently proposed for WCAG 2.2 all need some clarification and improvement (with the exception of 2.5.7 Dragging Movements, which TPGi are pleased with).
It’s a long article of recommendations, each linking to separate GitHub issues raised by TPGi. But to take an example, some feedback for “3.3.7 Accessible Authentication” includes ensuring copy-paste is not blocked: “The “Intent” section of the non-normative Understanding document mentions that copy-paste must not be blocked, but this is not in the text of the SC. We feel it would need to be in order to ensure that it’s a requirement.”.
It’s fascinating to watch the community shape the WCAG standards of the future, and inspiring that any one of us has the power to propose improvements.
A colleague shared this in our work Slack. Anthony S. Ferraro (asfvsion) demonstrates how he completes everyday tasks as a blind person. He covers the very basics (how to pour a cup of water; by keeping one finger over the rim of the cup and stopping pouring when he feels liquid), to the extreme (how to skateboard on a half-pipe; by mapping out the area with his cane and then basically going for it). He shows just how important tactile controls / labels are on products, e.g. the oven and washing machine, which would be extremely difficult to use otherwise.
TikTok adds photosensitivity warnings to its videos, and allows viewers to opt out of viewing them. It’s also educational; warning labels are shown to creators on the specific effects that may trigger photosensitive epilepsy.
TikTok also offers auto captions and text-to-speech tools, and the ability to switch between animated and static thumbnails.
Anecdotally, TikTok is often seen as very accessible compared to other social media platforms, so it’s always worth noting the improvements they’re making in this area.
A guide by the Microsoft Edge DevTools team, though almost all of it applies to any modern browser.
This mammoth article is a 23 minute read, and covers how to use DevTools for automated accessibility testing, by working through the accessibility ‘warnings’ in the console. It then describes how you should manually test your page by:
Resizing the viewport to simulate a zoomed in or mobile device.
Attempt to interact with the page with a keyboard, and keep an eye out for focus styles.
Inspecting the Accessibility Tree to check for elements with a “generic” role (usually attributed to being encoded as a div or span rather than a button), which won’t be available to users of assistive technology.
Simulating hover/focus states on interactable elements and checking their contrast.
Testing with dark and light themes.
Emulating vision deficiencies with things like blur filters.
Verifying that the page respects the prefers-reduced-motion media query.
It’s worth at least a skim through – chances are you’ll learn something!
This is a website that gamifies teaching you sign language. It uses your webcam to recognise sign language hand gestures, and works extremely well! You gradually progress through different levels of difficulty, eventually covering the entire alphabet.
18% of the UK population regularly uses closed captioning, of which only 1 in 5 actually have hearing difficulties. Why?
The article cites lots of reasons, such as helping with learning a new language. It can also be useful for people with autism and ADHD by providing “deeper context clues”. It also covers situational impairments, such as when sirens or other noises from outside drown out the sound of the movie. And of course, captions allow you to catch up on content on your phone, without disturbing the person next to you.
“We can read faster than we can speak,” says Dr. Stephen Christman, a cognitive psychologist and professor of psychology at The University of Toledo. “With closed captioning on, the viewer can quickly read the current dialogue and then turn their attention back to the visual action and use their knowledge of what is being said — and what is about to be said — to enhance their appreciation of the nonverbal/visual aspects of what is happening on the screen.”
The article cites some downsides, however: “It can really wreck a great punchline or suspenseful twist, making it ill-suited to anything that relies on surprise. It can be irritating when it’s poorly executed and riddled with errors.”
Over 400 accessibility advocates and developers have signed an open letter calling on the industry to avoid using controversial “accessibility overlay products”, the most famous of which is accessiBe. These ‘widgets’ you can install on your website often claim to make your site WCAG compliant, by pulling in third party scripts to ‘fix’ problems such as missing alt text.
The document lists first-hand accounts from people with disabilities struggling to use websites that have implemented overlays.
It also describes the privacy issues of such overlays, which detect when assistive technology is running on the device, exposing the fact that the end user has a disability, with no option for them to choose whether or not to disclose it themselves.
The document recommends that people fix the underlying accessibility issues at source, and abandon use of quick fixes such as these, as they are not effective.
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.
A guide by the Microsoft Edge DevTools team, though almost all of it applies to any modern browser.
This mammoth article is a 23 minute read, and covers how to use DevTools for automated accessibility testing, by working through the accessibility ‘warnings’ in the console. It then describes how you should manually test your page by:
Resizing the viewport to simulate a zoomed in or mobile device.
Attempt to interact with the page with a keyboard, and keep an eye out for focus styles.
Inspecting the Accessibility Tree to check for elements with a “generic” role (usually attributed to being encoded as a div or span rather than a button), which won’t be available to users of assistive technology.
Simulating hover/focus states on interactable elements and checking their contrast.
Testing with dark and light themes.
Emulating vision deficiencies with things like blur filters.
Verifying that the page respects the prefers-reduced-motion media query.
It’s worth at least a skim through – chances are you’ll learn something!
This is a website that gamifies teaching you sign language. It uses your webcam to recognise sign language hand gestures, and works extremely well! You gradually progress through different levels of difficulty, eventually covering the entire alphabet.
18% of the UK population regularly uses closed captioning, of which only 1 in 5 actually have hearing difficulties. Why?
The article cites lots of reasons, such as helping with learning a new language. It can also be useful for people with autism and ADHD by providing “deeper context clues”. It also covers situational impairments, such as when sirens or other noises from outside drown out the sound of the movie. And of course, captions allow you to catch up on content on your phone, without disturbing the person next to you.
“We can read faster than we can speak,” says Dr. Stephen Christman, a cognitive psychologist and professor of psychology at The University of Toledo. “With closed captioning on, the viewer can quickly read the current dialogue and then turn their attention back to the visual action and use their knowledge of what is being said — and what is about to be said — to enhance their appreciation of the nonverbal/visual aspects of what is happening on the screen.”
The article cites some downsides, however: “It can really wreck a great punchline or suspenseful twist, making it ill-suited to anything that relies on surprise. It can be irritating when it’s poorly executed and riddled with errors.”
Over 400 accessibility advocates and developers have signed an open letter calling on the industry to avoid using controversial “accessibility overlay products”, the most famous of which is accessiBe. These ‘widgets’ you can install on your website often claim to make your site WCAG compliant, by pulling in third party scripts to ‘fix’ problems such as missing alt text.
The document lists first-hand accounts from people with disabilities struggling to use websites that have implemented overlays.
It also describes the privacy issues of such overlays, which detect when assistive technology is running on the device, exposing the fact that the end user has a disability, with no option for them to choose whether or not to disclose it themselves.
The document recommends that people fix the underlying accessibility issues at source, and abandon use of quick fixes such as these, as they are not effective.
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.
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.
