Welcome to the first week11y of 2023! I’ve had a nice little break from the newsletter, but am looking forward to getting going again.
But first: a big thank you to everyone who completed my survey. It’s really useful knowing what’s most important to you (so much so that I’ll leave it open, in case anyone else wants to fill it in). Developments in a11y specifications, as well as tools/resources to help with a11y testing/design, are the subject areas that were most requested, and I have an example of each in this issue!
I will also continue writing my summary for each resource, as most of you said you find this useful. Another idea pitched was to start ‘collections’ of bookmarks, so that these links aren’t lost into the ether after they’re published. Whilst these newsletters are posted to my website, they’re not organised beyond date, so I’ll definitely give that some consideration. Now, on with the issue!
Giphy is adding alt text to make GIFs more accessible
Giphy is working with Scribely (a “content accessibility solutions provider”) to add descriptive text to its most popular animated gifs. It will be professionally hand written, not auto-generated.
Giphy is also planning to expose the alt text through its APIs, so that third party platforms can benefit from the alt text too. Twitter, for example, has a partnership with Giphy, so any Giphy content shared to Twitter might soon be more accessible.
It does seem a bit sad that we’re celebrating a major company beginning to recognise the importance of alt text as we’re entering into 2023. But a step in the right direction nevertheless.
The 411 on 4.1.1
Adrian Roselli writes about WCAG SC 4.1.1: a 13.5 years old rule that first came out in WCAG 2.0. Roughly, it stipulates that content should have proper markup (elements only nested as per specifications, no duplicate attributes or IDs, etc).
One of the authors recently-ish filed a proposal to clarify the language, claiming that the original intent of the criterion was narrower than the current interpretation reflects. Moreover, it’s been argued that 4.1.1 as a whole should be deprecated now that browsers more predictably handle nesting, closing elements and duplicate attributes. It may disappear as early as WCAG 2.2.
Adrian goes into technical detail on why each thing covered by 4.1.1 is either no longer relevant, or considers where that thing might be better covered by other Success Criteria. He anticipates that the W3C will “come out with a clearer and better considered mapping for former 4.1.1 issues”.
Swearing and automatic captions
Eric Bailey highlights the issue of how automatic captions deal with swearing. A number of providers automatically censor certain words, displaying a string of asterisks instead. There are lots of problems with this:
- It’s nannying what a Deaf person should be hearing, creating a lack of equivalency in experience.
- It undoes the speaker’s agency, “diluting the message they’re trying to communicate”. People get passionate, people swear, it is a deliberate act.
- It wrongly assumes that captioning is only ever used in a professional or ‘business’ context.
- It also asserts that all professional or business contexts should be swear free – why?
- It creates confusion: the audience is left trying to figure out what the word is, and may even imagine a far ruder word than the captioning software was trying to save them from!
- It falls victim to inaccuracy. Non-swear words get accidentally censored, whereas actual swear words get imaginatively interpreted (Eric cites “Titz”, a municipality in Germany).
Eric experiments with speaking specific swear words into a number of different applications that provide automatic captioning, e.g. Zoom, Google Meet and TikTok. The results were mixed – you can watch videos of each in the article. I particularly enjoyed the summary for Skype: “many swears were initially displayed and then replaced with asterisks, making the entire point moot.”
We then move onto ‘voice control’ technologies, such as voice access (a native Windows 11 feature). It censors (with asterisks) the swear words you’re transcribing – a disappointing outcome for inclusivity. Apple’s equivalent, Voice Control, doesn’t censor. Dragon Home censors by mishearing words, e.g. “shipped”.
Censoring swear words is kind of a default approach built into a lot of software. It’s often implemented with little thought, on the reasonable enough assumption that this is the correct, ‘safe’ approach, to avoid the risk of abuse of your product and/or reputational damage to your company. But there’s a serious accessibility issue at the heart of this, and Eric hits the nail on the head. Well worth a read.
colorandcontrast.com
This is a very deep dive into colour, contrast, and how people differ in how they see things. It has interactive examples throughout, which really help to illustrate the concepts. Definitely one worth a bookmark.
It begins with the biology of the eye, before going into colour vision and visual impairments, and different vision effects. It then covers properties of colour (lightness and hue, but also chromaticity and chroma), the relationships between colour, the different colour models used in technology (RGB vs CMYK etc) and different ways of measuring contrast.
It ends with a chapter on light vs dark mode, and a chapter on user interfaces and data visualisations, which will be perhaps the most relevant sections to skim through.
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.
