JavaScript Render Blocking is Bad for Accessibility

If you run a site through Google PageSpeed Insights, there’s a chance that Google has warned you about render-blocking resources. It may seem like an easy problem to solve, but some methods of eliminating JavaScript render-blocking may also cause accessibility issues.

What is render blocking?

Render blocking is best understood when you understand how a web browser renders (reads) your website.

Very simply, a web browser reads your webpage’s code from the top, right down to the bottom of it.

If in that rendering (reading) process, the web browser encounters a Javascript file, it needs to stop reading whilst it downloads and processes that file.

For example, your website may have a fancy Javascript footer, and a file attributed to that footer called footer.js. However, that Javascript may be placed at the top of your code, meaning a browser will have to download and read the footer script before it proceeds and loads the rest of the page.

Your website code may look like the following:

• Header meta
• Footer.js
• HTML for your content

Where this footer is placed blocks the rendering of your page, because the browser needs to read this before loading your page. That JavaScript file is render-blocking.

What are render blocking resources?

Render blocking resources are usually just JavaScript and CSS files.

Images and videos are not render blocking resources, so don’t worry about these. Of course, it’s best practice to optimise any images you embed into your site. But optimising the delivery path of images is unnecessary.

The common ways of eliminating render blocking

With page load speed being important for SEO and user experience, it’s in everyone’s best interests to eliminate the render blocking resources. However, using the most common methods of render blocking will impact your website’s accessibility.

Asynchronous rendering

The most common way for alleviating render blocking is called asynchronous rendering. This lets the HTML parser (the user’s browser) download the JavaScript file whilst still parsing the HTML. It will however stop parsing the HTML when the script is fully downloaded.

Deferred rendering

Deferred rendering allows the HTML parser (the browser) to download the JavaScript whilst parsing the rest of the HTML. Once the HTML has finished parsing, it will then execute the script once this is complete.

Why render blocking and asynchronous rendering is bad for accessibility

When a screen reader of a visually impaired user initially reads a website, it does so in the same fashion that a web browser does so. It reads the elements of the page in a top to bottom fashion.

Crucially though, a screen reader relies on the HTML to deliver the structural elements of each page and identifies where the user can skip to using their assistive technology.

Render blocking resources are bad for accessibility

Without an async or defer attribute, we revert back to the initial problem. The HTML will load, until a JavaScript file interrupts it, which will pause HTML load and execute the JavaScript before loading the rest of the HTML.

This causes screen reader users to be unable to read the rest of the page before initiating the JavaScript.

For example, your site layout may be like this:

• Header
• Navigation
• HTML for first part of the page
• Javascript slider
• HTML for the rest of the page
• HTML footer.

The JavaScript file in the middle is a render blocking resource and when a screen reader reads the site, it will be unable to view any of the HTML (for the rest of the page, including the footer) that is below the JavaScript slider.

Asynchronous rendering is bad for accessibility

One of the most common methods of eliminating render blocking resources, as explained above, is asynchronous rendering. This allows for the HTML to be parsed and a JavaScript file to be downloaded in the background. It will then pause the HTML parsing to execute the downloaded JavaScript file.

However, this presents a similar issue to classic render blocking in that it pauses the HTML parsing whilst the script executes. This, again, means that a screen reader will not be able to read further down the HTML until the JavaScript has been executed.

How to eliminate render blocking and keep your website accessible

Using deferred rendering

The simplest way to do this, is to include the defer attribute to your JavaScript. As explained earlier in the blog, deferred rendering allows for the entire HTML of the site to be parsed and then the JavaScript to be executed once the HTML has finished parsing.

This allows for a screen reader to read the whole page’s HTML without it pausing or coming across any blockers.

Adhering to best practice

Best practice for accessible JavaScript use has always been fairly clear in that it asks: “Does it really need to be JavaScript?” Problems can very easily arise when developers rely on JavaScript too often to solve all of their problems. Sometimes we see a website where everything has been done with JavaScript – the HTML is generated by JavaScript, the CSS is generated from JavaScript, etc. This has many accessibility issues associated with it, including that some users may not be using browsers or hardware that can translate JavaScript.

It’s important to use the right element for the job. The JavaScript powered 3-D information box is all well and good, but would plain text simply suffice?

Best practice is to understand what your users want and implement it so they can find all of the information they need in the shortest time possible. JavaScript can be a great tool for developers when it comes to helping users achieve their goal. But only if it helps them do what they need.

Instead of implementing scripts across our website without thought, we should always ask “Is this what the user needs?” and moreover, we should ask “Will this be accessible for everyone?”