An Interactive Guide to CSS Grid This article is excellent, in my opinion. It explained a lot of things that I half-knew and helped me get a mental model of what’s happening. (Your learning style might be different, of course, but I found I had to read it 2 or 3 times to get into it, and I’ve bookmarked it to be able to refer to)
How to Use Responsive HTML Video (…and Audio!) – Back to the future, here; this was in the spec and in browsers (it was the inspiration for the original <picture> element), removed, and now is back again!
Reflecting on 18 years at Google – Hixie, the leader of WHATWG that bought about “HTML5” and a renaissance for the Web, has resigned from Google. He’s characteristically forthright about his reasons.
Exclusive accordions exclude – Eric Eggert on why the current proposal to extend HTML <details> element to make exclusive accordians hasn’t been sufficiently thought-through
Vosh – a third-party screen-reader for the Macintosh – “After getting fed up with the general neglect of MacOS accessibility from Apple… I decided to attempt something that for some reason nobody seems to have tried to do before: write a completely new screen-reader for that platform.”
Inside Foxconn’s struggle to make iPhones in India – “Chinese engineers are flying to India to train the next generation of iPhone builders”. A fascinating look at the culture differences, and a disconcerting reminder of the exploitation behind our gadgets.
TL;DR: Until Formstack integrates autocomplete, I don’t believe it’s possible to guarantee accessible forms. Formstack’s inadequate accessibility documentation suggests they do not understand their obligations.
If you find filling in forms boring, you won’t believe how boring coding them can be. And then you have to do something with the submissions, decide on how to archive them, their GDPR liabilities etc. No wonder so many organisations go looking for third party solutions.
For web users, browsers can do a lot of work to help filling in forms accurately and quickly. We’re all familiar with browsers remembering your username and password. Also, all browsers let you input credit card details and other personal data (address, name, date of birth etc) and that can be used by the browser to autocomplete forms, if the developer identifies the purpose of the field:
A client recently asked me to evaluate their site against the new WCAG 2.2 requirements. One of these is 3.3.7 Redundant Entry which states “Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated, or available for the user to select”. This doesn’t require developers to integrate browser’s autocomplete (logic could be developed to populate from back-end systems), but it could certainly help. And, at level AA (which is the minimum you should aspire to), autocomplete is required by Success Criterion 1.3.5: Identify Input Purpose:
The purpose of each input field collecting information about the user can be programmatically determined when: The input field serves a purpose identified in the Input Purposes for user interface components section; and The content is implemented using technologies with support for identifying the expected meaning for form input data.
The client had made the decision to use Formstack to generate their forms. I pored through the Formstack documentation to learn how to set autocomplete attributes on the HTML it generates, but found nothing. Eventually, I emailed support who replied
Unfortunately, we currently do not have support for this feature however, this is an excellent idea and may be something that we can add in a future release. We recommend submitting this as a Feature Request on our feedback page for our Product team to review for implementation.
I filed a Feature Request, feeling like Winston Smith depositing paper into the Memory Hole. The email contained a link which told me they are “substantially 508 Compliant” (‘508’ is a US accessibility law – note, they don’t claim to be ‘fully compliant’). The page invited me to “get more details and information on our 508 Compliance, please click here!”. “Click here” link text is a failure of the most basic level of accessibility, and the link is broken.
Nitpicking, but Pat Lauke pointed out 508 still references WCAG 2.0, so the “new” 1.3.5 Identify Input Purpose from 2.1 isn’t necessarily covered by being “508 compliant”, although it is necessary for WCAG. Helpfully, Formstack also has a page Is Formstack WCAG Compliant? which doesn’t talk about WCAG at all, conflating it with 508.
This does not give me confidence that Formstack understands the accessibility requirements of the forms it generates.
Formstack claims that it helps you to “Create the frictionless digital experiences that employees and customers expect”, so it’s bizarre that it doesn’t allow you to integrate with autocomplete; when Google first implemented it in Chrome they found that “by correctly using autocomplete attributes on your forms, users complete them up to 30% faster“.
Of course, browsers will try to help out. Here’s Microsoft Edge valiantly trying to autocomplete a Formstack form:
Edge (which is based on Chromium) is packed full of heuristics which even employ machine learning to try to match the previously-supplied user data with the fields. Or, Formstack could simply add simple logic to their form builder so that if I choose a ‘name’ entry field, it adds autocomplete="given-name" to the relevant input field. Perhaps Formstack could expose an “advanced mode” in their designer in which you can attach arbitrary attributes and values to a form element. Until then, I don’t believe it’s possible to guarantee accessible forms if you’re using Formstack.
For humans, “don’t make me think” is a good design motto. For machines, it’s “don’t make me guess”.
Link of the Week: Navigation API: Accessibility technology announcements – a great discussion of accessibility features in the new Navigation API (that replaces the History API). This should ameliorate many of the woes that Single Page Apps cause screen reader users. Also, a great place to start if you don’t know why SPAs can be very hard for disabled users of Assistive Tech, if coded thoughtlessly and untested. Contains a useful Guide for migrating from the existing history API.
Who can you trust with your online business? asks Jason Grigsby. I’ve worked in many places with a hugely over-engineered tech stack recommended by Consultants that I suspect were secretly working for the clients’ competitors.
Autocomplete accessibility bookmarklet – “bookmarklet for testing WCAG success criterion 1.3.5 Identify Input Purpose (AA) which requires that if an input field requests personal information about the user, we must apply the appropriate autocomplete value to the field.”
Generic font families – “groups font faces into categories which could be considered as an initial set of new generics in CSS. The idea is that if you specify a generic font setting and there is a font on your system that belongs to that category, you would not want the fallback replacement font chosen by the browser to be from a different category”. By Richard Ishida
A bold new look for the GOV.UK homepage – Some of the most impactful UX/ web design work isn’t done with whizzy animations, or incredibly smooth SPAs. It’s done by better spacing boring old links and boxes. Thanks, gov.uk
The DMCC Bill: an appeal to common sense – Tom Fish, previously from the UK CMA, on how the GAMMA firms (Google-Apple-Meta-Microsoft-Amazon) are lobbying to hamstring the Regulator by introducing a procedural quagmire.
In order to avoid having Safari being deemed a Core Platform Service (and thus falling under the remit of DMA), Apple argues “Look, those Safaris on iOS, iPadOS, MacOS, TvOS, WatchOS are TOTALLY DIFFERENT PRODUCTS and none of them have enough users in the EU for you to even think about regulating us, alright? We’re a tiny start-up! Will nobody think of the children?!?”. (I paraphrase somewhat).
This is despite the DMA stating
An undertaking providing core platform services shall not segment, divide, subdivide, fragment or split those services through contractual, commercial, technical or any other means in order to circumvent the quantitative thresholds laid down in Article 3(2). No such practice of an undertaking shall prevent the Commission from designating it as a gatekeeper pursuant to Article 3(4).
The commission counters this claim (page 25, paragraph 115) rather deliciously. It notes that the argument put forward by the celebrated law partnership of Messrs Wriggle, Squirm and Weasel Esq. contradicts Apple’s own claims in 64px type: “Same Safari. Different device”.
Whatever Apple’s real reason for requiring all iOS and iPad browsers to use its own WebKit engine (and therefore be little more than a branded whitelabelled Safari), they claim it’s done to protect customer privacy.
we demonstrate how Safari allows a malicious webpage to recover secrets from popular high-value targets, such as Gmail inbox content. Finally, we demonstrate the recovery of passwords, in case these are autofilled by credential managers.
and notes
While iLeakage works against Macs only when running Safari, iPhones and iPads can be attacked when running any browser because they’re all based on Apple’s WebKit browser engine.
So if the iOS WebKit monopoly is for your comfort and security™, it isn’t working very well; the iLeakage bug was disclosed to Apple more than a year ago in September 2022. Another effect of this rendering engine monopoly (AKA #appleBrowserBan) is to inhibit the utility of Web Apps on iOS, because WebKit doesn’t implement certain vital APIs, and users can’t use a different engine.
This had led to the EU’s Digital Markets Act requiring that companies it deems “gatekeepers” can no longer do this:
43: In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.
In September, the EU announced Apple is a gatekeeper, and iOS is a Core Platform Service. The law will come into force in March 2024. We can expect Apple to attempt to wriggle out of anything other than malicious compliance via endless legal wrangling. Here’s a fascinating insight into the legal culture inside Apple, from an interview with Apple’s former General Counsel, Bruce Sewell:
If you can figure out how to get closer to a particular risk, but be prepared to manage it if it does go nuclear, then your company, think of it as a sailing metaphor, your company is able to sail closer to the wind than its competitors are. And that’s a real advantage … The reaction from Tim [Cook] was that’s the right choice. You made the best choice that you could with the information that you had. You didn’t know about these other things. Don’t let that scare you. I don’t want you to stop pushing the envelope because that’s why legal is an important function in the company.
Link o’the Week: Enhance Music — “a music library and audio player app built with HTML and CSS, and progressively enhanced with a couple pinches of JavaScript. Despite being built as a traditional multipage website, Enhance Music features an audio player that persists across page loads, and some gorgeous interactive UI built entirely with web standards.”
We Deserve Better from Apple: Why I Can No Longer Recommend a Mac to Fellow Blind Computer Users – “This critical problem has persisted for years across multiple MacOS versions without a permanent fix from Apple. Given the longevity and level of disruption caused by this bug across Safari and other applications, I can unfortunately no longer in good faith recommend Macs to anyone who relies on using VoiceOver.”
The modern CEO job is completely broken — but AI could make executives useful again – “We must hold CEOs accountable in the same way that we do their employees or dissolve the role entirely. A chief executive must meaningfully contribute in a way that is measurable and delivers clear value for the company. Failing that, I would argue that the opaque role of the CEO should be the first one to be replaced by artificial intelligence.”
At Barnardo’s, we have a very tight performance budget: All web pages on Barnardo’s products should be less than 100 kilobytes. (This is aspirational rather than a hard rule; as Big Al notes, “To serve users at the 75th percentile (P75) of devices and networks, we can now afford ~150KiB of HTML/CSS/fonts and ~300-350KiB of JavaScript (gzipped)”.)
So while I was prototyping a new project, I decided to use HTML popover to make a ‘lightbox’ when a user clicks on an image or video placeholder to make the media bigger and dim the page behind it. This isn’t quite ready for primetime yet, as it’s not implemented on Safari/Mac, and is still behind a flag in Firefox. But I wanted to kick its tyres because doing something declaratively reduces the amount of JavaScript, leaving more budget for actual content – you know, the thing that the user actually came for.
Also, it’s nice to use a new HTML thingie named after one of my favourite Soviet constructivist artists, Lyubov Sergeyevna Popova (Любо́вь Серге́евна Попо́ва).
As you can see from my popover demo page, it works splendidly for images, with no JavaScript required. Voiceover (on Chrome, as Safari/ Mac doesn’t support it yet) tells me the first image is a button (which it is; popover only works as an attribute on buttons) and that it’s collapsed. Hitting space tells me that the button is expanded, and pressing ctrl+alt+right focusses into the popover, which I can then explore. Hitting esc to dismiss it returns me to the ‘thumbnail’ button, which is announced as once again collapsed.
The video popover is more problematic. All works as expected, but if I start the video and hit esc or click outside the popover to dismiss it, the video disappears from view but the audio continues! Why does the Mr Astley audibly continue to reassure me of his undying devotion and, most importantly, why do those no longer-required bytes keep streaming?
The answer is that when a popover is dismissed, it is set to display:none. Whether the popover spec requires this, or whether that’s just the way the engineers decided to implement it, is unclear to me. You can check that this is how display:none behaves (outside the context of a popover) using this video of Mike Taylr’s legendary Don’t Stop, Donkey Punch video.
As I’m a good web standards wonk, I filed a Chrome bug. I accept that we can’t retrospectively change the behaviour of display:none, as that could break the web. And, as a Chrome engineer pointed out, “one can play audio (or video, e.g., to capture to a canvas) with an element that’s not even plugged into the DOM anywhere”.
So my question is really: should a popover dismissal invoke a special new display mode? display: unperceivable, or display: really-really-none or display: blackhole, or similar? I personally can’t think of a situation in which media showing in a popover should continue playing on dismissal. And if you did want that, you can do it with some JS flim-flam, just as we’ve made popovers for the last 250 years.
But if the point of a declarative standard is to reduce or remove the need for scripting for the most common use-cases, dismissing a video overlay/ lightbox/ popover should default to silencing it and stopping the data transfer, so 99.99% of authors don’t need to write that code.
Government Design Principles “The UK government’s design principles and examples of how they’ve been used.” There’s some great stuff in here.
Getting started with View Transitions on multi-page apps “The best part about MPA View Transitions, is that under the hood it’s just normal “dumb” page loads and we’re progressively enhancing our way into smart, sleek transitions all with zero JavaScript required.”
Where to Put Focus When Deleting a Thing – “TL;DR: When deleting something you should generally move focus to the prior equivalent control or its grouping container”, says glamorous Adrian Roselli
Safari is working on the Popover API, which is nice. Apple evidently want it to be a strong browser for when other engines are allowed to compete on iThings.
Talking of popovers, I found an interesting bug in display:none when looking at using popover as a lightbox for images and videos: Should AV content with display:none continue to play sound?. It seems to me that “display” refers to all perception/ senses. That is, if something is hidden from eyes it should be hidden from ears.
A few unpopular opinions about AI “The most dangerous prospect arising from the current generation of AI is not the technology, but the philosophy espoused by some of its technologists.” – similarly with cryptocurrency, which explains my deep queasiness about both techs.
I Blame the W3C’s HTML Standard for Ordered Lists – I can get unreasonably grumpy about standards, but this is God-tier: “Am I blaming the rise of fascism and the downfall of Western civilization on the W3C’s pig-headed and flawed implementation of the OL tag in HTML? A little, yes.”
On Friday, Vadim and I published episode 19 of our podcast, The F-word, with Léonie Watson as a special guest. Léonie is a web standards mover and shaker, a business owner, a total grooving cat, and also a screen reader user.
Some of her top tips for making sites accessible:
HTML5 introduced a whole bunch of elements nav, main, header, footer, aside and such. And from a screen reader user point of view these were one of the most amazing strides forward I can remember coming across.
Should you have very terse, or detailed descriptive alternate text for images? Léonie says,
Not everybody wants to listen to that detail, but you don’t have to listen to it. If it’s there, you can skip past it, or you can stop and listen to it. If somebody decides not to put it there, that choice has gone right out of my hands.
On ARIA:
should you be using ARIA at all? Because from experience the answer is almost always probably not. I’ve probably seen more websites brought down by using ARIA than I have made better for it. To be honest that’s probably one of the biggest accessibility problems I come across … you’ve got to use it sparingly and thoughtfully.
(This isn’t to say that ARIA is always bad. The W3C Using ARIA spec’s first rule of ARIA is “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so“.)
What’s the biggest accessibility bang for the buck a developer can achieve?
start off with just good quality code. That’s by far and away the best thing you could do for accessibility, especially screen reader accessibility. Screen readers are absolutely dependent on plain old semantic HTML. Divs and spans are our absolute worst thing you can do to us because they’re meaningless.
There you are! Use the right HTML elements for the job. There’s loads more nuance and InfoNuggetz™ in the podcast transcript.
I woke this morning to the news that Molly Holzschlag is dead. I can’t remember how I first met Molly. It feels like I’ve known her since I started working on the Web. She was definitely one of the people who helped me with the CSS for this very site when I made it in 2004 (she emailed me the code to centre the ransom note logo: .header img {margin: 0 auto;}; there was no social media back then).
Here we are at @media conference in London in 2005:
We co-edited a book together. She was perhaps the only person who could persuade me to go on stage with her at a conference dressed as a cowboy. She came to stay at my house, we got riotously drunk and she threw up on my guest bed. We fell out for a while when we both worked at Opera (about the WebKit engine, ridiculously but so typically). I suspect one team wasn’t big enough two Jupiter-sized egos. We made up again, at Future Insights 2014 in Las Vegas, and celebrated by getting so drunk I lost my laptop so we retraced our steps through the bars we could recall visiting, before I remembered I’d left it on my hotel bed.
And that was the last time I saw her. We stayed in touch occasionally after her illness; her last email was some gossip and backstory on persuading Bill Gates that web standards are good idea. She sent it to me after watching a video of me talking about Open Web Advocacy‘s efforts to end the Apple Browser Bans, which she cheered from the sidelines. Perhaps I’ll include some of it if I ever reprise that talk.
As the announcement in the Tucson Sentinel says
She was steadfast in her insistence that the World Wide Web be usable by disabled people, including sites being able to be parsed by screenreader technology for people with impaired vision.
I was about to type “rest in peace”, but Molly was Jewish, and Jewish chums tell me that the phrase “may her memory be a blessing” is more appropriate. But I think she would prefer “may her teachings about an open, inclusive and humane web be passed on”. They will be.
