Updated A Round Of Applause Semantic Release For The Clapper Component

_drafts/a-round-of-applause-semantic-release-for-the-clapper-component.markdown

@@ -19,13 +19,13 @@ author: cwilton
 
 You may not have noticed a small change to our blog posts this week, but it's a significant one for inclusivity. Recently I noticed that the [applause button component](https://www.npmjs.com/package/applause-button), which allows readers to show their appreciation for a blog post by giving it a clap, was not accessible by keyboard 🫣 
 
-![mouse-laugh.jpg](/uploads/mouse-laugh.jpg)
+<img src="/uploads/mouse-laugh.jpg" alt="Mouse laughing" title="Not so smart now huh?!" style="display: block; margin: 1rem auto;" />
 
 Yep, kinda embarrassing, and a problem I and colleague [Dave Ogle](https://blog.scottlogic.com/dogle/) were keen to put right straight away. The usual fixes applied here: using a `<button>` gave immediate relief, though of course there were styling issues to resolve, some structural rearrangements, and a few animations to sort out. On that front, I dampened those animations unless the user has [no preference on reduced motion](https://css-tricks.com/nuking-motion-with-prefers-reduced-motion/), and there is work in progress to correct colour contrast issues.
 
 ## Release the Kraken
 
-Time's up, inaccessible clapper! But this is where things became more interesting: how was the applause-button component being released and published? I could see [semantic-release](https://www.npmjs.com/package/semantic-release) and [travis-deploy-once](https://www.npmjs.com/package/travis-deploy-once) dependencies in the `package.json`, and a Travis CI config file in the repo root, but I had no idea how to access the Travis build, nor even if it was still running because the last release was almost 4 years ago... 😱
+Time's up, inaccessible clapper! But this is where things became more interesting: how was the applause-button component released and published? I could see [semantic-release](https://www.npmjs.com/package/semantic-release) and [travis-deploy-once](https://www.npmjs.com/package/travis-deploy-once) dependencies in the `package.json`, and a Travis CI config file in the repo root, but I had no idea how to access the Travis build, nor even if it was still running because the last release was almost 4 years ago... 😱
 
 I decided everything would be simpler and more transparent if I switched to using a [GitHub workflow](https://docs.github.com/en/actions/writing-workflows/about-workflows) for the release. Luckily for me, the owner of the [applause-button GitHub repo](https://github.com/ColinEberhardt/applause-button) is our very own [Colin Eberhardt](https://blog.scottlogic.com/ceberhardt/), who graciously gave me maintainer rights and free rein to tinker as I saw fit 🛠️
 
@@ -53,27 +53,27 @@ An NPM_TOKEN secret is something I needed to ask Colin to generate specifically
 
 By default, [Commit Analyzer plugin][commit-analyzer-plugin] uses [Angular commit message conventions](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit) to determine whether a release is major (breaking changes), minor (new feature) or patch (bug fixes). This plugin uses [conventional-changelog][conventional-changelog] under the bonnet.
 
-It's important to note that neither `docs` nor `chore` types trigger a release by default, and I chose to deviate from the default by including `docs` changes in patch releases, otherwise our package README on NPM could become out of sync.
+It's important to note that neither `docs` nor `chore` commit types trigger a release by default, and I chose to deviate from the default by including `docs` changes in patch releases, otherwise our package README on NPM could become out of sync.
 
 ### Generate Notes
 
-By default, [Release Notes Generator plugin][release-notes-plugin] groups commits by type: fix as Bug Fixes, feat as Features, perf as Performance Improvements, and BREAKING CHANGES as a separate group at the bottom. Again, I chose to deviate from defaults to include docs under Documentation, but you don't have to follow suit.
+By default, [Release Notes Generator plugin][release-notes-plugin] groups commits by type: `fix` as Bug Fixes, `feat` as Features, `perf` as Performance Improvements, and BREAKING CHANGES as a separate group at the bottom. Again, I chose to deviate from defaults to include `docs` as Documentation, but you don't have to follow suit.
 
 Take a look at [semantic-release's own release page for v23.0.0](https://github.com/semantic-release/semantic-release/releases/tag/v23.0.0) to see how these grouped release notes look.
 
 ### Prepare
 
 This step is implemented by [NPM plugin][npm-plugin] and [GitHub plugin][github-plugin], to prepare bundles for release - a tarball for the NPM package, and zip and tarball of source code for the GitHub release. However, there are important differences in the bundles generated for the two.
 
-It is [recommended not to increment version number](https://semantic-release.gitbook.io/semantic-release/support/faq#making-commits-during-the-release-process-adds-significant-complexity) in the GitHub repo during a release, as that adds a lot of complexity: the release process will need permissions to create and push a commit, which is likely to be restricted on the release branch. Instead, you will see in the [applause-button package.json](https://github.com/ColinEberhardt/applause-button/blob/master/package.json#L4) we have version set to "0.0.0-semantically-managed", to indicate we don't need to worry about version numbering during development. This is a key tenet of semantic versioning: let the code determine release numbering, rather than working towards pre-determined releases.
+It is [recommended not to increment version number](https://semantic-release.gitbook.io/semantic-release/support/faq#making-commits-during-the-release-process-adds-significant-complexity) in the GitHub repo during a release, as that adds a lot of complexity: the release process will need permissions to create and push a commit, which is likely to be restricted on the release branch. Instead, you will see in the [applause-button package.json](https://github.com/ColinEberhardt/applause-button/blob/master/package.json#L4) we have version set to "0.0.0-semantically-managed", to indicate we don't need to worry about version numbering during development. This is a key tenet of semantic versioning: let code changes determine release numbering, rather than working towards pre-determined releases.
 
 However, we do need our package in NPM to have the correct version number, so the [NPM plugin][npm-plugin] makes that change locally before creating the tarball, using the version number calculated in the Analyze Commits step. Additionally, we have an npm script (`prepack`) which runs the build before packaging, to generate  production-ready JavaScript and CSS files. Therefore the package tarball also contains a dist folder with these assets, which the GitHub source bundles do not have.
 
 ### Publish
 
-Here's another lovely thing about semantic-release: they provide a set of [recipes for common release tasks](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations), including a recipe for [releasing to NPM via GitHub Actions](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/github-actions#node-project-configuration). [NPM Provenance](https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/) is a relatively new concept, but is gaining traction: packages can gain a provenance badge by providing a verifiable link back to the source code _and_ to the build configuration. GitHub Actions are one of the current verifiable build systems, which is another good reason to use them instead of Travis.
+Here's another lovely thing about semantic-release: they provide a set of [recipes for common release tasks](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations), including a recipe for [releasing to NPM via GitHub Actions](https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/github-actions#node-project-configuration). While [NPM Provenance](https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/) is a relatively new concept, it is gaining traction; packages can gain a provenance badge by providing a verifiable link back to the source code _and_ to the build configuration. GitHub Actions are one of the current verifiable build systems, which is another good reason to use them instead of Travis.
 
-The workflow simple to set up following the above recipe. The only extra config needed for provenance is this section inside `package.json`:
+The workflow is simple to set up following the above recipe. The only extra config needed for provenance is this section inside `package.json`:
 
 <pre style="margin-inline: 0; margin-block: 1.5rem"><code>"publishConfig": {
   "provenance": true
@@ -83,7 +83,9 @@ The workflow simple to set up following the above recipe. The only extra config
 
 Adding comments to released issues is a nice touch. Here's an example:
 
-![semantic-release-comment.png](/uploads/semantic-release-comment.png)
+<img src="/uploads/semantic-release-comment.png" alt="Issue release comment" title="Hello semantic-release bot!" style="display: block; margin: 1rem auto;" />
+
+Equally, when things go wrong it's nice to receive a notification, via a new issue detailing the errors. This helps track both the problem and the eventual solution.
 
 ## Flexible Configuration