Continuing on the idea of creating a living document of my multitudes, I want to talk more about the intentions and the strategy that follows.
So, to quickly recap:
I want to create a living egography for Carlos’ past, present, and future selves.
I’ll do so through stories.
These stories need to be accessible, readable, usable, scalable, citable and sendable beyond my lifespan.
To do so I will focus on standards, such as accessibility, performance (in Part I), usability, and web best practices (in Part II).
These are my intentions, and that’s great but it’s not enough.
Intention without strategy is chaos Kim Crayton
I don’t want chaos, so, a strategy is needed.
Each of these standards will be quantified here and now, i.e. what they are and how I will measure them so that I’m holding myself accountable.
Accessibility
Accessibility fundamentally comes down to answering the question, “How many people will find it difficult to perceive and interact with my website?”
Using the Web Content Accessibility Guidelines (WCAG) and its conformance levels A, AA, and AAA I can measure how bad an issue is; where A is the worst, i.e. some people will find it impossible to use my website; to AAA, i.e. some people will find it somewhat difficult to use my website.
And whilst it’s great to have guidelines, these don’t answer my question.
For that, we need to look at things in greater detail.
We need to look at a single Success Criterion, such as Criterion 1.4.3: Contrast (Minimum).
85.3% of all home pages suffer from texts with low contrast, making this the most common criterion that isn’t met.
Meanwhile, the World Health Organization (WHO) estimates that 1 in 6 people live with some form of vision impairment.
That includes people with mild, and moderate to severe vision impairment and the 36 million people who are blind.
In total, that’s 1.3 billion people, more than the entire population of India, and the number of people who will find it difficult to perceive and interact with my website if I fail to meet minimum contrast requirements.
And that’s for a single criterion.
That, answers my question.
I wonder if I can pair each criterion to the number of people it will impact?
Now, only about 30% of accessibility issues can be automatically detected so I will need to do manual testing as well but automated testing is a decent start and a worthy inclusion in my toolbox.
I’ll use Google Lighthouse and Pa11y to run automated tests on my old website (learning exercise) and this reboot.
Please note that Lighthouse’s accessibility testing suite is pretty fucking basic anyway, and currently doesn’t include metrics to measure how long it takes before Assistive Technology can perceive and interact with pages but it’s better than nothing.
My benchmark is WCAG 2.1 AA, which will form the foundation for my accessibility budget and the bare minimum this reboot needs to meet.
Performance
Performance is answering the question, “How long will a person have to wait before they can perceive and interact with my website?”
Multiple technologies come together to form the cohesive experience we think of as browsing a website but for the sake of talking about performance, I’ll group them into two: server-side and client-side.
In simple terms, server-side is all things that happen on someone else’s machine.
Meanwhile, client-side is everything that happens on your machine.
The concept of Performance then becomes all the things which have to happen on someone else’s machine, and then get sent to yours, where other things need to happen until you can perceive and interact with it.
Different technologies affect performance differently, JavaScript, for example, is notoriously slow to process client-side.
Studies show that 40% of people will abandon a website that takes more than 3 seconds to load and based on personal experience browsing other people’s websites I can confirm that I won’t wait for slow-ass websites either.
I’ll use Google Lighthouse and WebPagetest to run automated tests on my old website and this reboot.
My benchmark is that I want this reboot to be faster than my old website so I’ll be using it to create a performance budget to measure against.
To stay within that performance budget I’ll then have to do one or more of the following things:
- Optimise an existing feature or asset on the page.
- Remove an existing feature or asset from the page.
- Don’t add the new feature or asset.
This one is going to be challenging because the previous site was generated by the static-site generator Jekyll and created static HTML pages, whilst this reboot is running Laravel.
In Part II, I’m going to look at usability and web best practices.