Journal
I’ve started reading Uncanny Valley, by Anna Wiener.
Thanks for the recommendation, @mrtomchurchill.
Design Engineering, on the Clearleft Podcast
Loved this short listen from Clearleft, on a subject close to my heart! New job titles can feel a bit “emperor’s new clothes” but with Design Engineering I think Clearleft, GitHub et al. might be onto something. It was fascinating hearing people from both design and engineering backgrounds give their perspectives, and how ultimately they’re addressing the same thing—the need to “finesse the overlaps/gaps” between design and the realisation of that design in engineering, especially in light of the complexities of the modern front-end.
(via @Stugoo)
Broken Copy, on a11y-101.com
Here’s an accessibility tip that’s new to me. When the content of a heading, anchor, or other semantic HTML element contains smaller “chunks” of span and em (etc), the VoiceOver screen reader on Mac and iOS annoyingly fails to announce the content as a single phrase and instead repeats the parent element’s role for each inner element. We can fix that by adding an inner “wrapper” element inside our parent and giving it role=text.
Make sure not to add this role directly to your parent element since it will override its original role causing it to lose its intended semantics.
The text role is not yet in the official ARIA spec but is supported by Safari.
(via @Seraphae and friends on Twitter)
Motion One: The Web Animations API for everyone
A new animation library, built on the Web Animations API for the smallest filesize and the fastest performance.
This JavaScript-based animation library—which can be installed via npm—leans on an existing web API to keep its file size low and uses hardware accelerated animations where possible to achieve impressively smooth results.
For fairly basic animations, this might provide an attractive alternative to the heavier Greensock. The Motion docs do however flag the limitation that it can only animate “CSS styles”. They also say “SVG styles work fine”. I hope by this they mean SVG presentation attributes rather than inline CSS on an SVG, although it’s hard to tell. However their examples look promising.
The docs website also contains some really great background information regarding animation performance.
Testing ES modules with Jest
Here are a few troubleshooting tips to enable Jest, the JavaScript testing framework, to be able to work with ES modules without needing Babel in the mix for transpilation. Let’s get going with a basic set-up.
package.json
…,
"scripts": {
"test": "NODE_ENV=test NODE_OPTIONS=--experimental-vm-modules jest"
},
"type": "module",
"devDependencies": {
"jest": "^27.2.2"
}
Note: take note of the crucial "type": "module" part as it’s the least-documented bit and your most likely omission!
After that set-up, you’re free to import and export to your heart’s content.
javascript/sum.js
export const sum = (a, b) => {
return a + b;
}
spec/sum.test.js
import { sum } from "../javascript/sum.js";
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
Hopefully that’ll save you (and future me) some head-scratching.
(Reference: Jest’s EcmaScript Modules docs page)
Harry Roberts says “Get Your Head Straight”
Harry Roberts (who created ITCSS for organising CSS at scale but these days focuses on performance) has just given a presentation about the importance of getting the content, order and optimisation of the <head> element right, including lots of measurement data to back up his claims. Check out the slides: Get your Head Straight
While some of the information about asset loading best practices is not new, the stuff about ordering of head elements is pretty interesting. I’ll be keeping my eyes out for a video recording of the presentation though, as it’s tricky to piece together his line of argument from the slides alone.
However one really cool thing he’s made available is a bookmarklet for evaluating any website’s <head>:
— ct.css
The accessibility of conditionally revealed questions (on GOV.UK)
Here’s something to keep in mind when designing and developing forms. GOV.UK’s accessibility team found last year that there are some accessibility issues with the “conditional reveal” pattern, i.e. when selecting a particular radio button causes more inputs to be revealed.
The full background story is really interesting but the main headline seems to be: Keep it simple.
- Don’t reveal any more than a single input, otherwise the revealed section should not be in a show-and-hide but rather in its own form in the next step of the process.
- Conditionally show questions only (i.e. another form input such as Email address)—do not show or hide anything that’s not a question.
Doing otherwise causes some users confusion making it difficult for them to complete the form.
See also the Conditionally revealing a related question section on the Radios component on the GDS Design System
W3C Design System
The W3C have just published a new Design System. It was developed by British Digital Agency Studio 24, who are also working (in the open) on the redesign of the W3C website.
My initial impression is that this Design System feels pretty early-stage and work-in-progress. I’m not completely sold on all of the technical details, however it definitely contains a number of emergent best practices and lots of interesting parts.
I particularly liked the very detailed Forms section which assembles lots of good advice from Adam Silver and GOV.UK, and I also found it interesting and useful that they include a Page Templates section rather than just components and layouts.
It’s cool to see an institution like the W3C have a Design System, and I’m looking forward to seeing how it evolves.
I’ve started reading Kindred, by Octavia E. Butler.
Accessibility Testing (on adactio.com)
In this journal entry, Jeremy Keith argues that when it comes to accessibility testing it’s not just about finding issues—it’s about finding the issues at the right time.
Here’s my summary:
- Accessibility Audits performed by experts and real Assistive Technology users are good!
- But try to get the most out of them by having them focus on the things that you can’t easily do yourself.
- We ourselves can handle things like colour contrast. It can be checked at the design stage before a line of code is written.
- Likewise HTML structure such as ensuring accessible form labels, ensuring images have useful
altvalues, using landmarks likemainandnav, heading structure etc. These are not tricky to find and fix ourselves and they have a big accessibility impact. - As well as fixing those issues ourselves we should also put in place new processes, checks and automation if possible to stop them recurring
- As for custom interactive elements (tabs, carousels, navigation, dropdowns): these are specific to our site and complicated/error-prone by nature, so those are the things we should be aiming to have professional Accessibility Audits focus on in order to get best value for money.