How to use strategic planning to improve web accessibility?
Most companies are not aware of the accessibility issues of their websites until someone points them out. In best case scenario, they have obeyed a couple of general guidelines, like using image alt text, navigate using the keyboard, correct resizing … But many of them are using a “we’ll fix it later” approach, leading to web pages that are optimized later on. However, this approach is not always possible.
Making posthoc changes is possible when a piece of code can simply be added or restructured — like adding additional picture sizes or resolutions to adopt different screen sizes, or like adding alt text to images after the site is complete. However, frontend development (should) always start with a design. Changing specifics afterward, like changing body fonts is a major deal in touch-and-feel of the website (yes, it’s a small change in the code but has a major impact on the presentation).
At Smashing conference in 2014, a designer Yesenia Perez-Cruz introduced an interesting idea for the “from the start” approach to accessibility optimization. She calls it Performance budget.
Watch full video: Design Decisions Through The Lens Of A Performance Budget
First, you have to determine your budget, which works like with every other budget. Your resources are limited and you have to be aware of that. Resources that we are addressing hereby are page size and number of requests.
The single page size is not a file size — it’s more than that
Page size in this context is the total size of the page. Contrary to the traditionally used file size, this information sums up all the files (data, images, CSS, JS …). So the budget determined includes the sum of all files and this is really the tricky part: images can take up a whole lot of bandwidth and — believe it or not, fonts are not innocent either.
Perez-Crus proposes to predetermine a maximum page size and take it from there. Trade-offs are mandatory, as otherwise, the budget is unrealistic. She proposes 400 kb, though in 2018 this number could as well be increased. So, how to make some tradeoffs? Well, selecting a specific special or Google font in 1 weight, e.g. 400, regular and italic for headings, can require you to use system font for body texts. You can also compensate for using fewer images or different image formats (SVG instead of GIF).
A number of (HTTP) requests — what is that?
Modern sites, especially some Wordpress themes are extremely heavy on files. Some load a couple of CSS files for responsive design, a few JS files for additional features, adding external fonts etc. Each such file, including image and video, is an HTTP request. It starts with a single request for the page, which then uses code to make additional requests for additional files. Once everything is downloaded, the page can render and function properly. But here’s the catch: the more requests the slower the loading time.
Why is that? Well, in theory, each external file could only include a very optimized code and therefore the page size (see above) could hardly differ from having everything in one file. However, each request extends the loading time as the browser has to make a request and server has to respond. Chain requests are also possible (the first file requires the second one, which requires the third one) and this makes things even worse.
Using external files is not simply bad and should be avoided. Not at all! It can be very beneficial — having one CSS design file for all the pages saves maintenance time, development time and with browser cache properly implemented it also saves loading time on repeated visits. But a number of requests should be kept at a minimum, to enable fast loading.
Using the Performance budget
In a real-world project, poorly determined performance budgets may sometimes lead to project holdups and weird tradeoffs. However, having a written guideline on page size and a number of requests prior to implementation can help the teams think about optimization from the start — and maybe you will even avoid adding useless features to the site because they “look good”. Performance should still win the battle between Nice to have and Working fast (using minimum resources).
