Making the Website More Accessible with HTML5 & CSS3

Presented at the Amigos Library Services’ HTML5 & CSS3 Online Conference a couple of weeks ago. It was recorded, but the recordings are not public, so instead, I’ve included my deck and a slightly edited version of the script that I used.

Presentation on Speaker Deck

Definition of Web Accessibility

Most seem to define web accessibility to mean making the web accessible to those with disabilities, including visual, auditory, motor, and cognitive (W3C Web Accessibility Initiative (WAI)’s definition).

I prefer the more general meaning, of making the web accessible equally to everyone, including those with disabilities (Wikipedia’s definition). That is, regardless of whether someone has a disability, they should be able to access information in their preferred manner including using any browser, operating system, or device.

However, since most people use the term to focus the discussion on making the web accessible for those with disabilities, particularly those who use assistive technologies (AT), that is how I will generally use the term as well.

Why Should You Care?

Legislation & Regulations

Legislation and regulations exist in many areas stating that public institutions must adhere to a set of web accessibility guidelines. Even if it’s not legislated, many institutions (public and private) will have policies or mandates that require or promote equal or equivalent access to all users.

In Ontario, we have the Accessibility for Ontarians with Disabilities Act (AODA), which states that all public institutions must conform to the Web Content Accessibility Guidelines (WCAG) by next year.

If you’re in the US, check out the Section 508 Government website. It focuses on the government regulations for US federal departments, but includes lots of general resources.

Increased Access

Public institutions serve a very diverse group of people. While persons with disabilities is a minority, in all public institutions I’ve worked in, the ideal is to serve one minority as well as any other minority and the majority. Everything from mild to more extreme cases, adhering to web accessibility guidelines can help to serve:

  • blind users, who will use screen readers
  • low vision users, who may use screen readers or magnifying tools
  • color blind users
  • mobility impaired users, who might only use a keyboard
  • users with cognitive or learning disabilities
  • and more…

Better for Everyone

While web accessibility generally focuses on providing and improving access for persons with disabilities, making sure your site follow a set of guidelines can also improve the experience of your other users as well.

So while most of the improvements I’m talking about will focus on increasing access for those with disabilities, my presentation today will also cover the broader meaning of web accessibility to include all users.

I also apologize now if the techniques I’m talking about seem a bit random, but I will be focusing on things I’ve implemented in the recent redesign of my library’s website and then only on the HTML5 and CSS3 elements, ignoring all the things I changed for accessibility purposes that existed pre-HTML5/CSS3.


Proper & Valid Markup

Whether you’re new to HTML5 or not, it is of course always a good idea to make sure your HTML code validates every so often. Using a validator, such as the w3c validator, can be particularly useful to check that you’re not only using HTML5 elements correctly, but that you’re also no longer using elements, and particularly, attributes that are deprecated or obsolete.

Section Elements

Of all the new HTML5 elements, the new section elements seem to be the most commonly known, so hopefully you’ll have at least heard of most of them.

  • header
  • hgroup – group of headings, e.g. heading has subheading
  • nav – global navigation
  • article – self-contained piece of content e.g. blog entry
  • section – generic section of the content e.g. book chapter
  • aside – tangentially related to the content around it, e.g. sidebar
  • footer
  • address – contact info

The idea is that using these elements help those using assistive technology determine the purpose or role of various sections of a webpage without further coding needed. Great right?

Unfortunately, while HTML5 support increases with every release, HTML5 accessibility support varies by browser and assistive technology software. To help your users using assistive technology in the meantime (that is, until HTML5 is fully supported), it is recommended to use ARIA (Accessible Rich Internet Applications) roles. These are normally only used for custom aspects, particularly interactive pieces, but help during this transition period.

The problem of course is that unless you’re already familiar with the topic, you might never have even heard of ARIA, let alone understand how you would apply them. Honestly, you’re not alone. There just isn’t a lot of documentation out there (at least that I have found), but a working draft on Using ARIA in HTML has been recently created. The recommendations table lays it out simply for you which ARIA roles should be defined based on current overall browser support.

A simple way to think about it is that a role tells the user the purpose of the element or the content in the element. For example, the purpose of ‘nav’ is providing ‘navigation’, or the purpose of ‘footer’ is to provide information about the webpage, such as copyright or privacy statements.

If you put it all together, the structure of a page might look something like this:

<!DOCTYPE html>
<html lang="en">
    <title>Every Page Should Have a Title</title>
    <header role="banner">
        <h1>site name</h1>
      <nav role="navigation">
        <a href='#'>Global Nav Link</a>
        <a href='#'>Second Nav Link</a>
        <a href='#'>More Nav Link</a>
      <div id="content" role="main">
        <article role="article">
          <!-- your content, a blog post for example -->
        <article role="article">
          <!-- another standalone piece -->
      <div id="secondary" role="complementary">
            <!-- typically your sidebar -->
    <footer role="contentinfo">
            copyright and other info

Embedded Content: iframe

I’m not going to touch on most of the new embedded content types. As you can tell from the conference program, audio/video and the canvas elements are presentations onto themselves. But I do want to touch on iframe. I try my best to avoid iframes (that is to say I avoid them like the plague) not least of which is because it’s not very accessible, but also because it’s difficult to control. Interestingly, I find it almost impossible to avoid in library websites that use third-party or hosted services, like ours does.

Long story short, of all the accepted changes going from HTML4 to HTML5, I have found the new iframe attributes to be the least supported. Only Chrome and Firefox support some of the new attributes, but then don’t behave the same way when dealing with deprecated attributes. For example, we use iframe to display licensing information on our e-resources pages.

I wanted to make sure there is no scroll bar. In HTML4, you had the ‘scrolling’ attribute, but in HTML5, it’s recommended instead that you apply the CSS: ‘overflow:hidden’. Unfortunately, in Chrome, it didn’t work and even seamless didn’t help, so I still had to keep the scrolling attribute. This was, however, a few months ago, so it’s possible Chrome has fixed this by now.


There are quite a number of new form input types and attributes that are great not only for accessibility purposes, but for general usage as well. What’s really great about the new input types and attributes is that the browser can check and warn the user if there is an error even before it’s submitted.

New Types:

  • search (mostly stylistic)
  • tel (doesn’t enforce set pattern)
  • URL
  • email
  • date/time – various
  • number
  • color

New Attributes:

  • placeholder – not read by AT
  • autofocus – don’t use for AT reasons
  • required
  • and more

Alright, that covers HTML5, so now we’re going to switch gears and move on to CSS3.


There are so many new CSS3 properties, especially around image manipulation and animations, but I admit, I haven’t played around with most of them. Because CSS is all about presentation, there is also little in this section to do with web accessibility per se, but will be about improving content for general visitors or sometimes for you, the developer.

Adjacent Selector

There are two new selectors in CSS3, one of which is the adjacent selector. It’s basically a conditional that says if you have element 2 immediately following element 1, then apply this to element 2.

The biggest advantage I’ve found with the adjacent selector is being able to write simpler (and less) code with less classes, which means less load time. Admittedly, CSS load time is negligible in most cases, but still helps.

Structural Pseudo-Classes

Some new useful structural pseudo-classes have also been added to CSS3. In particular, is: :nth-of-type

Here’s an example. Remember when you had a table and wanted to do zebra lines, you had to add class even or odd (whichever you preferred) to every other row in a table? Well, no longer! You can now use :nth-of-type. Let me explain how it works.

We’re going to take a trip down memory lane to elementary math class when you first learned algebra. nth-of-type along with the other similar new pseudo-classes use the simple:

an + b
where a and b can be any integer

For example, if I have 3n – 1; n can also be any integer, so we could use negative numbers, zero, and positive numbers to get the result. Of course, there are no negative results when counting elements in HTML and CSS, so we get to throw out any non-positive results.

In this case, we would apply our CSS properties to the 2nd, 5th, 8th element and so on.

So, going back to our table, if we want odd rows, we would use:

tr:nth-of-type(2n+1) {
  background-color: #CCC;

For even rows, you would use 2n. Luckily, to make things simpler, there also exists the special words ‘even’ and ‘odd’, so you could actually write it this way:

tr:nth-of-type(odd) {
  background-color: #CCC;

Similarly, in CSS3, we also have :nth-child. Using nth-child applies properties to that element, but the counting occurs regardless of the type of element under the same parent. An example is the best way to explain it. Say you have:

  <h2>Red Pandas</h2>
  <p>are cute.</p>
  <p>are sloths.</p>
  <p>are playful nonetheless.</p>


p:nth-of-type(odd) {
  color: red;
p:nth-child(odd) {
  color: red;

Using nth-of-type, the first and third <p> are coloured red. However, consider that the div here is the parent and the rest are its children. <h2> is its 1st child, the ‘cute’ <p> is the 2nd child, etc. Using nth-child, that’s how it counts and applies the CSS. So, only the 2nd paragraph is coloured, because the 1st child <h2> is not a <p> and the 3rd child is the ‘sloth’ <p>.

Hope that makes sense to everyone.

Also available:

  • nth-last-of-type – starts counting from the “bottom”
  • nth-last-child
  • first-of-type – only the first one
  • first-child
  • last-of-type – only the last one
  • last-child
  • only-of-type – applies it to the only one under the parent (assumes there is only one)
  • only-child


Another really useful one is the new attribute for box-sizing, called border-box.

You likely know that the default is to specify the width and height of the element, then padding, border, and margin are drawn outside of the specified width and height.

Now, if you specify: box-sizing: border-box; The width and height you specify includes the padding and border. Using border-box can really simplify how you calculate the layout and help with making sure your website looks the same cross-browser.

Media Queries

Alright, so what’s all the rage right now. Media queries. In particular, media queries are the basic building blocks to making a website responsive.

Taking it a little farther, say you have media queries based on some pixel values. The actual values, determining breakpoints are arbitrary. As my colleague, Matthew Reidsma would say, your breakpoint is determined by “when it looks stupid”.

Using pixel values, however, are not ideal. I won’t go into all the reasons, but using em sizes instead of pixels increases the accessibility of the site, particularly for those users who use the zoom function. As a person zooms, the site will re-flow according to the media queries, regardless of the screen size when the page is first loaded.

If you’re not already using media queries, you might consider using a framework, such as Foundation or inuit.css.


Okay, so now that you know a lot of new HTML and CSS, let’s talk about fallback. Fallback, I think, is particularly important, because I don’t know any library that doesn’t use a slightly older version of one or more browsers. For most browsers, if you’re only one or two version behind, that’s not necessarily a big problem (you can check support for individual elements or properties on the Mozilla Developer Network) and most new elements and properties will degrade just fine. (Although, you always want to be on the newest version, especially with the constant accessibility upgrades.) Still, the fact remains that our users do not always use the most up to date version of any given browser, so we need a fallback.

HTML5: Internet Explorer

I haven’t actually encountered any issue with HTML5 in most browsers, even older versions. The exception is older versions of Internet Explorer. IE7 is particularly a problem, but even IE8 creates a number of issues. As a fallback, the simplest way is to use JavaScript scripts purposely made for IE. On our site, we use:


I’m simply going to say that for simpler things this should be built into your CSS. If you’re using gradient, have a solid colour as a fallback.

The font-face “bulletproof” syntax is a good example, as it basically covers all possible cases.

And actually, sometimes you might not have anything, like my table example, because zebra lines are helpful, but not necessary.

Just like with HTML, there are various scripts that can help you with CSS fallback and transitioning to CSS3. Since a lot of properties usually start out using prefixes e.g. -moz, -webkit and it can be difficult to keep track of which version of a browser dropped it and when it might be dropped in the future, consider using Prefix Free. It’s a simple JS file which will automatically insert prefixes into your CSS where it’s needed.

For more complex CSS3, such as media queries (which is especially a problem in IE prior to version 9), again, the simplest is to use a JavaScript fallback, such as respond.js.

If you want to avoid having so many individual JavaScript files loading, and especially if you’re concerned with supporting older browsers other than Internet Explorer, consider using modernizr. Modernizr is a JavaScript library that detects various HTML5 and CSS3 features, allowing you to write conditional JavaScript and CSS.


What’s new in HTML5 and CSS3 is great, just make sure it’s still accessible and degrades nicely.

Other Accessibility Resources

Author: Cynthia

Technologist, Librarian, Metadata and Technical Services expert, Educator, Mentor, Web Developer, UXer, Accessibility Advocate, Documentarian

Leave a Comment

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: