Archive for the 'accessibility web standards' Category

TC39 – the song

For my first conference after joining Vivaldi a week ago, I travelled to Amsterdam to help MC the JSNation conference. Naturally the opening ceremony required a JS Pop group (a sub-genre of K-pop) doing a carefully choreographed dance routine and lip-syncing to a song.

Here’s the TC39 group in front of the river. Left to right are Phil Nash, me, Niall Maher and Floor Drees.

4 gorgeous people in colourful jumpsuits and marching eyeglasses

And here we are, captured at the end of our routine with the letters “TC39” on the back of our suits. There were over a thousand attendees, and not a dry seat in the house.

4 gorgeous people in colourful jumpsuits on stage with letters on their backs

Here’s the song what I wrote, for your listening pleasure. (Afficianados will note that I have deftly re-purposed the tune of Saperlipoppete, the Eurovision smash I wrote for the transnational supergroup Deluxembourg.)

the cruellest months · TC39

I get so excited writing JavaScript
I’m pretty easy-going but now I use Strict.
When I first began I was in callback hell
But then I met you and now it all goes well

I love you when my tests pass
Meet me in the moonlight and extend my class.
You’ve always kept your Promises from the start
Now you’ve shot your fat arrow straight to my heart

Oh TC39, I’m so glad you’re mine!
Say you will be with me til the end of time!
Oh TC39, you’re so sublime.
Your specs are the best, my TC39!

(More of my slightly less-daft music by the cruellest months)

Joining Vivaldi

Today is my first day working at Vivaldi, the browser people (many of whom I know from our time at Opera before it changed hands). I shall be working as a Technical Communications Officer, helping out with blogposts, journalist enquiries, and regulatory fun.

Because of the latter aspect, I’ve resigned from the Board of Open Web Advocacy. OWA has always been a group of independent web developers with no skin in the browser game other than the wish for the Web to reach its full potential, and be a true competitor to Single-Platform Apps. I don’t want any of Big Tech’s army of lawyers pointing at OWA and saying “look! Bruce works for Vivaldi, so OWA are a shill for, er, Big Little Tech!”. Needless to say, I am still whole-heartedly a supporter of their aims, and will amplify their voice.

Knowing the core team at Vivaldi of old, I don’t expect my job title to constrict what I actually *do*; I’m attracted to working with them because it’s a non-hierarchical company that believes in self-organising and collaboration. One of the guiding principles is “Respect each other, question everything, be creative and get things done”.

I’ve also been a Vivaldi user for a few years now, and like that they don’t snoop, and that there is no bundling LLMs/ “AI” or crypto-crapto in the browser. Vivaldi is owned by its employees (all of them, including cleaner and office manager) and has no external investors, so there’s a good chance of keeping that culture.

Don’t ask me too many hard questions yet; it’s been eight years since I was working in browsers, and there’s a lot to catch up on. Lately I’ve grown jaded about the Rube Goldberg machine that is modern web development; I’m sick of Docker and node dependancy nightmares, silly CSS dialects to shield “full stack devs” from understanding how to style web sites, creaky old component libraries and over-hyped frameworks that seem to be designed to make it harder to send performant, accessible HTML to users.

So I’m looking forward to returning to BrowserLand, Web Standards World (wouldn’t those be great theme parks?) and extending the reach of the greatest democratising communication system ever invented, while prising as much of it as possible out of the clammy hands of Big Tech and Vulture Capitalists.

Reading List 320

Indian Big Tech draft regulation makes Big Tech bosses cry scandal

I hope you’re sitting down, because Reuters reports that Google, Amazon, Apple lobby group opposes India’s EU-like antitrust proposal:

A U.S. lobby group representing tech giants Google, Amazon and Apple has asked India to rethink its proposed EU-like competition law, arguing regulations against data use and preferential treatment of partners could raise user costs

The proposed Indian legislation (PDF) is “much further in scope” than the EU’s, according to a tear-stained letter sent by the U.S. Chamber of Commerce’s U.S.-India Business Council to India’s Corporate Affairs Ministry.

Reuters explains

India’s “Digital Competition Bill” is on the lines of EU’s landmark Digital Markets Act 2022. It will apply to big firms, including those with a global turnover of over $30 billion and whose digital services have at least 10 million users locally, bringing some of the world’s biggest tech firms under its ambit.

It proposes to prohibit companies from exploiting non-public data of its users and promoting their own services over rivals, and also abolish restrictions on downloading of third-party apps.

Cynics might suggest that US Tech regards India as a potential sacred cash cow, given that its home markets are becoming saturated and China is notoriously harder to operate in. Reuters points out

With a population of 1.4 billion people and a growing affluent class, India is a lucrative market for big tech companies. Apple CEO Tim Cook said this month the company posted a “revenue record” in India during the March quarter, when its overall global revenue declined 4%.

The U.S.-India Business Council (whose directors include representatives of such trusted organisations as Boeing, Lockheed Martin, Meta, Google and Amway) is, of course, only thinking of Indian consumers:

“Targeted companies are likely to reduce investment in India, pass on increased prices for digital services, and reduce the range of services,” it says.

Naturally, that’s not to be interpreted as some sort of threat. Nope, that’s beloved captains of US Capitalism throwing their collective benign arms around Indian consumers, protectively. A heart-warming story for today’s troubled times.

CSS :has(), the God Selector

Probably everybody knows this, but I didn’t and in case you don’t, here’s why the CSS :has() pseudo-class is omnipotent and so awe-inspiring I call it the God Selector.

I was working on a no-JavaScript fallback for a mobile hamburger menu, using the newly-baseline HTML Popover API. For users without JavaScript (and, yes, there are many), the code looks like this:

<header>
<a><picture> <!-- Logo homelink --> </picture></a>
<button> <!-- big fat CTA --> </button>
<search> .. </search>
<button popovertarget="narrowscreen-nav">Menu</button>
<nav id="narrowscreen-nav" popover> ... </nav>
</header>

I wanted to give the button a different style if its associated popover is shown. There is no pseudo-class for button:pressed (which is why some people like the checkbox hack, which is clever but has the wrong semantics. And, anyway, popovers can’t be triggered from inputs).

There is, however, a pseudo-class to tell you if a popover is open: :popover-open. Now, to find a way to style the button element by targetting this aspect of its associated (but not descendant) popover target element.

Sometimes people called :has a “parent selector”, but it’s not only that. I knew that it could “reach out” and look at siblings etc if there is the necessary CSS combinator. This selector worked for my code:

button:has(~nav:popover-open) {background-color: goldenrod;}

However, I wasn’t happy about it; what happens if the nav ceases to be a sibling (as it soon did, because I needed a wrapper around the stuff before the nav, to lay it out using Flexbox)? I tend to dislike handing code over to clients that has a very tight dependancy on exact markup structure.

Luckily, I had a conversation with the splendid Luke Warlow of Igalia (a free software consultancy/ hippie commune who do loads of work in all the browser engines), and he blew my mind. It turns out I was thinking about :has the wrong way round.

Behold the almighty God Selector:

:has(nav:popover-open) button[popovertarget] {background-colour:goldenrod;}

This is omnipotent because it doesn’t require any structural relationship between the thing being checked and the thing being styled. The first bit of the selector :has(nav:popover-open} doesn’t have a class, ID or element name, so is scoped to the root of the document. That’s the thing being checked: is there a nav that is an open popover anywhere in this page?

The second part of the selector is the thing to be styled, which is a descendant of the root – and, of course, everything on the page is a descendant of the html element, which is the root. Think of the selector as html:has(nav:popover-open) button[popovertarget] if that makes it easier to reason about.

Of course, you can narrow it down to hone in on the exact nav or button you’re interested in. For example,

header:has(nav:popover-open} button.letsBeSpecific[popovertarget] {background-color:goldenrod;}

And now, I’ve used the God Selector in three different places in the same stylesheet already, to achieve an effect I could not have done without handing over markup of much greater fragility. Thank you to the Mighty Luke Warlow, and I’ll have a kilo of whatever goes in the Igalia bong.

Reading List 318

Reading List 317

Reading List 316

Drive-by accessibility tweaks

Sometimes, if I’m fixing an unrelated bug I spot the opportunity to make a quick “drive-by” accessibility tweak that is quick and easy and will give a disproportionately big boost to the user experience for people with accessibility needs.

Here are some of my top faves (number 3 will have you in tears!). Your mileage may vary, of course, depending on your codebase and conventions.

Replace meaningless divs with landmark semantics

In some codebases, I see lots of HTML festooned with classes, which are used to style the element rather than apply styles to the element directly, so <div class="header"> and a CSS rule .header {display:block; color: goldernrod; …} instead of header {color: goldernrod; …} as Sir Uncle Timbo intended.

This allows me to change it to <header class="header"> with no need to rewrite the CSS, and assistive technology users get information and navigation assistance from the semantic of header (whereas div is meaningless).

If your codebase is similarly styled, you can do this with nav, main, footer too; my article The practical value of semantic HTML explains the benefits.

I often add a <search> element too, if the JS/ ARIA labyrinth isn’t too deep.

Make in-page links more accessible

Another sneaky quick win involves adding tabindex=”-1″ to the target of in-page links, so focus isn’t lost after the link is followed.

So if you have <a href="#mainContent">Skip to main content</a> in your page (and if you haven’t, why not??) the target of that link needs a tabindex:

<main id="mainContent" tabindex="-1">

I had thought this problem had gone away when Internet Explorer was laid to rest, but no.

Replace JS accordions with HTML

Depending on your codebase, this may not be as easy. But there are literally 735 trillion sites (and crusty old libraries and creaky tutorials ) that still use cobwebby JavaScript to make accordions and similar disclosure widgets, with fragile ARIA and focus management.

For years, HTML <details> and <summary> just do it for you, managing roles and states for free without any JavaScript, and they work everywhere. You might have to get more creative if you need an animated arrow (can you imagine the shame of a disclosure widget without an animation?!?) but it can be done.

You can also consider replacing your Penny Farthing JavaScript dialog boxes and popovers with HTML <dialog> which works everywhere and (soon) the HTML popover attribute and associated API, and get all your focus management, roles and states and z-index shenanigans handled by the browser for free.

Remember, kids: built-in beats bolt-on. Bigly. Happy drive-by accessibility tweaking!

Apple’s new Core Technology Fee is a Core Technology Fleece

At the recent EU-organised workshop, Apple explained its proposals for its compliance with the Digital Markets Act, and took questions from developers. One developer, Riley Testut of AltStore (which has announced it will be a third-party app store in the EU) asked an interesting question about Apple’s new Core Technology Fee. He noted that the free open-source app he made and released while at High School would have put him in 5 million Euros of debt to Apple under their new fee structure, even though it was not distributed through its AppStore.

Apple’s lawyer made soothing noises about Apple wanting to support “the dreamers” and to “stay tuned”, presumably for any exceptions Apple may graciously bestow on such developers.

But it made me wonder: what is the Core Technology Fee actually for, if a developer makes an app and distributes it outside the AppStore? So, I asked:

A developer who wants to make an iOS app must do it on a Mac; these are not cheap, and only available from Apple. You’ll need an iPhone to test it (the xcode simulator won’t allow you to check accessibility with Voiceover). You’ll probably want an iPad, too – bafflingly, apps can work on iPads too, even though iOS and iPadOS are completely different operating systems (according to Apple).

A developer license costs $99 per year (although it’s unclear to me if you actually need one if you’re not uploading your app to the AppStore). And if a consumer wants to download your app, they will need a shiny iThing, which they’ve bought from Apple at a premium price, precisely to reimburse Apple for the core technology it contains. Would anyone buy an iPhone if there were no apps available?

So I don’t buy Apple’s argument that developers must pay them for the core technology that the iPhone user has already paid them for. And I wonder if the EU believe it, either; EU antitrust chief Margrethe Vestager said after the workshop

There are things that we take a keen interest in, for instance, if the new Apple fee structure will de facto not make it in any way attractive to use the benefits of the DMA. That kind of thing is what we will be investigating.

To quote Apple’s legal team: stay tuned.