Explore My Notes

Code with your voice | Cursorless

Cursorless is a very cool VS Code plugin that uses Talon (voice-control assistive tech) to navigate around codebases, write and edit code, and do just about anything else. Even if that isn't interesting, give the tutorial video a watch, because it's fascinating.

Use your Mac the way I do | Blake Watson

A phenomenally interesting journey through one person's assistive set-up, using only the left mouse button to navigate the web, code websites, play video games, and everything else in-between.

On a better keyboard layout for limited cursor-travel, pointer-only typing:

...you come across the Chubon keyboard layout, which seems to be optimized for your very situation—it places common letters toward a center grouping where they’re easy to click with less pointer travel.

On the many superpowers of the macOS Accessibility Keyboard:

The built-in Panel Editor gives you the ability to edit the panel or create new ones. This means you can create your very own keyboard layout! The Panel Editor is powerful. You can add not only the basic keys but also buttons which execute key combos, invoke system actions, input strings of text, and more.

On some unexpected accessibility benefits of supporting Markdown:

Note-taking apps like Bear that use Markdown for formatting are great because you can avoid using keyboard shortcuts or UI controls for formatting—and you added dedicated punctuation buttons to your keyboard so that you don’t need to press Shift to access characters like the asterisk or underscore.

On a tool for making your mouse behave like a touch event in macOS browsers:

The browser extension ScrollAnywhere lets you click and drag on webpages to scroll them—much like you would on a mobile touchscreen.

On how you can use voice commands to play video games:

Since Talon gives you the ability to verbalize keypresses, your mouse pointer is freed from typing duty. This is important for being able to play games that require camera control via the mouse.

On how tools can be combo'ed to turn a single mouse input into a whole stack of augmentations and efficiencies:

You started with nothing more than a one-button mouse. But from there you expanded the capabilities of that humble device, giving yourself keyboard access, shortcuts and macros, assistive tech tools, and powerful voice input capability.

📆 20 Mar 2024  | 🔗

Complex images can paint a thousand words | Paul Watson

What is the best way to provide descriptive text for images that are both complex and the main focus of a page? Paul has tried to tackle this on pages dedicated to their personal art, and found that the advice isn't necessarily that clear. The tl;dr would be: move the text onto the page itself and reference it from the image (using ARIA or alt attributes, or a combination).

I hadn't realised that the WAI has outlined seven image "types", nor that they have different suggested approaches based on the "type". I initially thought Paul's use of the "complex image" type felt wrong, but reading over the spec I agree; it's weird, but that's the best fit for these kinds of pages/content.

On disproving the weirdly common belief that you can't have more than 140 characters in alt text (this isn't Twitter!):

Myth busted: there is no character limit on “alt” text.

On concerns with overly long alternative text:

So you’re free to use as many characters in your
alt text as is necessary to describe an image, but it’s also worth remembering that someone using a screen reader apparently cannot skip listening to the alt text if it feels like it’s going on forever, so try not to be unnecessarily verbose.

On the official guidance from WAI (taken from the WAI tutorial on images):

In these cases, a two-part text alternative is required. The first part is the short description to identify the image and, where appropriate, indicate the location of the long description. The second part is the long description – a textual representation of the essential information conveyed by the image.

On how to deal with "Complex Images":

The general advice is to make long descriptions available to everyone to reach a wider audience with your content. For example, show the description as part of the main content.

Inclusive glasses frames | Reframd

I've always struggled to find glasses or sunglasses that fit my weird head, so I was intrigued by a company explicitly targeting body shapes that aren't well catered for. Unfortunately, the selection is pretty narrow and likely won't work with my level of prescription, but saving to check back in the future.

Bidirectional text in HTML | @samgai

Today's obscure HTML element: <bdi>. It stands for "bidirectional" and refers to text that can include both RTL and LTR languages (does not appear to care about other variations).

Looking on MDN, the exact order is quite complex, but thankfully the browser does most of the heavy lifting for you.

Usernames and other user-provided values should be directionally isolated from their surrounding inline text, if there is any.

In HTML, this can be done with the <bdi> element.

Not only does this stop people messing with text direction using directional overrides (sorry for ruining your jokes), it also makes sure that an English sentence still ends on the right even when starting with an Arabic name.

A global documentation platform | Andy Bell

Andy brings up a very valid and very scary point: what happens when Mozilla shuts down MDN? Why is one of the most important sources of web knowledge not under community stewardship? And what can we do about it?

These are all solid questions and worth thinking about. I'm not so sure that the funding model proposed here would work, but I think a hybrid approach – one with corporate subscriptions, Patreon style personal donations, and big ticket sponsorship – might. It'll just be about building the right team in the first place, and hitting that critical mass of funding to make them financially secure.

On Mozilla versus MDN:

I want to be absolutely clear that I wholeheartedly support MDN. I think it’s fantastic. I think it’s under the wrong stewardship though.
I think MDN core documentation content needs forking and an alternative platform needs to develop from that forked, attributed content that has a sustainable funding and leadership model. Mozilla ain’t providing that.

On the lacklustre demos (some seem actively problematic these days):

Often, on MDN, demos are too abstract from real world use cases and frankly uninspiring

On Mozilla's odd (and problematic) priorities:

Mozilla could invest in this work — y’know, improving the docs so they help as many people as possible — but they instead introduce an “AI” helper that lies to people. Unforgivable.
The point I’m making is we as a collective can do so much better and importantly, look after an extremely valuable resource better. Something that’s focused on what it is, rather than something that’s good, but frequently gets enshittified by terrible leadership decisions.

On Andy's proposed funding model:

In community organisations the onus is often on generous individuals and corporate sponsors. I think the onus should be on companies that rely on web documentation for profit.

On the problems of open source and why it isn't a good fit here:

Open source is unfortunately treated as free, including lots of free labour. It’s free at the point of use, but people’s time and wellbeing is often exploited to achieve that.

On why we need to act now, rather than later:

MDN isn’t safe in Mozilla’s hands and the thought of it disappearing is terrifying. We can organise though and get something positive going before we have to because MDN has been rug-pulled. Fix the roof when it’s sunny and all that.

The two Reacts | Dan Abramov

A very well written overview of when client-side functionality and server-side functionality make sense to use for a website.

Frustrating to read, though, because not only have people been saying this for years (and saying this to the author, in particular, for years, which is not acknowledged here at all), but they've also been solving this for years. There are many competing patterns out there, so I wouldn't call this a problem with a definitive answer. But positing the question and then effectively shrugging your shoulders and saying "but who could ever possibly dream of such a world" is a little trite when solutions do, in fact, exist.

Though is it trite, or is it simply worrying that someone who has supposedly been thinking around solutions to this problem themselves seems so unaware of the space they are considered a thought leader within..?

For example:

Is there some way we could split components between your computer and mine in a way that preserves what’s great about React? Could we combine and nest components from two different environments? How would that work?

Yes, Islands Architecture. Or Web Components. This is neither a "hard" problem (at a conceptual level) nor an unsolved one.

(Though perhaps the issue here is the "preserves what's great about React", because based on React's attempts to solve these issues, I'm not sure the React team and the general developer community agree on what that is.)

The good, the bad, the web components | Zach Leatherman

An excellent overview of the current state of web components, including suggestions on how they could be improved.

On the current popularity (and success) of web components:

In August 2023, Chrome Platform Status reports that 19.4% of page loads in Google Chrome were using a web component (via the CustomElementRegistryDefine key). For comparison <img loading>

On the simplest form of web component, a Custom Element (or HTML Web Component):

Custom Elements allow you to attach a JavaScript class to any custom element you define on your page, to add behaviors and JavaScript-generated content to any element instances on the page.

On the downside to Custom Elements (not very DRY):

Multiple instances of the same component need to repeat the same nested content and any changes to nested content need to be applied manually to all instances.

On the Shadow DOM, the next step up in terms of complexity:

Shadow DOM is the next level of our web components evolution. It solves the developer experience problem with repetition in authoring markup at the expense of clientside rendering 😭.

On how Declarative Shadow DOM is just several Custom Elements in a trench coat:

[Declarative Shadow DOM] solves the clientside rendering dependency for Shadow DOM but at the expense of repetition in authoring markup! The ol’ switcheroo (in some ways) feels like a de-evolution back to the approach we discussed in Custom Elements!

Quickly check Core Web Vitals | Page-Speed.dev

A quick way to check for PageSpeed metrics, Lighthouse scores (are those the same thing these days?), and Core Web Vitals, all in one place.

📆 05 Mar 2024  | 🔗

  • Frontend
  • core web vitals
  • page speed
  • Lighthouse
  • web performance 

Removing list styles without affecting semantics. | Manuel Matuzović

A simple tweak that simplifies the common approach to "lists that don't look like lists" with HTML/CSS and sidesteps any semantic/accessibility concerns. Neat!

you can use a string as the value of the `list-style-type` property.
ul { 
    list-style-type: "";
}

A history of painting (with dinosaurs) | Mark Witton

Ultimately, this is a book review, but it's a very good one that helps dissect the topic of where palaeoart fits in with the wider canon of art itself. It certainly gave me pause for thought on how even I (with a growing palaeoart collection) think about displaying and enjoying the medium.

On the snobbery and cultural conditioning of dinosaurs as "childish" and therefore not worthy of artistic expression (itself a quote from Lescaze 2017):

“Throw an engraving of an egret above the mantelpiece and no one balks. Hang a painting of a *T. rex* in the same spot, and the decision screams nerd stuck in second childhood.”

On the core question of the book and, arguably, of palaeoart itself:

And, more broadly, it asks why must art of dinosaurs be useful? Can it not be art for the sake of being art, or created purely for aesthetic value?

Made By Me, But Made Possible By:

CMS:

Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.