When it comes to crafting web sites, we often think of doing things that please search engines such as Google. This has the potential to lead us down a path where we think of Google first and users second. What happens when coding something for better optimization from Google’s perspective clashes with coding something that is better for people with disabilities?

Earlier this year Google announced speed is going to be included as a signal in their search algorithms.

Right around that time I was in Phoenix for the 2010 IA Summit, and on Wednesday in my Real World Accessibility for Ajax and Web Apps workshop, an attendee asked about the issues of speed. At his company they’ve been focussed on speed of service delivery for their web site. To the point where they’ve changed the markup to be leaner. For a navigation menu, instead of using an ordered list, they were using simple links without any other markup.


<ul>
	<li><a href="page1.html">Page 1</a></li>
	<li><a href="page2.html">Page 2</a></li>
	<li><a href="page3.html">Page 3</a></li>
	<li><a href="page4.html">Page 4</a></li>
</ul>

178 bytes

versus

<a href="page1.html">Page 1</a> <a href="page2.html">Page 2</a> <a href="page3.html">Page 3</a> <a href="page4.html">Page 4</a>

129 bytes

For that component alone, that’s roughly a 30% reduction in code. It is faster.

Add in style rules to make the list items display:inline, and include any DOM manipulation or traversal and these differences can add up.

I think most people would agree that the first example with the unordered list is more accessible, and provides more semantic markup. We’ve been coding navigation menus as lists of links for years and you likely have been too, for good reasons:

  • a list of links provides more context (we’re on item 2 of 4)
  • coding it as a list allows a typical screen reader user to jump from one nav block to the next
  • we often use nested lists to denote hierarchy in our navigation (though this example doesn’t)

So, where does this leave us, then?

It seems that at a micro level, speed and basic accessibility (and semantics) are at odds with one another.

I sincerely hope the weight given to site speed isn’t something that overpowers other factors like accessibility. Why? Because site speed is about to be the new big thing that companies focus on in order to try to get to the top of the search results. Thankfully they state: “While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page

Relevance will always be the most important factor (or at least, it better be). Accessibility and speed are important too, so to me, the best way to approach it will be:

  1. write/create hightly relevant content
  2. use semantic markup and ensure your site is as accessible as it can be
  3. use every means to speed up and optimize after you’ve done everything else.

It doesn’t have to be speed versus accessibility, does it?

9 thoughts on “Speed vs accessibility”

Read comments

  1. You make a very good point. Balancing important competing demands can be difficult. OTOH, true performance also benefits users as metrics consistently show improved user engagement on fast sites. Especially on slower devices and connections (like the iPhone I’m using now). #no4Ghere

    1. Nicole — firstly, let me thank you for submitting the first *ever* comment on Simply Accessible! 🙂

      Secondly, I’m interested in the balance and “true performance” — I’m wondering if a screen reader user might actually prefer something a bit slower if it is better markup for their purposes. That would definitely put speed and accessibility at odds, wouldn’t it?

  2. jpvincent says:

    honestly it would be a crime, especially for gaining even 30% on a whole HTML page : those days the HTML is maybe the smallest resource on a page, most CSS / JS are generally bigger (though cacheable)

    I hope developers will remember that it’s more important to have clean (and accessible) code than to micro optimize their HTML : a robot can munge the HTML and save bytes if it’s really needed

    1. Good point about HTML being possibly the smallest resource on the page. Overall, 30% savings on HTML might not end up being that much.

  3. Andy Davies says:

    As Nicola’s already said, it’s about balance and understanding the trade-offs.

    Rather than re-writing the list as a set of links, the original developer would have probably been better off ensuring deflate/gzip is enabled and get that 60-70% saving.

    That said, I see plenty of verbose markup where there’s room to make it more concise and more readable, interestingly it tends to have bad semantics and a poor separation of concerns too.

    Back to accessibility for a moment… how do the screen readers behave with lists these days, do they still read out “bullet” or can it be suppressed with styles now?

    1. Yes, there are definitely means by which the developer can save to a much greater extent. That should make the argument for changing markup to be less semantic a little weaker.

      As for screen readers and what they read with a list — it really depends on which screen reader we’re talking about, what its verbosity settings are and how exactly it is coded. How’s that for a vague answer? 🙂

      1. Andy Davies says:

        “It depends” has always been the answer to “What do screen readers do with this markup”, when I was using them a lot, it tended to depend of which minor version of JAWS you had…

  4. Divya says:

    I have always wondered why we need list for a bunch of links. There are several accessibility scenarios that need to be considered, not just those who use screen readers. This post seems to be quite focussed on those who use screen readers. Even then, I think the reasons cited for use of links do not seem that compelling:

    – a list of links provides more context (we’re on item 2 of 4)
    Most screen readers always provide a list of links found on the entire page. Also, JAWS documentation seems to suggest it can detect when a bunch of links are found together and offers a way to skip them or read them one by one (I have never used it, so I am very curious to know if it works).

    – coding it as a list allows a typical screen reader user to jump from one nav block to the next
    Can this not be done with using nav element in HTML5? Or even using the ARIA role attribute?

    – we often use nested lists to denote hierarchy in our navigation (though this example doesn’t)
    If there is a need for nested links lists are useful (though what is the harm in using headings?). But the case used in this post does not seem to need lists.

    1. Hi Divya, and thanks for the comment.

      Agreed that there is more to this than just screen reader use, but technical markup tends to have the most impact on that group of people so they tend to be top of mind. But you’re absolutely correct — we have more people to consider. You will never ever hear me say otherwise 🙂

      Most screen readers always provide a list of links found on the entire page. Also, JAWS documentation seems to suggest it can detect when a bunch of links are found together and offers a way to skip them or read them one by one (I have never used it, so I am very curious to know if it works).

      Yes, in a screen reader you can easily pull up a list of all the links in the page and you can activate them from there. I’m not sure which JAWS feature you’re talking about — can you provide the details of what you were looking at? Essentially when links are coded in a list (for logical groupings) there is an advantage to knowing how many there are. If I’m in a list of 5 links, I get a sense of the scope of the list. If I’m in a list of 55 links, I get a sense that there are many more. That context is provided by the fact that they are in a list and coded as a group.

      … coding it as a list allows a typical screen reader user to jump from one nav block to the next. Can this not be done with using nav element in HTML5? Or even using the ARIA role attribute?

      Eventually, yes, but the nav element in HTML5 gives us nothing useful at this point in assistive technology. That will change over time. And there is some support right now for ARIA’s role=”navigation” in newer assistive technology, but all of the older versions don’t have that support.

      … we often use nested lists to denote hierarchy in our navigation (though this example doesn’t). If there is a need for nested links lists are useful (though what is the harm in using headings?). But the case used in this post does not seem to need lists.

      There is certainly a use for headings, and a case can be made for keeping hierarchical navigation as separate lists with headings. And you’re right, in the case I pointed to here, there is definitely no need for nesting.

      Thanks again for your thoughts!

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.