At work, I've had to produce VPAT documents for the software I'm responsible for.
The VPAT template asks you to list, for each of the WCAG criteria, whether you support it or not, or if it doesn't apply.
The W3C have made a WCAG-EM Report Tool which helps you to work through the WCAG criteria and make notes about whether they're satisfied.
At the end, you can download a copy of the report in either summarised HTML format, or a JSON file with all the data you entered.
The first time I did a VPAT, I mostly manually converted the information from the WCAG-EM report to a reStructuredText table, to go in our Sphinx documentation.
Now I'm doing it a second time, I know I don't want to waste my time doing that!
So I've written a Python script which takes in the JSON file from the report tool and prints out the tables for the VPAT template, in reStructuredText format.
Last August we bought an Ultimate Harmony cargo e-bike from amcargobikes, which is the English branding for the Danish company amladcykler.
Now we've had it a while, I thought it would be worthwhile to write a review to help anyone else considering buying one.
A lot of what I do on a computer involves web development.
For work, I develop several projects which involve running a Django server, which I have to run locally while I'm working on them.
And for client-side stuff, I always run a simple HTTP server to serve static files, because browsers apply a lot of security restrictions to pages loaded through file://.
For years, I would type in things like http://localhost:8000 into my browser's address bar, like a chump.
Then one day, a lightbulb turned on and I realised that since I already have an HTTP server running on port 80, I could make its homepage be a list of links to the ports I usually run servers on.
A little while later, another, brighter lightbulb turned on and I realised that the homepage could be a script which scans every port to automatically find every server I'm running.
At the moment I'm writing up one of my regular development update posts on the Numbas blog.
I try to write one every couple of months.
The posts act as a changelog for the various projects related to Numbas.
It's been just over seven months since the last one, because of everything, so this time there's a lot to talk about.
This post is about how I wrote an ActivityPub server using the Django Python framework, to provide a fediverse account on the same domain as a WordPress blog.
On The Aperiodical, we do a monthly post collecting bits of maths news that we've seen.
This is the compromise we came to as we realised that we're too old and busy to keep up with writing in-depth posts about individual things any more.
When we started doing this, I set up a /news slash command in our Slack channel which would take a URL and some explanatory text, and add it to the current draft post.
Slack insists you give a username to the account that replies to this command, so we have our happy little Aperiodipal secretary.
Since we only publish the news posts once a month, we sometimes miss out on spreading the word about time-limited events, such as deadlines to register for conferences or mathematical holidays.
And when there's Big Maths News such as a proof of an old conjecture, it'd be nice to put something out immediately rather than waiting until it's old news.
So I thought it would be a good idea to automatically toot on the fediverse each time one of us adds an item to the news post, as part of the /news Slack command.
Ideally, I'd like the fediverse account to belong to the aperiodical.com domain, instead of a Mastodon instance such as mathstodon.xyz.
That meant I'd have to serve the ActivityPub protocol on aperiodical.com.
This is the kind of thing you do when really you're more curious about how the protocol works than making a pragmatic decision of the best course of action.
Mastodon has really taken off this month, as a result of Twitter collapsing.
The instance I run with Colin Wright, mathstodon.xyz, has grown from about a thousand active users to just over 5,000 as I write.
There are lots of people running small Mastodon instances who suddenly need to support lots more activity than they're used to.
I've had to learn a lot about making a webserver run at scale, so I thought it would be worth writing down what I've learnt.
I didn't take proper notes while fixing things, so I've probably forgotten some important non-obvious stuff.
Soz!
This is just the things that stuck in my mind recently.
While updating Numbas, I wanted to know which new CSS and JavaScript features we could use while maintaining compatibility with almost all browsers in use.
Until now, we'd been stuck hanging on to support for Internet Explorer 11, but it seems to have finally faded away into insignificance.
So we needed a new target for compatibility.
We agreed that aiming for compatibility with 95% of devices in use would be a reasonable target.
I have been using caniuse.com to check individual features against their usage stats.
It's a really useful site!
But our policy shouldn't just be "any feature supported by 95% of browsers can be used": if two features each have 95% support, the set of browsers supporting both features could be anything between 95% and 90%.
With more features, the intersection of all those sets could end up being much lower than our target, and make Numbas inaccessible for a significant number of people.
I looked around for something that would let me specify a collection of features and see what percentage of browsers support them all.
I'm sure it exists, but I couldn't find it, so I spent a happy day making it.
I gathered MDN's compatibility data and caniuse.com's usage data, and presented it as a massive searchable tree of features you can tick off.
The other half of the screen shows you which browsers support all of the selected features, and their relative usage and release dates.
For each browser, you're shown which features force that particular version, so you know what to drop in order to be supported by older versions.
I've realised that I have to be quite careful about which features I tick when using this tool, particularly with respect to CSS: browsers usually silently ignore CSS rules that they don't support, so I should only tick features that are absolutely required for the page to function.
There's a function to download the set of selected features so you can documente what your project requires.
I haven't added this yet, but next time I need to do this job I'll add a feature to load in that file, so I don't have to start again from scratch!
I've been working on a new version of the Numbas lockdown browser app.
It's a very basic Electron app: the point is to provide a web browser with none of the developer tools that would let a student fiddle with the internals of a Numbas exam.
Packaging it up has been a nightmare!
For Windows, we need to produce a .msi file for our IT people to install automatically on cluster PCs.
The electron-builder documentation seems comprehensive, but it's extremely hard to read.
It took me ages to work out whether and how certain things could be configured.
At least now I know a little bit more about how .msi files work!
Our IT person said that the app automatically launches after installation, which he doesn't want to happen.
I couldn't find an option for that in the configuration documentation, so I decided to look inside the .msi file to see how it's defined, then trace things backwards to a configuration option.
I installed the msitools package on Ubuntu, then ran msiinfo tables Numbas-lockdown.msi to see what's inside.
The InstallExecuteSequence table turns out to contain a list of things that happen during installation.
There's a runAfterFinish option which seems to be what I want.
I traced that back through the source code of electron-builder, and eventually found out that in the build.msi object in my project's package.json, I can set runAfterFinish: false.
