Home - Sa11y
Another handy accessibility testing tool that can be used as a bookmarklet.
Another handy accessibility testing tool that can be used as a bookmarklet.
I’m at day two of Indie Web Camp Brighton.
Day one was excellent. It was really hard to choose which sessions to go to because they all sounded interesting. That’s a good problem to have.
I ended up participating in:
In that testing session I shared some of the bookmarklets I use regularly.
Bookmarklets? They’re bookmarks that sit in the toolbar of your desktop browser. Just like any other bookmark, they’re links. The difference is that these links begin with javascript:
rather than http
. That means you can put programmatic instructions inside the link. Click the bookmark and the JavaScript gets executed.
In my mind, there are two different approaches to making a bookmarklet. One kind of bookmarklet contains lots of clever JavaScript—that’s where the smart stuff happens. The other kind of bookmarklet is deliberately dumb. All they do is take the URL of the current page and pass it to another service—that’s where the smart stuff happens.
I like that second kind of bookmarklet.
Here are some bookmarklets I’ve made. You can drag any of them up to the toolbar of your browser. Or you could create a folder called, say, “bookmarklets”, and drag these links up there.
Validation: This bookmarklet will validate the HTML of whatever page you’re on.
Carbon: This bookmarklet will run the domain through the website carbon calculator.
Accessibility: This bookmarklet will run the current page through the Website Accessibility Evaluation Tools.
Performance: This bookmarklet will take the current page and it run it through PageSpeed Insights, which includes a Lighthouse test.
HTTPS: This bookmarklet will run your site through the SSL checker from SSL Labs.
Headers: This bookmarklet will test the security headers on your website.
Drag any of those links to your browser’s toolbar to “install” them. If you don’t like one, you can delete it the same way you can delete any other bookmark.
I’m a little obsessed with web performance. I like being able to check a page’s core web vitals quickly and easily.
Four years ago, I made a Lighthouse bookmarklet. Whatever web page you were on, when you clicked on the bookmarklet you’d get the Lighthouse results for that page. Handy!
It doesn’t work anymore. This is probably because Google are in the loop. Four years is pretty good innings for anything involving that company.
I kid (mostly). Lighthouse itself is still going strong, despite being a Google product. But the bookmarklet needs updating.
Rather than just get Lighthouse results, I figured that the full PageSpeed Insights results would be even better. If your website is in the Chrome UX report, you get to see those CrUX details too.
So here’s the updated bookmarklet:
Drag that up to your desktop browser’s bookmarks toolbar. Press it whenever you want to test the page you’re on.
I love a good bookmarklet, and Harry has made a very good bookmarklet indeed.
Drag ct.css to your browser bar and then press it whenever you’re on a site you want to check for optimising what’s in the head
element.
I like this idea for a minimum viable note-taking app:
data:text/html,<body contenteditable style="line-height:1.5;font-size:20px;">
I have added this to bookmarks and now my zero-weight text editor is one keypress away from me. You might also use it as a temporary clipboard to paste text or even pictures.
See also: a minimum viable code editor.
I love bookmarklets! I use them every day (I’m using one right now to post this link). Amber does a great job explaining what they are and how you can make one. I really like the way she frames them as your own personal dev tools!
I use Firefox. You should too. It’s fast, secure, and more privacy-focused than the leading browser from the big G.
When it comes to web development, the CSS developer tooling in Firefox is second-to-none. But when it comes to JavaScript and network-related debugging (like service workers), Chrome’s tools are currently better than Firefox’s (for now). For example, Chrome has a tab in its developer tools that lets you run Lighthouse on the currently open tab.
Yesterday, I got the Calibre newsletter, which always has handy performance-related links from Karolina. She pointed to a Lighthouse extension for Firefox. “Excellent!”, I thought, and I immediately installed it. But I had some qualms about installing a plug-in from Google into a browser from Mozilla, particularly as the plug-in page says:
This is not a Recommended Extension. Make sure you trust it before installing
Well, I gave it a go. It turns out that all it actually does is redirect to the online version of Lighthouse. “Hang on”, I thought. “This could just be a bookmarklet!”
So I immediately uninstalled the browser extension and made this bookmarklet:
Drag that up to your desktop browser’s bookmarks toolbar. Press it whenever you’re on a site that you want to test.
Max describes how he does bookmarking on his own site—he’s got a bookmarklet for sharing links, like I do. But he goes further with a smart use of the “share target” section in his web app manifest, as described by Aaron.
By the way, Max’s upcoming talk at the Web Clerks conference in Vienna sounds like it’s going to be unmissable!
Drag this to your browser’s bookmark bar now!
Such a useful quick check for resilience—this bookmarklet shows you a side-by-side comparison of a site with JavaScript enabled and disabled.
Another bookmarklet for checking accessibility—kind of like tota11y—that allows to preview how screen readers will handle images, focusable elements, and more.
I was idly thinking about the different ways I can post to adactio.com. I decided to count the ways.
This is the classic CMS approach. In my case the CMS is a crufty hand-rolled affair using PHP and MySQL that I wrote years ago. I log in to an admin interface and fill in a form, putting the text of my posts into a textarea
. In truth, I usually write in a desktop text editor first, and then paste that into the textarea
. That’s what I’m doing now—copying and pasting Markdown from the Typed app.
If I’m logged in, I get a stripped down posting interface in the notes section of my site.
This is how I post links. When I’m at a URL I want to bookmark, I hit the “Bookmark it” bookmarklet in my browser’s bookmarks bar. That pops open a version of the admin interface tailored specifically for links. I really, really like bookmarklets. The one big downside is that they don’t work on mobile.
This is something I knocked together at Indie Web Camp Brighton 2015 using the Twilio API. It’s handy for posting notes if I’m travelling somewhere and data is at a premium. But I don’t use it that often.
Thanks to Aaron’s OwnYourGram service—and the fact that my site has a micropub endpoint—I can post images from Instagram to my site. This used to happen instantaneously but Instagram changed their API rules for the worse. Between that and their shitty “algorithmic” timeline, I find myself using the service less and less. At this point I’m only on their for the doggos.
Like OwnYourGram, Aaron’s OwnYourSwarm allows me to post check-ins and photos from the Swarm app to my site. Again, micropub makes it all possible.
OwnYourGram and OwnYourSwarm are very similar and could probably be abstracted into a generic service for posting from third-party apps to micropub endpoints. I’d quite like to post my check-ins on Untappd to my site.
Thanks to rel="me"
and IndieAuth, I can log into other people’s posting interfaces using my own website as the log-in, and post to my micropub endpoint, like this. Quill is a good example of this. I don’t use it that much, but I really should—the editor interface is quite Medium-like in its design.
Anyway, those are the different ways I can update my website that I can think of right now.
In terms of output, I’ve got a few different ways of syndicating what I post here:
Just so you know, if you comment on one of my posts on Facebook, I probably won’t see it. But if you reply to a copy of one of posts on Twitter or Instagram, it will show up over here on adactio.com thanks to the magic of Brid.gy and webmention.
Someone at Clearleft asked me a question recently about making bookmarklets. I have a bit of experience in that department. As well as making a bookmarklet for adding links to my own site, there’s the Huffduffer bookmarklet that’s been chugging away since 2008.
I told them that there are basically two approaches:
I favour the first approach. Partly that’s because it makes it easier to update the functionality. As you improve your server-side script, the bookmarklet functionality gets better automatically. But also, if your server-side script doesn’t do its magic, you can always fall back to letting the end user fill in the details.
Here’s an example…
When you click the Huffduffer bookmarklet, it pops open this URL:
https://huffduffer.com/add?page=…
…with that page
parameter filled in with whatever page you currently have open. Let’s say I’ve got this page currently open in my browser:
https://adactio.com/journal/6786
If I press the Huffduffer bookmarklet, that will spawn a new window with this URL:
https://huffduffer.com/add?page=https://adactio.com/journal/6786
And that’s all it does. Now it’s up to that page on Huffduffer to figure out what to do with the URL it has been given. In this case, it makes a CURL request to figure out what to use as a title, what to use as a description, what audio file to use, etc. If it can’t figure that out, I can always fill in those fields myself by hand.
I could’ve chosen to get at that information by injecting JavaScript directly into the page open in the browser. But that’s somewhat invasive.
Brian Donohue wrote on Ev’s blog a while back about one of the problems with that approach. Sites that—quite correctly—have a strict Content Security Policy will object to having arbitrary JavaScript injected into their documents.
Content Security Policies (https://en.wikipedia.org/wiki/Content_Security_Policy) are great except that they prevent bookmarklets like @instapaper from loading. 😐
— Jason Garber (@jgarber) March 16, 2016
But remember this only applies to some bookmarklets. If a bookmarklet just spawns a new window—like Huffduffer’s—then there’s no problem. That approach to bookmarklets was dismissed with this justification:
The crux of the issue for bookmarklets is that web authors can control the origin of the JavaScript, network calls, and CSS, all of which are necessary for any non-trivial bookmarklet.
Citation needed. I submit that Huffduffer and Instapaper provide very similar services: “listen later” and “read later”. Both use cases could be described as “non-trivial”. But only one of the bookmarklets works on sites with strict CSPs.
Time and time again, I see over-engineered technical solutions that are built with the justification that “this problem is very complex therefore the solution needs to be complex” (yes, I am talking about web thangs that rely on complex JavaScript). In my experience, it’s exactly the opposite way around. The more complex the problem, the more important it is to solve it in the simplest way possible. It’s the only way of making sure the solution is resilient to unexpected scenarios.
The situation with bookmarklets is a perfect example. It’s not just an issue with strict Content Security Policies either. I’ve seen JavaScript-injecting bookmarklets fail because someone has set their browser cookie preferences to only accept cookies from the originating server.
Bookmarklets are not dead. They may, however, be pining for the fjords. Nobody has a figured out a way to get bookmarklets to work on mobile. Now that might well be a death sentence.
A handy little bookmarklet for doing some quick accessibility checks.
You know what would be awesome? If you could huffduff the audio from videos on YouTube, Vimeo, and other video hosting sites.
To give you an example, A List Apart recently started running online events and once the events are over, they pop ‘em onto YouTube. Now, I’m not saying I don’t want to look at those lovely faces for an hour, but if truth be told, it’s the audio that I’m really interested in.
In the past, my only recourse would’ve been to pester the good people at A List Apart to export audio as well as video, in much the same way as I’ve pestered conference organisers in the past:
I wish conference organisers would export the audio of any talks that they’re publishing as video. Creating the sound file at that point is a simple one-click step. But once the videos are up online—be it on YouTube or Vimeo—it’s a lot, lot harder to get just the audio.
Not everyone wants to watch video. In fact, I bet there are plenty of people who listen to conference talks by opening the video in a separate tab so they can listen to it while they do something else.
Some people have come up with clever workarounds to get the audio track from videos into Huffduffer but they’re fairly convoluted.
Until now!
The brilliant Ryan Barrett has just launched huffduff-video:
huffduff-video lets you send @Huffduffer the audio from videos on YouTube, Vimeo, and more! https://t.co/fBkMBESI61 http://t.co/2pNItWGL8f
— Ryan Barrett (@schnarfed) March 8, 2015
He has created a bookmarklet you can use whenever you’re on a YouTube or Vimeo page that you want to huffduff. It works a treat—I’ve already used to huffduff that A List Apart event and a talk by Matt Jones.
It takes a little while to do the initial conversion but you can just leave the pop-up window open while it works its magic. I’ve incorporated it into the Huffduffer bookmarklet now too. So if you’re on a YouTube or Vimeo page, you can hit the usual bookmarklet and it’ll route you through Ryan’s clever creation.
That’s makes two fantastic pieces of software from Ryan that have improved my online life immeasurably: first Bridgy and now huffduff-video. So nifty!
A handy little bookmarklet for quickly checking how a site might look at different screen sizes, and you can customise it to use whichever screen sizes you like.
Just as every instance of “the cloud” can be replaced with “the moon” or “my butt”, so too can every instance of the word “markets” in business reporting be replaced with the word “dragons”.
James has got you covered with this bookmarklet to do just that.
The dragons reacted strongly to the news.
A lovely new service from Mike Stenhouse: install the bookmarklet and then when you come across a website with a nice combination of fonts, you can save a snapshot of the page (and its fonts) for later perusal. You can then browse those fonts on Typekit, Fontdeck, MyFonts or Google Fonts.
A bookmarklet version of that handy multiple-iframe page I linked to the other day. Even more useful for testing responsive designs!
This is really handy: a bookmarklet that will disable any CSS3 on a page so you can check that your fallbacks look okay.
A bookmarklet to help you figure out what files you might want to put in your cache manifest for offline storage.