10 guidelines to improve your web accessibility

There’s a quote by Tim Berners-Lee, Director of W3C and inventor of the World Wide Web, that says, “The power of the web is in its universality”. As people who make a living by making websites, it’s our responsibility to ensure everyone has access to them. Web accessibility seems like a tall order on paper, but it’s definitely much easier than it sounds.

Our ten web accessibility guidelines are designed to ensure that all websites are universal.

This will not only help screen reader users, but will also improve browsing experience for slow connections. We’ve sorted our guidelines by implementation time to give you a clear picture of just how much effort you’ll have to put into this process. Before you get overwhelmed, take our word for it—it’s totally worth it.

First things first:

{misc-bullet1}

What the heck is Web Accessibility?

According to W3C, web accessibility means that every person can perceive, understand, navigate, interact with, and contribute to the web. In this regard, website accessibility encompasses all conditions that affect access to the web, including visual, auditory, physical, speech, cognitive, and neurological disabilities.

You’ll find a bunch of content on this topic around the web, and you should really look deeper into the Web Accessibility Initiative (WAI) if this topic interests you.

With that in mind, here are our guidelines:

{misc-bullet1}

1. Do not depend on color (~ 45 minutes)

Color is a powerful tool we often use to express emotions and communicate messages on the web. However, we shouldn’t put all our faith in color to convey meaning and information to our users.

Why?

For example, it’s widely known that green means “right” and red means “wrong,” but what happens when we use this as our only mean of communication?

If we display important messages in our user interfaces using only color to convey information, we are leaving 4.5% of the population behind.

Color should complement an error or confirmation message, but it cannot be the only tool we use. In order to be certain that we reach all our users, we should always add labels or icons that display whether filled information in a form is right or wrong.

A very interesting solution was adopted bycaniuse.com, which provides an alternative color palette to display the content of their compatibility tables.

It is ideal to check for color blind and contrast while designing, so make sure that you and your design team have the right tools. We highly recommend theStark pluginfor Sketch that helps you design with accessibility in mind!

{misc-bullet1}

2. Do not block zoom (~ 5 minutes)

In the age of responsive design we might have made a few irresponsible mistakes.

One of these is the apparition of maximum-scale=1.0, which disables the functionality to zoom in on web pages using mobile devices.

<meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1">

Astigmatism affects between 30 and 60% of adults in Europe and Asia, but blurry vision can affect people of all ages and nationalities (Hi mom!).

The ability to zoom in is not just another whiny WCAG guideline, but a tool to simplify everyday life for these people. So next time you are building a responsive website remember to think of my mom every user with blurry vision.

Besides making it possible for users to zoom freely on mobile devices, remember to also check that your layout looks good at up to 200% zoom in desktop browsers.

{misc-bullet1}

3. Rediscover the alt attribute (~ 45 minutes)

No matter how long you’ve been making websites, you might be surprised to know these few tips on the famous, yet mysterious, alt attribute.

• The alt attribute is compulsory to every img tag but an empty alt attribute is completely valid. If an image is decorative or not necessary to understand the content of the page you can simple use alt=””
• Screen readers tell the user that an <img> tag is an image so there is no need to be redundant and begin your alt with “Picture of”; just go straight to the point.
• The function of an image is as important as its meaning: if your logo links to your website’s home page then your alt text should be something like ”Home Page” instead of “Logo.”
• Alternative text is not just about accessibility. Sometimes users with slow data connections disable images to achieve a faster browser experience. Have those users in mind whenever you write your alt attributes too!

But not all images in your website are img tags, right? You might have an SVG or two around there…or a whole SVG icon system.

How do we make SVG accessible for everyone? Luckily for us, the Scalable Vector Graphics standard has us covered! In order to describe our vectors we have the <title> and <desc> tags for short and long descriptions.

<symbol id="langIcon">
    <title>Language Icon</title>
    <desc>Longer description</desc>
    <path d="M0 2C6.47 2 2 6.48 2 12s4.47 10 9.99 0h24v24H0z" />
</symbol>

{misc-bullet1}

4. Add subtitles and captions to your videos (4+ hours)

This might be one of WCAG’s most difficult guidelines to achieve, not because of a technical difficulty, but because it can be time consuming. There are a few ways to get this done:

• Let’s take YouTube for instance. Once you upload a video to the platform you can enable closed-captions. These are automatically generated and might turn out to be inaccurate in some circumstances depending on the language, background noise, or the speaker’s accent. Nevertheless, these are very easy to implement and can work well on most English-speaking videos.
• If we are looking for 100% accurate captions it’s hard to trust YouTube to come up with good copy, so we must write the captions ourselves or hire a third party to do so. YouTube will take the most common subtitle formats (.srt, .sub, and .sbv) as well as letting us write the subtitles on the platform itself, which can be very convenient if we don’t own any subtitle software or if we wish to ask our community to help us translate the content without giving admin access to our account.
  
• But perhaps you don’t want to use YouTube as your hosting platform. Perhaps you wish to use an HTML5 video hosted on your server. We’ve got you covered! HTML5 includes the <track> tag, which you can use to easily attach as many caption and subtitle files as you like using the WebVTT format (Translations FTW!).

<video controls>
  <source src="movie.mp4" type="video/mp4">
  <track label="English Captions" kind="captions" srclang="eN" src="captions.vtt" default>
  <track label="Subtitulos en español" kind="captions" srclang="es" src="subs.vtt">
</video>


{misc-bullet1}

5. Semantics = accessibility (~ 45 minutes)

Font tag, remember? I hope you don’t, those were dark times.

In spite of common belief, semantics weren’t born with HTML5. They have been with us since the first HTML page and have greatly improved since then. With the HTML5 standard, new semantic tags are introduced for our everyday use.

Ok, but isn’t semantics just for SEO?

Not necessarily. When you consciously choose an <h1> tag over a <p> or a <span>, you are deliberately changing the meaning of an element, providing hierarchy, and building a tree structure of your page’s information.

Screen readers are not oblivious to this. In fact, semantics is one of its most useful weapons.

Keep in mind that with great power comes great responsibility, so make sure to use the proper semantic tag for each element, from h1 to the brand new main tag.

{misc-bullet1}

6. Use the right mark-up (~ 30 minutes)

As a follow up to the previous point I’d like to discuss a few false friends and controversial pairs:

Time vs. Datetime

The time element displays many types of date formats, time zones, and durations using the ISO 8601 standard to represent dates and times.

Datetime is an optional attribute that helps represent the content of <time>. Let’s see some examples:

<time>14:54</time> Hours and minutes
<time>2018-06</time> Year and month
<time>-03:00</time> Time zones
<time>2h 32m</time> Harry Potter 2 Duration
<p>CSSConf Argentina took place on <time datetime=”2016-08-07”>August 7th</time></p>


{misc-bullet1}

Del and Ins

The web changes constantly, but there’s no need for those changes to go unnoticed. We can mark edits using the ins and del HTML tags in combination with the datetimeattribute.

The ins element represents an addition to a document:

<time>14:54</time> Hours and minutes
<time>2018-06</time> Year and month
<time>-03:00</time> Time zones
<time>2h 32m</time> Harry Potter 2 Duration
<p>CSSConf Argentina took place on <time datetime=”2016-08-07”>August 7th</time></p>

The del element represents deleted content:


<ul>
    <li><del datetime="2017-06-05">Rewatch Harry Potter 8</del></li>
    <li><del datetime="2017-06-05">Cry because ____ dies.</del></li>
    <li><del datetime="2017-06-06">Write article</del></li>
    <li>Order room</li>
</ul>

{misc-bullet1}

Button vs. &lt;a> tag

Get the popcorn, this is a good one. When should we use each?

Let’s see:

&lt;a> tags are meant to link one file to another or open links in a new tab or in the current one. However, this tag is not ideal whenever we wish to trigger actions such as hamburger menus or image galleries. The button element is the right choice for these situations and is usually achievable with JavaScript.

Also, the button tag can be easily confused with the input type=”button” but the difference relies in the former being able to take more content (text, image + text or only images).

There are two things to consider when using the button tag:

First, if the content of a button is not explicit enough (take an “X” in a close button for example), we must add an aria-label attribute to help explain the function.

<button aria-label="Close">X</button>

Second, if adding an href a

But…

{misc-bullet1}

7. Use roles when necessary (~ 1 hour)

In order to tell screen reader users that our link triggers an action and it is not, in fact, an ordinary &lt;a> tag, we must add the role attribute with the value “button”.

But beware!

When writing your JavaScript you need to call your functions not only on click but also when the user presses the spacebar. This is necessary because the behavior used for buttons is different from the one used for links and the user should be able to trigger the action on either of these commands.

<a href="img/kitten.jpg" role="button" onclick="handleBtnClick(event)" onKeyPress="handleBtnKeyPress(event)">
  Button
</a>

function handleBtnClick(event) {    
  // Do something
}
 
function handleBtnKeyPress(event) {
  // Check to see if space or enter were pressed
  if (event.keyCode === 32 || event.keyCode === 13) {
    // Prevent the default action to stop scrolling when space is pressed
    event.preventDefault();
    
    // Do something
  }
}

Read more about this on MDN.

Bear in mind that aria roles are not usually necessary unless you break the rules, like in the example above. HTML semantic elements have a default role already applied: “navigation” for the &lt;nav> tag, “link” for the &lt;a> tag, and so on. That means that a role attribute is only necessary when we wish to change these default values.

{misc-bullet1}

8. On hiding elements (~ 1 hour)

There are a few methods available to hide things with HTML & CSS. This table will help you find the best alternative for every situation:

If you want to hide elements from view but still let screen readers know about them, then the last option is the best.

This is very useful in form labels or skip-to-content links. The visuallyHidden class is one of those CSS codes that should go into your favorites so it is easy to find for every project. Yes, you can change the name if you like (my suggestion is .pottersCloak, fyi)

.visually-hidden { 
    position: absolute !important;
    clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
    clip: rect(1px, 1px, 1px, 1px);
    padding:0 !important;
    border:0 !important;
    height: 1px !important;
    width: 1px !important;
    overflow: hidden;
}
body:hover .visually-hidden a, body:hover .visually-hidden input, body:hover .visually-hidden button { display: none !important; }

{misc-bullet1}

9. Follow web accessibility standards (~ 30 minutes each week)

Web accessibility is hard and standards and guidelines are here to help.

All previous points in this article lead here: how does &lt;button> work? When should we use it? What’s the difference between display: none; and the “hidden” attribute?

It might be dull at first but not only are W3C standards and WCAG guidelines reliable, they’re also educational. Go ahead and get lost in the infinity of information they provide. I assure you you’ll discover code and practices you never knew existed!

{misc-bullet1}

10. Audit and review (~ 3 hours)

Once you’ve applied all this knowledge, it’s time to test it. Here’s a list of the best tools to audit website accessibility:

1. ChromeVox: Available for Mac and Windows users, this Chrome extension is a screen reader you can use to test your website.
2. Accessibility Developer Tools for Chrome: Another great extension for this browser that adds an accessibility audit option in your everyday developer tools.
3. Color Filter: Test your website for different types of color blindness with this online tool.
4. W3C Validator: This official W3C tool will let you know if your HTML markup follows the web accessibility rules!
5. A11Y Compliance Platform: The Bureau of Internet Accessibility (BOIA) offers a graded report that provides an overview of how your website fares when tested against the WCAG A/AA checkpoints.
6. WAVE: A web accessibility evaluation tool made by WebAIM.

{misc-bullet1}

Aerolab’s experience with web accessibility

We try to make a habit of testing our work constantly. Our next product should always aim to be better than the last. Yes, we sometimes make mistakes, but we strive to constantly improve and adapt, not to mention to learn something out of each challenge.

We want our products to offer the best possible experience to users, which is why we started including accessibility standards to our workflow little by little.

There’s still a long road ahead of us as well as some major room for improvement, but we’re darn happy to have chosen this path.

The landing pages we did for Xapo are an example of how we’ve been applying website accessibility standards, in case you want to check them out:

{misc-bullet3}

Final Words

Website accessibility is not always easy to implement, but if you make it part of your everyday workflow (instead of a last-minute checklist) implementation and testing will become easier over time.

When in doubt, don’t be afraid of asking other developers or doing some research. Some of my favorite sources of information are The A11y Project, A11y Wins, HTML5 Doctor, and MDN.