If WCAG 3 would adopt the word “view” instead of “web page”, the standard would be more useful in non-web contexts like native apps, documents and XR. Because many wish to understand how accessible such environments are, we should consider adopting a unit that isn’t “web page”. To me, “view” is the strongest contender.

Context: as part of the Accessibility Guidelines Working Group (AGWG) work on WCAG 3, I'm leading a subgroup on (re)defining “views” for WCAG 3. This group builds further on a discussion at TPAC 2024, which builds on discussions over many years about WCAG and WCAG2ICT. Opinions in this post do not reflect those of the subgroup, or of my clients.

I would love any feedback in wcag3/discussions/286.

The web page

In WCAG, and most WCAG-related documents, the notion of a “web page” does quite a lot of work: it's in the name of some success criteria and it's WCAG 2's “unit of conformance”, i.e. the thing people can claim conformance about.

A web page, in WCAG 2, is unambiguously scoped to something to obtain from a single URI:

a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

It's so unambiguous that we'd struggle to come up with examples where one person would draw the boundary between two web pages differently than the next. Well done, team WCAG!

Inevitably, though, a unit of conformance that can apply more broadly will be more ambiguous.

In other places

No less than 16 success criteria in WCAG 2.2 mention web pages: 1.4.2 Audio control, 2.1.2 No keyboard trap, 2.3.1 Three flashes or below threshold, 2.3.2 Three flashes, 2.4.1 Bypass blocks, 2.4.2 Page titled, 2.4.3 Focus order, 2.4.5 Multiple ways, 2.4.8 Location, 2.5.6 Concurrent input mechanisms, 3.1.1 Language of page, 3.2.3 Consistent navigation, 3.2.4 Consistent identification, 3.2.6 Consistent help, 3.3.4 Error prevention (legal, financial data) and 3.3.6 Error prevention (all).

It's also used in documents like WCAG-EM, the evaluation method.

Conformance

“Web page” is WCAG 2's “unit of conformance”, meaning that if you want to say something “conforms” to WCAG, that something should be a web page, and not something else, like a date picker component that you've built. You can use WCAG to reason about the accessibility of that date picker component, but a claim that it conforms to WCAG would not make sense.

Note, the phrase “unit of conformance” isn't actually mentioned or defined in WCAG itself, but WCAG2ICT explains it clearly:

(…) the unit of conformance in WCAG 2 is a single web page (…)

(From Interpretation of Web Terminology in a Non-web Context)

Conformance claims are also specifically about full web pages, not parts of them. They can be about more than a single page, though:

a conformance claim may be made to cover one page, a series of pages, or multiple related web pages.

(From: WCAG 2.2, section 5.3: conformance claims)

That's common too: in fact, accessibility conformance reports usually cover a whole website.

Views

“Views” could be a new unit to use, meaning web pages on websites and other things in non-web contexts. View are not defined in WCAG 2 (they are in UAAG and in ATAG, interestingly, and a 1999 doc defines “page view”). The latest WCAG 3 draft also has a definition for view, we'll get to that later.

Views as a unit of conformance for WCAG have been considered before, most nobably in the WCAG2ICT groups, see for instance the discussion in reply to the concept of User Interface Context. In all those years, the group could not think of a definition that wouldn’t introduce problems of its own.

Has anything really changed since then? Well, one thing that is different now, is that we have more variety in products that need accessibility conformance evaluated than ever. There seems to be a growing desire to bring our units of conformance up to date with that reality. It would make conformance assessments more practical to their writers and readers and simplify monitoring by governments.

I feel the balance between theoretical purity and practical need has shifted.

Requirements for a new definition

When we set off thinking about views, we discussed requirements, including that we want “views” to:

• Not confuse people who have an existing understanding of the word ‘view’, which is a word used by many, including developers (like views in React Native, views in Django, views that CSS view transitions transition and views in MySQL)
• Not reduce accessibility requirements: a new definition shouldn't cause things to meet WCAG that don't today.
• ‘Work’ for a variety of different contexts, like web pages, (native) applications, VR/AR and documents (I know, a long wishlist)
• Useful for people who do conformance assessments (accessibility specialists/consultants), or use them in some way (designers, developers, monitoring agencies, judges in some areas).

Steve Faulkner's suggestion

As mentioned, there is an existing draft definition in the latest WCAG 3 draft. I agree with Steve Faulker that it is wooly.

What the exact definition needs to be is yet to be determined, but after the initial (less-wooly) definition we presented to the Working Group, Steve proposed to base the definition around “change of context”.

Steve's proposed definition:

Conformance scope that includes all content visually and programmatically available without a change of context

In addition, he suggests updating “change of context” to be:

Major change in the content of the view that, if made without user awareness, can disorient users who are not able to view the entire view simultaneously

Changes in context include changes of:

• user agent;
• viewport;
• content that changes the meaning of the view.

A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, opening a non-modal dialog, or a tab control do not necessarily change the context.

Example: Opening a new window, opening a modal dialog, going to a new view (including anything that would look to a user as if they had moved to a new view) or significantly re-arranging the content of a view are examples of changes of context.

I like where that is going.

Needless to say, I don't think anyone envisions this to be a find/replace in all documents that mention “web page” today.

Subviews?

Sometimes it makes sense to talk about specific parts of a UI or view, like a modal overlay, drawer or full screen search functionality. We looked at a number of examples within the group and found we were internally conflicted about some cases, there was a lot of gray area.

For this reason, I think we should in fact not define “subview”, contrary to what we intitially thought. I'd love to know what others think, please add your thoughts to the subview part of the discussion.

Possible issues

There are some disadvantages to “view”, and we got some excellent feedback from the Working Group in our initial discussion. You can see all in the minutes of 18 February, but I'll highlight two here.

More subjectivity

Among the feedback we got from the Accessibility Guidelines Working Group, was Gregg Vanderheiden's feedback that I'll summarise as: “web page“ is objective and “view” is not.

I think he's technically correct that we lose some objectivity. But I don't think that's as much of a change to the status quo. Accessibility practioners define scopes for tests today already, and, if we're honest, subjectivity already exists in accessibility conformance reports. Bad actors can act bad today, that's not a reason to avoid making things more usable for all actors. Especially if a new term would help with clarity about accessibility or inaccessibility of products.

Besides, the cat is out of the bag already: companies and governments need other environments than web apps assessed, and whether they do that with an unambiguous but inapplicable definition for “web page” or with a broader definition for “view” is unlikely to make the difference.

In app development

In native app development, a world I’ll admit I’m not very familiar with, the word “view” seems to refer not to a whole screen or page, but to parts of it, as I understand similar to what on websites, you’d call components. I learned this when I presented some of these ideas in the Mobile Accessibility Task Force (MATF), where “page” was offered as an alternative to “web page” that could work as a unit of conformance for (native) apps.

This may get into “confusing people with existing definitions of view” territory, I am not sure what's the best way out, I worry “page” could introduce similar problems in terms of future proofing. A potential solution, from Jan Jaap de Groot, could be that a different word than view is used in a document like WCAG2Mobile, which then points at WCAG's “view” for the definition. Others I talked to suggested something similar, we could have different units of conformance for different contexts, that all point to one broader unit.

SC meaning

One issue that we didn't get to much, but that is essential: what about all the SCs that mention web pages today? The published note WCAG2ICT covers mappings from “non-web software and documents” to WCAG 2 success criteria and EN 301 549 (clause 10 and 11) harmonises with that. Mapping is not be in the scope for the task of defining “views” per se, but it deserves our attention to consider what requirements would look like if we used a word like view.

Feedback wanted

In this post, I've tried to summarise some of the discussion around “view“ it happened over the last few months. It's a lot of information, with one goal: please share your thoughts.

It doesn't have to be “views”, it could be “purple zebras”, as Alastair suggested, but modernising what WCAG's unit(s) of conformance are will be more helpful to users than avoiding it.

I'd love more feedback (by email or in the GitHub discussion) on what views can be and what the potential risks are, especially from accessibility practitioners (including evaluators), folks from monitoring agencies and designers and developers who want to meet WCAG.

---

Originally posted as Views on views on Hidde's blog.

Reply via email

It's only a few days until 2025. That means one thing: it is time for my yearly tradition of reviewing… some of my year. I'll cover work, conferences, reading, writing and music.

This will inevitably sound cheesy, but I am once again genuinely grateful for the opportunities I got… there were fun projects at work, I got to see some of my dearest artists live and I got to share knowledge and opinions at events among some of my favourite peers. At the same time, the last few months have, honestly, been intense, and I am looking forward to take a few breaks in January.

I also can't not mention politics. I saw a number of sad elections results. I saw people chose to vote, basically, against other people. It was heartbreaking to see people vote against women, against trans people, against people who crossed borders, and also against the odds for humans to inhabit this planet… and some major tech leaders chose to embrace, encourage or cheerlead that. Booh.

Some say one should focus on things one can impact. I'm not always good at that, but I'll do it now, by sharing a bit more about my year in terms of projects, conferences, reading and listening.

Projects

I spent most of my time on two projects for the Dutch government: NL Design System and the digital accessibility (standards) team at Logius.

At NL Design System, I got to organise another Design Systems Week, and worked on accessibility testing, guidance for forms and WCAG (both in Dutch), communication strategy, events and our website. At Logius, I worked on growing our participation in international standards discussions, specifically accessibility standards like WCAG and EN 301 539, at W3C and ETSI. It's been really cool to get back into familiar groups and join new ones (like the TC and JTB; yes I learned new abbreviations why).

Next year I'm increasing my time for standards at Logius, which, sadly, also means I'm leaving the NL Design System team.

From February, I'll have some availability for new projects, too: ~2 days/week to work on accessibility, frontend and/or design systems, do get in touch if you can use help.

Conferences

It's been a very busy and very fun year in conferences (I recommend going to conferences, for all reasons Sophie outlines in her post You should go to conferences).

Some talks I liked:

• The art of reflection by Imran Afzal at All Day Hey
• Feminism in programming language design (start at 20:50) by Felienne Hermans at Joy of Coding
• The many lives of a notification by Sarah Highley at Accessibility Toronto

I loved speaking at a number of them, too. I got to meet new people in the industry and hang out with friends. Even if it is nerve wracking at times, it gives me a lot of energy.

Creativity, art and AI

In October, I presented a new talk called Creativity cannot be computed at Beyond Tellerrand in Berlin. I talked about what's great about arts and creativity, in the context of our industry's tendency to leave stuff to computers. I love computers and art both, but we've got to prioritise. Some of this has been in my head for the last decade, and I loved to hear how it resonated with people in conversations after (maybe partially because I can't seem to shut up about it, sorry to all affected). I plan to write more about art and AI on my blog, but you can already read along with the slides or watch the video.

Acccessibility

Another new talk was Built-in accessibility: blessing or curse, which combined some of my earlier talks on tooling, browsers and CMSes with what I learned about design systems at NL Design System, all to uncover a general theme: that building in accessibility is not a one size fits all solution, but when done right, can be a sound part of your accessibility strategy. I gave this talk at A11y Club Amsterdam and at Accessibility Toronto.

Popovers

Earlier in the year, I did the most northern iteration of my popover talk (video) at All Day Hey in Leeds. I was very happy how it turned out and it was great to visit this city and this event that I had heard so many good things about.

My shortest talks were at Joy of Coding in my home town of Rotterdam, where I spent 5 minutes rambling about software and accessibility, and Mozilla's performance.sync() meetup in Amsterdam, where I talked about Open UI and reducing bundle size.

In the next year, I'd like to talk about web sustainability more, and continue to cover accessibility, design systems and AI/art.

Reading

I read some books this year, two of my favourites were:

• Character limit: how Elon Musk destroyed Twitter; a lot of the shocking facts in this book were public knowledge already, but Ryan Mac and Kate Conger did a wonderful job telling how the events unfolded, the details make one fear a world in which Elon Musk has any influence.
• Against technoableism: : seeing people with disabilities as an “inspiration” or needy of technological “fixes” is problematic, this book explains why.

These blog posts from others are among favourites this year:

• Coming Home by Mandy Brown
• Generative AI is for the idea guys by Rach Smith
• The Dilemmas You'll Face When Creating a Component Library by Andrico Karoulla
• We have a content quality problem, not a content quantity problem by Cory Dransfeldt

Music

Three albums that came out in 2024 that I liked:

• Odyssey by Nubya Garcia (jazz saxophone with orchestral arrangements, vocals and more).
• Lives Outgrown by Beth Gibbons (of Portishead fame, it grew on me).
• Drop 7 by Little Simz (hip hop, it feels more free and experimental than her previous work).
• IJsland by Abel & Sef (Dutch punk hip hop that I loved almost instantly).

In live music, it was a good year… I stayed on top of who's touring and ticket acquisition, and managed to see many faves. Most liked: IJSLAND, Massive Attack and Robert Glasper. I also made a point of going to see stuff when traveling, a tradition I hope to keep, though it gets expensive when traveling outside of Europe and its subsidised cultural venues.

In music making: I am picking up playing piano again and have joined a choir, which has been on of my best decisions, it is so much fun. As usual, I should have listened to a friend's advice earlier.

Writing

With 10 posts in total, I didn't write as much on this blog in 2024. I don't know which were most read, but these got some good feedback:

• On popover accessibility: what the browser does and doesn't do (co-written with Scott O'Hara)
• “AI” and accessible front-end components: is the nuance generatable?

Cities

Outside The Netherlands, I spent time in Duisburg, Berlin, Taipei, Tainan, Kaohsiung, Brighton, Antwerp, Paris, Leeds, London, Bad Schandau, Brussels, Los Angeles, Toronto, Liverpool, Vienna.

Self study

I did a bunch of self-study:

• Josh Comeau's The Joy of React. It was indeed joyful, and the most down to earth overview of React I've seen so far.
• the IAAP certification exams. I'm now a CPWA, which is both WAS and CPACC. I have more to say about this, maybe some other time or 1:1.
• I worked with Melinda on specific parts of my public speaking, I would absolutely recommend her to anyone looking to learn.

Wrapping up

I wanted to write up some resolutions for the next year, but I ran out of time. I guess I'll leave it, as a resolution itself, for the next year. If you're reading this, I wish you all the best for the new year!

---

Originally posted as What I got up to in 2024 on Hidde's blog.

Reply via email

Generative AI features have a large climate impact and water consumption. We can weigh that impact against those features' benefits, but what if they are left unused? If lots of people don't in fact use the thing? That seems like lots of avoidable waste. Which matters, we're in a climate emergency and we're dangerously far from that 1.5 degrees target.

I know, we all want people to use features we build, but it is safe to assume they often don't. For my business, I use a lot of very beautiful self service portals that I only ever log in to, to download a PDF that my accountant needs. The beautifully considered UI, fancy spinners and clever copywriting are there, but if I'm honest, I mostly ignore them (sorry).

Is that ok? A button in your app that your user doesn't press, wastes little energy. But if your app automatically generates summaries, captions or suggestions, and the user didn't want or use that functionality, a lot of energy and water was wasted. While serving no purpose. It's that combo of waste and purposelessness that we should avoid at all times.

Wait, that's absurd, you say. Does this really happen? Yeah, I come across it all the time, and it's not just because I'm somewhat of a luddite myself.

Features I didn't use

Some examples of AI features that ran on my behalf just in the past week, but that I didn't use:

• Loom's transcripts and automated titles and descriptions. They show up almost instantly after upload. I always remove them, they fail to get the point across, which I want to do pointedly to save colleagues reviewing a video time.
• Parabol's automated summary of team retrospectives: it emailed us key points, some incorrect. While we had written them down correctly already.
• Notion's AI assistance that shows up whenever you press ‘Space’. Ok, granted, it only runs once you've actually typed a prompt, but it's a good example for this post, as it's one of those I hear many people want to turn off, and you can only do that “on Enterprise“, according to this Reddit topic dedicated to turning that feature off.

Of course, these features are not redundant if users benefit from them. But let's be real, oftentimes users didn't want to generate anything. It happened anyway, and was unsolicited. They will probably discard of the output. In those cases, the energy-intensive feature was redundant. And that's an issue, as we don't have redundant energy.

Meanwhile, most major tech companies announced they are letting go of their net-zero goals. Some have bought nuclear power plants to cater for their energy needs (see Microsoft's plans with the Three Mile Island plant). This confirms to me that we don't have abundant energy. Maybe one day, but not today.

An ethical web

Is this ethical? The W3C's Ethical Web Principles have a specific principle that applies here: 2.9 The web is an environmentally sustainable platform.

It suggests new technologies should not harm the environment:

We will endeavor not to do further harm to the environment when we introduce new technologies to the web (…)

and recognises people who benefit are not always those who are harmed:

and keep in mind that people most affected by the environmental consequences of new technologies may not be those who benefit from the features introduced.

If a feature is useful for some, but indirectly causes the energy or water bills to go up for others, we're breaking this Ethical Web Principle.

Conclusion

So, I'm just a guy sitting behind a keyboard, begging anyone including generative AI features: only put them to work when users indicate they want that to happen. That's also going to turn out cheaper when OpenAI increase their rates, which is likely as investors are going to want returns. Why not consider leaving out that new LLM-powered feature in the first place: not everything needs to be “artificially intelligent”, sometimes a bunch of if statements make a killer feature (dude, that's so paternalistic and you're oversimplifying the realities of software engineering, you say… yeah, sorry, I'm trying to react to the overcomplexification that also happens).

Do you have other examples of software that forced LLM generated content on you? Let me know and I'll add them to the post.

Further reading

• Thinking about using AI? Here’s what you can and (probably) can’t change about its environmental impact by the Green Web Foundation
• AI’s Growing Carbon Footprint (cites data centres account for 2.5-3.7% of global greenhouse gas emissions, exceeding aviation)
• We’re getting a better idea of AI’s true carbon footprint
• Is generative AI bad for the environment? A computer scientist explains the carbon footprint of ChatGPT and its cousins

---

Originally posted as Turn off AI features by default (to reduce their climate impact) on Hidde's blog.

Reply via email

Taking the train for work travel can cost more time than going by car or plane. But it's one of the most energy efficient ways to travel, and I get this weird productivity boost from them.

Note that you can absolutely also chill out, read, sleep or listen to music on trains. I like that too, sometimes. But this post is about when I use train time to work. In Europe.

Enjoy the benefits

As mentioned in the intro, a major reason for my traveling by train is the low environmental impact (relatively, and apart from not traveling). I travel a lot for work, so my impact is relatively high, especially when I don't manage to avoid planes. Despite doubts about effectiveness of compensation, I do compensate in various ways, but it still doesn't feel great, avoiding is ideal.

Trains also offer a productivity boost. If you're forced to be in a seat, on a connection too unstable to take work calls, this presents an opportunity. An opportunity to get things done (no I am not for hire as a productivity coach).

gitI don't know what it is about trains, but I really find the time flies when I have something specific to write, code, or design. Trains have proven themselves as great offices to me. I don't know if I can convince my bookkeeper that train tickets are in fact office rental costs, but do you see how they can feel like that?

There are some more benefits to trains:

• good views. Depending on your route and time of travel, there's always plenty to see outside. Sunrise and sunset are particularly nice.
• arrival in central locations. European train stations are usually close to where the fun happens.
• less checks. Within Schengen, international trains usually don't have border checks or luggage checks, so there's a lot less hassle and queuing, you can show up and go.

Embrace the caveats

Things can go wrong, too. Like with any kind of travel.

Delays

If your international train has stopovers, delays can be a headache. Especially between train companies. Plan for stopover time and consider flexible tickets for onward journeys. And stay calm: it happens. Also, in Europe, you have lots of rights re train delays and will have travelled partially for free when delays happen.

Data

Large parts of Europe don't have stable mobile data, especially outside cities. Or, depending on your plan, you don't get a great connection roaming. Have some of your work available offline so that poor connection doesn't interrupt you. Know which web apps to trust (the progressively enhanced parts of GitHub are the best).

Power

Not all power outlets will work, so I follow the ‘ABC’ rule: Always be charging when you have the opportunity, so that batteries are full and ready to go when you don't.

In conclusion

Trains are nice, and their benefits outweigh the caveats, especially if you anticipate those in advance. I'm curious if people have found other benefits or caveats regarding taking the train for work. What's exciting you or holding you back? Feel feel to reply by email or via Mastodon or Bluesky.

---

Originally posted as Trains are offices on Hidde's blog.

Reply via email

Yesterday, I was at State of the Browser in London. It was great to catch up with friends and make new ones, and the talks were once again very well curated. In this post, I'll share some notes from the day and the takeaways that stood out to me the most.

The Barbican tube station

Think about funding the web ecosystem

Stephanie Stimac kicked us off with a brilliant talk on how to fund the critical infrastructure that is the web ecosystem. We couldn't browse the web without browsers, and they wouldn't exist without engines, that are hard to make, and to fund. In the current model, browsers get large amounts of money from search deals. For instance, in 2021, Google paid almost 20 billion (not a typo) to Apple to make its search engine the default (but a US federal judge ruled that such payments unlawfully limit competition). It's a lot of money, but as that money goes primarily to the browser companies, not the engines, and may go away if search deals are deemed illegal, we need to think about new ways to fund browser engines, Stephanie urged us. They could include donation based systems, tax breaks or a Web Levy. For more context, see Stephanie's slides and in the comments of w3c/breakouts-day-2024#20.

Participate in accessibility standards

Next up was fashion designer and web accessibility advocate Steve Faulkner. He shared some of his own web standards stories and gave practical tips around how to participate. Without naming (many) names, Steve very accurately explained some of the different types you'll find in standards meetings: there are well-meaning, argumentative, axe to grind, practical, clueless, old school, helpful, true-believing, revisionist and lurking type of people. There are a number of ways people do participate: you can file issues (like in w3c/wcag), comment on issues, file PRs, comment on PRs, join a Community Group or join a Working Group. Only for that very last one, you actually need to represent a W3C Member. What you do need to do, Steve warned, is to know when you don't know. It's fine to just listen before having strong opinions. Now, starting to participate can be hard and/or daunting, so to anyone reading this: feel free to slide in my DM/email, we can (always) use more perspectives.

Different types

Advocate for the open web

Stuart Langridge shared the story of how he and others at Open Web Advocacy ended up talking to regulators about anti-competitive behaviour in our industry, including the fact that iOS doesn't allow for other browsers than Safari. Their work has had an enormous impact, as it helped regulators understand the nitty gritty details of what they were regulators. “The web is ours”, Stuart said and anyone who believes the same can join and help out at Open Web Advocacy, or do their own advocacy for an open web. Amen to that!

Make impact

Gayle Ngozi shared how the non-profit Code your Future works with refugees and disadvantaged people to get skills in software engineering to close the gap between them and the job market, specifically in the tech industry. She said we can all make impact by contributing stuff like laptops, time by teaching and/or opportunities by working together to launch new tech careers.

Make little web components

Personal website innovator David Darnes finally explained the inner workings of that cool button on his site that announces his name spoken by different people every time you press it. He didn't cover why it has a bias towards his father's recording, but it was very interesting nonetheless. There's one component that upgrades the standard <audio> element to be a fancy button, another that randomises the source used and one more that makes the playing state available as an attribute so that it can be used in styles. Are Web Components just for little bits? No, Dave showed that it's also used in fairly complex applications he worked on, including at Nordhealth, that has both Nuxt and Django apps using the same components. The technology, Dave said, works so well because is versatile and forgiving.

Make standards open

Katie Fenn is a huge Daft Punk fan, so she used her talk slot to play their “Around the world” with web technologies: the WebMIDI and WebAudio APIs specifically. MIDI is a technology and technical standard specced in the 80s that allows you to pass messages and information between musical instruments, like notes and special effects. Because it was, just like the W3C's web standards, completely open and royalty-free, it's changed music production forever, especially electronic music: yay open standards. You should watch this talk when it comes out. I can't wait to go play with the MIDI-enabled devices in my home.

Synthesisers!

Automate more of assistive technology support testing

Lola Odelola showed how web standards work happens by using the ARIA-AT program (and ghost detection 👻) as an example. Many developers will be familiar with the ARIA Authoring Practices Guide. I am very happy for this to exist, but also see gaps in user testing (do real users actually; understand how to use the patterns?) and AT testing (do the patterns work in AT and is that consistent?). ARIA-AT, Lola showed, addresses the latter, and does so really well: there is a Selenium-like protocol called AT Driver to automatically test how the ARIA patterns work in different assistive technologies, with lots of reports as a result. Loved hearing Lola talk about this important project, that I hope can be built out further.

Use fluid scales

Richard Ruttter showed us how to use fluid scales for typography and spacing, I feel inspired to go and try that out on this website when I get a chance. See also what I wrote about that talk at Patterns Day.

Summing up

It was a lovely day, with great talks and conversations. One of the recurring themes was how much extreme capitalism affects the ecosystem we all clearly share a love for, we learned about various concrete ways in which this is at play. At the same time, we shouldn't forget to focus on what is valuable in and of itself: making music, fun buttons and UIs that include everyone. Priorities matter!

---

Originally posted as The open web, MIDI and assistive tech: State of the Browser 2024 on Hidde's blog.

Reply via email