Lighthouse provides a rich set of built-in audits but can also be extended to run your own custom audits.
This can be extremely useful if you have your own specific checks that you want to perform on your site, such as checking all links to external sites have the rel="noopener" attribute or contain a specific class to visually indicate an external link etc.
In this article, we’re going to write a custom audit to check for the well known web accessibility issue of adding a click handler to a non-interactive element and not ensuring it’s accessible for keyboard and screen reader users.
My article on
Accessible JavaScript Click Handlers
covers this web accessibility issue in more detail.
JavaScript modules for our custom audit
There are 3 JavaScript modules we’ll need to create for our custom audit.
This article covers configuring Lighthouse CI to run against a website and uploading the results to a Lighthouse CI server Docker container running both locally and in Azure.
Lighthouse is a great tool for auditing your website on performance, web accessibility, PWA, SEO and more. By automating Lighthouse to run nightly or with each commit and by uploading the results to a Lighthouse CI server, you can track your scores over time, see trends and detect when recent changes have had a negative impact.
While working on a large project, it can be very useful to keep on eye on key metrics about your codebase to see how your project is growing and review indicators that could mean you’re building up maintenance issues / technical debt.
SonarQube
by SonarSource is a static analysis tool that supports 27 languages including JavaScript, TypeScript, HTML & CSS and can detect a range of issues in your codebase including bugs, code smells and security issues as well as provide traditional code metrics like lines of code and cyclometric complexity.
SonarQube has several tiers available including a
Community Edition
which is free.
This article covers running the Community Edition up in a Docker container and analysing a project to see the range of information SonarQube can provide.
This article covers creating a new .NET 5 ASP.NET Core website in Visual Studio 2019 for Mac and running this website from both Visual Studio and from a Docker image.
Before we start, the following prerequisites need to be installed:
After recently seeing a few BEM class naming issues on a project I was working on, I looked for an online site that would check a CSS stylesheet for BEM naming issues.
I couldn’t find one… and what with being on lockdown here in England and having a fair amount of free time on my hands, I thought I’d write one!
Introducing the
BEM Class Names Checker
— An online tool to check a CSS stylesheet for common BEM naming issues.
BEM (Block, Element, Modifier) is a methodology for naming CSS styles in a modular and maintainable manner. If you’ve worked on large websites, I’m sure you’ll have come across indecipherable class names and felt the pain of changing a style in one place and that breaking the styling elsewhere on something that seemingly isn’t related. These are issues that BEM will help you to avoid.
In this article, we’re going to use the example of a product card to explain BEM.
Product card example
BEM relies solely on CSS class names to apply styles to HTML so there are no HTML tag or ID selectors. BEM class names can consist of 3 parts [block]__[element]--[modifier].
Over the years, I’ve worked on many large web app projects with developers of varying levels of experience and often see the same web accessibility issues crop up. In this article, I detail the 5 most common web accessibility issues I’ve come across and offer solutions for them.
Are you making / have you made these mistakes in your projects?
1) Using An Input Without An Associated Label
Wrong - Using plain text next to the input
Username <inputtype="text"name="username">
The text “Username” is not associated with the <input> so when a screen reader announces the <input>, it won’t announce that it’s for entering a username. The <input> will be announced along the lines of “input, edit text” so a screen reader user would have no idea what this <input> is for or what to enter.
The text “Username” also won’t act as a click / touch target to set focus to the <input>.
Knockout is a minimalist, mature and proven library for creating web applications.
It isn’t as feature rich as some of the more modern libraries & frameworks but it does what it does well, primarily being binding HTML elements against a data model.
Even in 2019, I believe Knockout has its place and is still used on some very large projects, including Microsoft’s Azure Portal.
TypeScript provides a huge amount of benefits over JavaScript including type safety, improved IDE tooling and additional constructs like interfaces and enums.
If you have an existing project that uses Knockout, you can move over to TypeScript now and start enjoying these benefits.
This article will start with covering using TypeScript and Knockout’s type definitions to create view models, components and bindings that are strongly typed.
We’ll then cover creating a new project from scratch that uses webpack and Babel to transpile TypeScript down to JavaScript (ES5).
This article covers how to start using TypeScript modules in an existing project alongside JavaScript modules.
If you have a large project, it may not be feasible to move to TypeScript all in one go.
Gradually migrating provides more flexibility and allows you to, for example, use TypeScript just for new code or “upgrade” modules when there are changes to existing code.
TypeScript provides some huge benefits like types support, better IDE tooling and additional constructs like interfaces and enums so why not start making use of these now.
When using Vuex with TypeScript, you typically use the @Getter decorator from the
binding helpers package vuex-class.
This is a more declarative approach over using this.$store.getters.*.
