“Since Covid, aren’t we all bedroom workers to a greater or lesser extent?”
Paul looks to his day job to offer some real-world advice on testing your website
If you’ve read this column over the past year or so, you’d be forgiven for thinking that I just spend all my time playing with phones, home automation and various gadgets.
But if you cast your eyes over to the right for a moment, you’ll notice that underneath my profile picture it says that my day job is running a web agency. It’s something that I’ve been doing since the mid-1990s, when the web first became a thing.
Actually, “web agency” paints a bit of a misleading picture, because it implies that my company just creates websites. And while yes, we do build websites, much more of our time these days is spent creating and managing web-enabled business tools. I’ll talk more about those further down the column, but let’s stick with websites for now.
The first thing that I want to dive into here is the subject of coding standards and website accessibility; they’re much more important than many people think, and they mean a lot to me. You see there are many thousands of companies out there that can build you a nice new website, from the big-budget agencies in their shiny ivory towers through to medium-sized companies such as my own CST Group, right down to the one-man-band developers working out of their bedrooms, possibly on a part-time basis in between studying or holding down a full-time job elsewhere.
That’s not to poo-poo the bedroom agency girls and boys. Many of them produce excellent work, and indeed if you go to one of the big ivory-tower agencies what you’re really paying for is their project management, because they’ll almost certainly be farming the low-level design and coding work out to a team of bedroom workers. Although, since Covid, aren’t we all bedroom workers to a greater or lesser extent? The lines have definitely become very blurred.
One thing you’ll find, especially with many of the bigger agencies, is that there’s probably nobody sitting in their head office (or working virtually there) who understands things such as database design, programming, coding standards or accessibility. They’ll mostly be account handlers, senior execs and content strategists. They’re the kind of people whose idea of creativity and design is covering a wall in Post-its with random words scribbled on them. The fact that an HTML form field needs a
Things like this ought to matter, though. Because as flashy, pretty and otherwise lovely as your website might be, if the fundamentals on which it is built are wrong, you’ll be losing a massive part of your website’s potential audience. And I’m not just talking about those with visual and other disabilities who can’t work out how to use your site. What you might not realise is that Google and other search engines will also look at things such as accessibility and the quality of the underlying HTML code, and will then use this when ranking your site in their query results. If the search engine spider encounters lots of broken links, pages with bad HTML or content that won’t render well on mobile devices, you’ll find your website appearing way down the list when someone goes looking for stuff.
It’s quite right that search engines do this. Their aim in life (apart from
“If you go to one of the big agencies, what you’re paying for is project management”
selling advertising) is pointing people towards the best websites, and if your site is broken then it doesn’t deserve as many clicks. And it’s not something you can generally fix with a quick skim of your website, either. Quality needs to be designed in from the start.
Think of it like building a house. There are loads of people out there who can decorate it and make it look nice, but unless the foundations were well designed and the building structure is sound then it might as well just be a flimsy film set. Too many websites are basically just film sets based around a basic template (perhaps a free WordPress theme) that a designer decorated to make it look pretty.
The other important point is that it’s not just disabled people and search engine spiders that an error-prone site will end up annoying, it’s the rest of us too. I don’t know about you, but if I find broken links on a business’s website then I generally end up looking elsewhere. And the saddest thing is that the company that owns the website won’t even know they’ve just lost a sale.
Regular check-ups
There are various tools you can use to test your website. Perhaps the most important is to register it with Google’s Search Console (it used to be called Webmaster Tools, and you’ll sometimes see it referred to as such in various online resources). Head over to pcpro.link/329search.
This will tell you lots of information about how Google’s “spider” sees your website, including any pages that have errors on them, and how your site compares for a mobile user against someone using a desktop or laptop. The Search Console also shows the search terms that people typed when finding your site, but you need to be very careful with this list as it’s entirely self-selecting.
Let’s take a highly concocted example where you run a website selling laptops. You might find the search terms used to find your site including things such as “best value laptop”, “laptops near me” and “recommended laptops”. But some people would say “notebook” rather than “laptop”, and if you’ve forgotten to use the word “notebook” on your website (see, I said this was a highly concocted example), then the list of Google searches won’t include “best value notebook” or “notebooks near me” even though people will be searching for those things. The list only shows the searches that actually manage to find your website, not those that completely miss it. It’s important to keep this in mind when looking at search term reporting.
You can’t rely solely on Google’s search reporting for testing your site for errors or accessibility, though; other tools are needed. There are four main things that you need to test for: functional errors, HTML problems, CSS issues and accessibility faults.
Functional errors include things such as bad links and missing images. There are many tools available for such testing, but one that I really like is Checkbot ( checkbot.io), a browser extension for Chrome. It very quickly scans through a website looking for broken links. The free version will scan up to 100 pages at a time, and that will cover the vast majority of SME websites. You can upgrade to Checkbot Pro for a tenner a month, which removes this limit and adds numerous additional testing and reporting features. My top tip is to look for a banner at the top of the Checkbot website, where you’ll find the company sometimes runs promotions – at the time of writing it’s 50% off for the first year.
When it comes to checking for HTML errors, again you’ll find that there are myriad tools available. But if you’re looking for something that’s free, reliable and that won’t keep nagging you for commercial upgrades, then it’s hard to beat the official W3C validator from the Worldwide Web Consortium. You’ll find the original checker at
validator.w3.org, but I recommend you use the newer one from validator.w3.org/nu.
You can ignore the warning about it being experimental; it works fine.
Unfortunately, both validators only test one page at a time. That’s fine if you want to check a new page after publishing or revising it, but not so helpful when you initially come to test the many pages of your website. If you’re slightly technical you can get the source from github.com/validator/
validator, and with that you can batch-check multiple URLs (for more details, see pcpro.link/329validator).
For CSS checking, again the best free tool is from W3C, and the
validator.w3.org/nu validator will work just fine (either via the website or built locally from the GitHub source), although you can still use the original standalone CSS validator, which you can find at pcpro.link/
329css. Whether you use the original or “nu” checkers it’s worth checking out the options available via the relevant links or buttons.
When it comes to accessibility, there’s a huge range of automated site testers available, but you’ll find that they give quite different results. The problem is that website accessibility is such a broad subject, encompassing many different elements, and each of the tools available will probably just test a subset of these. There’s a whole range of competing standards, too.
In particular, you’ll see WCAG mentioned, which stands for Web Content Accessibility Guidelines and is published by W3C, and within that there are three revisions: 1.0, 2.0 and the latest, 2.1, which was published in 2018. But then within each of these revisions you’ll find further breakdowns. For example, WCAG 2.0 has A, AA and AAA tests for accessibility, with AAA being the highest standard.
You’ll also see Section 508 mentioned. This is a US government initiative and it includes all consumer technologies, not just websites, so it
“There are four main things that you need to test your website for”
applies to things as diverse as train ticket ordering machines, mobile phones and even TV remote controls. But it does also apply to websites, and some accessibility checkers (especially those created by US companies that regard the US as the world) only focus on Section 508 tests and totally ignore WCAG.
As a result, you can have a website that fails miserably with one checker while passing with flying colours when using another. A good starting place is from 18F (the US government’s official digital agency), which publishes a list of resources at pcpro.link/32918f. While you’re on the 18F website, have a look through all of the pages shown in the left-hand navigation panel.
The other thing that people often forget, especially on corporate websites, is that it’s not just the web pages that need to be accessible – any PDF downloads should be too. This includes things such as document titles, tagging and alt text on images. Luckily, Adobe Acrobat (part of the Creative Cloud suite) includes a handy accessibility checker with easy-fix options for many of these things.
It can be a pain firing up lots of different tools to check the different aspects of your website, so it’s also worth looking at the various all-inone site testers available, although none of them is free. The two main players are Siteimprove and Sitemorse. Another one worth looking at is Little Forrest, although that concentrates more on accessibility, whereas the other two go deeper into the code quality aspects of your website. Personally, I’m a big fan of Sitemorse and my company has been using its services for many years.
Sitemorse also publishes its “Index”, where it regularly tests all of the websites across a given category (see sitemorse.com/index). It’s nice to be at the top of these lists (one of our sites regularly tops the London-listed PLCs index), but it should ring alarm bells for those companies or organisations whose sites sit at the bottom on the index. You’ll find some big names there too, with Bodycote, JD Sports, Savills and Dr. Martens near the bottom of the PLC list, and places such as Hull, Cardiff, Guernsey and Carlisle languishing at the bottom of the local government index.
Whether you use individual tools or an all-in-one website testing service, the most important thing is to ensure you run the tests regularly, because a rogue update to your website can easily render it invisible to search engine users, especially if the broken element is in something such as a footer include file, which runs across all your pages. Been there, done that, got a whole drawer full of the T-shirts.
Automated testing can only go so far, though. Sometimes you need hands-on testing to iron out the real problems. Take colour vision, for example. You probably know that one in 12 men are colour blind (one in 200 women, too), so a person might not be able to see red text on a green background, say. It’s hard to test for this using automation, especially if some of the text is within images. There’s a really useful Chrome extension called “Let’s get color blind” (note the US spelling) that simulates how people with various types of colour blindness will see your website. It’s great for spotting any major issues, although if you’re working on a big-budget website with a wide audience I’d strongly recommend getting your colour-blind team members, friends or relatives to also give the site a once-over.
Web-based tools
I mentioned at the start that my team and I spend more time creating web-based tools than we do websites these days. For example, we run the online table booking system for a major pub and restaurant chain. Another system is used by B2B legal practices to share confidential information with their clients. We also look after several intranets, extranets, online brand manuals, media libraries and other “non-public” systems.
The thing is, a web-based business tool is effectively just a website. It runs in a browser and, as far as testing is concerned, it shouldn’t be treated any differently. It might live behind a login or a firewall, or perhaps even on a private IP address, but it’s still just a website, albeit one with a bit more logic behind it.
In the past we’ve found that some clients have been reluctant to pay for things such as accessibility testing of these systems, thinking of them as internal tools that don’t need the same level of testing as a big public-facing website. Thankfully our current customers are a bit more clued up.
But take the table-booking system I mentioned above. It operates in thousands of pubs and restaurants, and many of these will have several screens open at the same time – perhaps a PC next to the till, and several handheld tablets used by the meet-and-greeters and the waiting staff. On a busy Saturday evening there are around 3,000 staff logged into the system, and if we assume that there’s an even split between male and female users then well over 100 of them are likely to be colour blind. If they were unable to tell the difference between the colour coding we use to denote whether a table has ordered or not it could be a real nightmare.
The same goes for the functional, HTML and CSS tests that I mentioned above: if the site is going to render correctly on all the various laptops and tablets people use, then the code quality needs to be tip-top.
I hope that’s given you food for thought. In a future column I’ll take a look at website analytics, and how to measure the success of your website.
“It’s also worth looking at the various all-in-one site testers available”