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
covers this web accessibility issue in more detail.
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 has several tiers available including a
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.
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!
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.
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
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.
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.
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.