Links

Building a component library is a challenging and rewarding experience, but there’s more to it than writing great-looking components. At every step of the journey, you’ll need to make choices to ensure your library is built appropriately for its intended audience.

(From: andrico1234/the-dilemmas-youll-face: The Dilemmas You'll Face When Creating Your First Component Library)

Currently, the Baseline support information does not include whether the feature is supported accessibly:

If you need to understand whether browsers support accessibility features as your own base level set of requirements, for legal or other compliance reasons, then Web Platform Baseline does not represent a baseline.

(From: Baseline Does Not Really Cover Baseline Support — Adrian Roselli)

I support Adrian's call for this to change. We should't assume features to be supported, if there are known accessibility issues in specific browsers or assistive technologies. I previously noted I feel Interop should include accessibility (and there is a separate Interop project for accessibility now, nice). I hope Baseline can meaningfully implement updates to make accessibility support more clear. A disclaimer, as Adrian suggested seems a good first step.

What would that it mean to deem a feature supported accessibly? WCAG's accessibility supported definition is a good start, but the W3C or Accessibility Guidelines Working Group (that makes WCAG) don't say exactly which browsers or assistive technologies a feature needs to work. For users of assistive technologies, ‘it works’ depends both their choice of assistive technology and the browser they use it with. But even if there's no clear cut answer to ‘which browsers or AT’, even the information that there are known bugs and where would tremendously help web developers decide whether to use a feature or not.

Just in time for #GAAD, and in the week where we saw OpenAI share a video of a new feature that integrates the GPT-4o model with BeMyEyes to assist blind people, I want to share the definition of “inspiration porn”:

Inspiration porn is the portrayal of people with disabilities (…) as being inspirational to able-bodied people (…), on the basis of their life circumstances.

(From: Inspiration porn - Wikipedia)

The demo itself was impressive, but I couldn't not notice that OpenAI shared it without captions. It could be that they just forgot. But they clearly didn't forget to upload record, edit, upload and promote the video, so accessibility must have been lower or no priority. And that's likely to be a systemic issue, a bit like some of the other announcement videos that portray assistants as somewhat flirty women.

The term “inspiration porn” has been used in various places, I found the concept particularly well explained in “Against Technoableism” by Ashley Shew and “Handicap” by Anaïs Van Ertvelde. I believe it was originally coined by comedian and journalist Stella Young, see also her TED Talk.

Ana Rodrigues:

I want it all, but it is impossible.

(From: Oh Hello Ana - I want it all but, it is impossible)

Bravo to Michelle Barker putting this out there, putting into words what many of us feel:

The web is becoming hostile to humans. Users are tracked and their privacy is routinely violated. Search results are populated with ads. We are constantly spammed by bots. Generative AI threatens to turn previously useful public forums into soulless marketing soup, while sacrificing the livelihoods of the creators that unwittingly power them. Power-hungry data centres demand the burning of fossil fuels, and divert water and energy from communities, emitting tonnes of carbon in order to power this digital junkyard. Users abandon hostile websites that take too long to load on low-powered devices, or are forced to upgrade, as the pile of electronic waste grows. We need a web by and for humans.

(From: Manifesto for a Humane Web)

I've noticed that whenever I (or someone else) posts a link to this blog on Mastodon, the decentralised nature of the platforms effectively DDoS's me.

(From: Mastodon Is DDoSing Me | Kev Quirk)

Live regions have a reputation for being "flaky" and inconsistent. While this can be attributed in part to shortcomings in current implementations, the problem can also be caused by developers misunderstanding how live regions are intended to work.

(From: Why are my live regions not working? - TetraLogical)

Excellent post by Patrick Lauke!

I’ve got a few tips for you--and anyone--about speaking. I think I can sum it all up pretty well in one phrase: GET COMFORTABLE.

(From: “Get Comfortable,” an article by Dan Mall)

I hadn't seen this post by Dan Mall about speaking when it came out, but read it as it was shared on Mastodon today. This week I gave a talk that I was quite nervous for beforehand and quite happy with afterwards; from my experience I would second all the advice he gives here on public speaking.

In Branch, Michelle Barker suggests a new mindset for the web:

If “move fast and break things” is Silicon Valley’s rallying cry, then the flip-side is “move slow and mend things”.

(From: The perfect site doesn’t exist - Branch)

She says we should center sustainability in our work on the web, be intentional in content and code, and prioritise being human to being perfectionist. I could not agree more.

Accessibility standards veteran and axe-core product owner Wilco Fiers explains how he sees EN 301 549 relate to WCAG:

EN 301 549 steadily gained importance. It is often dismissed as “WCAG with a different number slapped on it,” but it is far more than that.

(From: 301,549 ways to improve accessibility: EN 301 549 | Deque)

In the post, he explains the EN is broader than WCAG in various ways:

• it has more requirements, like for browser settings to be respected by websites (11.7 User preferences)
• it applies to more than web content (apps, kiosks), a scope WCAG explicitly doesn't support
• it and derivatives of it apply in more and more places, way beyond the EU (Canada, Japan, Australia)

On the authoring tool requirements bit that Wilco mentioned, I wrote a blog post to summarise our group's thoughts: On authoring tools in EN 301 549.