10 guidelines to improve your web accessibility

We put together a list of ten web accessibility guidelines that will guarantee access to your site to any person, in spite of their disabilities.

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:

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:

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.


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?

web accessibility-color blindness
Color blindness is one of the most common vision deficiencies. It affects about 4.5% of the world’s entire population (and more than IE11 users, you know…).

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.

web accessibility-color blindness

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

web accessibility-caniuse-website

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 the Stark plugin for Sketch that helps you design with accessibility in mind!

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.

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 😉

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.

  1. 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=””
  2. 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.
  3. 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.”
  4. 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.

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:

  1. 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.
  2. 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.
    web accessibility-translating-subtitles-Youtube-tool
  3. 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!).

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.

website accessibility-first-html-website

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.

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:

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 datetime attribute.

The ins element represents an addition to a document:

The del element represents deleted content:

Button vs. <a> tag

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

Let’s see:

<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.

Second, if adding an href attribute makes sense (a search component or a lightbox gallery), then we might as well use an a tag and override the link behavior with JavaScript. An image gallery that uses a tags with href will degrade gracefully if JavaScript is not enabled.


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 <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.

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 <nav> tag, “link” for the <a> tag, and so on. That means that a role attribute is only necessary when we wish to change these default values.

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:

Method Action on View Action on Screen Readers Compatibility
CSS: visibility: hidden; Hides element from view but its original space remains occupied (pretty much like opacity: 0;) Not readable Works everywhere, yay!
CSS: display: none; Hides element from view and its original space is lost, next element in the flow will take its place. Not readable Works everywhere, yay!
HTML5: hidden attribute Same as display: none; Not readable IE 11+
Aria-hidden = “true” Content is displayed in the browser, but not conveyed to the user via the assistive technology Not readable IE 11+
CSS: .visuallyHidden class Hides the element from view and removes it from workflow Readable Works everywhere, yay!

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)

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 <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!

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:

  • ChromeVox: Available for Mac and Windows users, this Chrome extension is a screen reader you can use to test your website.
  • Accessibility Developer Tools for Chrome: Another great extension for this browser that adds an accessibility audit option in your everyday developer tools.
  • Color Filter: Test your website for different types of color blindness with this online tool.
  • W3C Validator: This official W3C tool will let you know if your HTML markup follows the web accessibility rules!
  • 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.
  • WAVE: A web accessibility evaluation tool made by WebAIM.

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:

web accessibility-xapo-network-landing page
(Xapo Network and Store landings abides by guidelines 1, 3, 5, 6, 7, and 9. It doesn’t apply 2 and 7 100%, but it’s headed that way.)

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.

Have something to add to the conversation? We’re all ears!

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. I’ve been in the web accessibility business for over fifteen years, so I’ll mention that the BOIA tool linked to above must be new; I’ve never heard of it.

    A valuable source for exploring tools is this page from the Web Accessibility Initiative:

    as well as this, where new tools can be submitted for consideration:

    Since directing people to the WCAG 2.0 Recommendation can be overwhelming, for developers, this might be a better place to start:

    WAI typically suggests that the recommendation, itself, is not written for developers, but there are plenty of supporting documents on the site that are.

    For example, there is Easy Checks:

    I generally recommend the WebAIM.org site as a place with many good articles (that cover ideas in manageable chunks with code examples). And the WebAIM email list can offer good answers.

    Finally, for those who prefer Slack for communicating, Check out a11y Slackers.

  2. Under ‘7. Use roles when necessary’ (Geez, why don’t h3 headings have IDs?), shouldn’t role="button" not appear in the HTML, but be added to the a element with JavaScript? Because without JavaScript, it is a link?

    1. Good catch! If we are using a tags so it can degrade gracefully if JavaScript is not enabled adding the role with JS makes sense 🙂

      PS: We have updated the post with IDs!

  3. Great article! I always wonder why they usually add aria-label, aria-hidden and a thousand of other kinds of stuff like in this article.

  4. While it’s great to see this topic covered, probably worth clarifying some aspects.
    For “Time vs. Datetime” there’s little explanation here about the benefits of using that markup. Indeed, current browsers don’t do anything (useful or otherwise) when encountering these elements – so currently they appear to only be useful in situations where a page is scraped/processed by some other tool (like an aggregator or similar).
    Testing this with various browser/AT combinations, the only one where the use of the time element had any impact was Chrome+TalkBack on Android – here, TalkBack announces “time” at the end of any time element, which actually leads to very confusing output (e.g. “August 7th, time”). So I’d be careful here, as there’s potential to make content read out unnecessarily weird. Note that even in Chrome+TalkBack, the additional datetime attribute had no effect/was not accessed nor announced to the user.

    Similarly for “Del and Ins”, the only browser/AT combination that did anything with these elements is IE11+NVDA. Here, the user would correctly hear “deleted” and “inserted” respectively when encountering those elements. Again, the datetime attribute was not exposed to the user. All other browser/AT combinations ignored those elements, meaning that they gave no indication to users when something was marked as deleted. For this reason, I’d strongly recommend NOT to rely on these elements, as AT users will not be told when something is present but marked as deleted, leading to confusing (and in most cases probably wrong) output.

    1. Indeed, lack of implementation is sad 🙁 But when we want to show deleted and inserted content with del and ins we should find a proper way of telling sr users, perhaps aria-* attributes could help!

  5. If you haven’t started using the Chrome extension from Siteimprove, do it! One of the better automated testing tools available.

  6. @Eva,

    I cannot reply to a comment, so I am pasting yours in first:

    Indeed, lack of implementation is sad 🙁 But when we want to show deleted and inserted content with del and ins we should find a proper way of telling sr users, perhaps aria-* attributes could help!

    In the case of the del, ins, and time elements, ARIA attributes likely will not help as they generally only apply to specific type of elements: interactive, landmark, and widget. See this for more information: https://www.paciellogroup.com/blog/2017/07/short-note-on-aria-label-aria-labelledby-and-aria-describedby/

    If you do give it a go, please report back on your testing as I would love to hear which browser / assistive tech combos support it.

  7. The portion about SVG (at the end of item 3 on alt text) is misleading. Using and tags is great, but it takes more than that to make accessible to screen readers. Depending on usage, you may need the following attributes: role-image, aria-label, aria-labelledby. It’s a bit complicated because the level of browser and AT support is somewhat inconsistent. And last I checked, even when coded well, Safari+VO is failing with non-linked images.

    For more, see:

  8. Thanks for putting this list together!

    A couple of items I wanted to mention regarding some ARIA attributes you mention:

    aria-hidden is well supported by screen readers using browsers aside from IE 11. VoiceOver respects it when used with Safari, and NVDA (usually) respects it when used with Firefox. The exception is that aria-hidden content inside programmatically conveyed form labels can sometimes be read.

    Similarly, aria-label is well supported, but can sometimes conflict if an element contains actual content: often both will be read, which may be confusing. Additionally, aria-label support is not consistent on elements that don’t receive focus, so it shouldn’t be relied on for non-interactive elements. Generally if aria-label is meant to replace content, hiding the content is recommended. It’s also possible (and often recommended) to use visually hidden text instead of aria-label to provide the same type of support across the board. The HTML5 boilerplate includes a class to do so!

  9. Great check list, but I would add one more thing to you last chapter about review. That is to use the page with keyboard only. It’s not as powerful as testing with a screen reader, but it’s a lot faster and easier to learn, thus very useful to check that markup is in the right order and that links and form are implemented correctly.

  10. Your article on web accessibility is so detailed and informative, Eva. Trying to include all groups of people is such a key part of gaining traffic. Using things like segmentation analysis lets you know how to attract which kind of groups. Thanks for the awesome article.

  11. These aren’t enough to guarantee accessibility.

    I’m strobe-sensitive. I haven’t had clear-cut seizures, but do get migraines, vomiting, and other symptoms.

    These guidelines don’t address risks from strobes and animation. These cite the w3 guidelines, but they are inadequate. I can get migraines from flashing cursors, from flashing images at 0.2 Hz – well below their standard of 3 Hz -, from zooming suc as Google Maps and their imitators, from side-scrolling, from jitter, etc. I also have trouble seeing near flashing cursors, etc.

    These guidelines don’t address compatibility with scrolling software. I’ve encountered sites which are incompatible with my scrolling software.

    This site also animates if I scroll up. Two icons pop from the top of the screen.

    1. Hello Marja!

      There are, indeed, a couple things we missed. We are strongly looking forwards to working with vestibular disorders and creating a better experience for everyone.

      Soon, we’ll be sharing another document that includes some of Rachel Nabors’ research on the subject, with DevTools Challenger ( http://devtoolschallenger.com/ ) as an example and the reduced-motion media query.


  12. Thank you for this article. I’m quite familiar with much of this – the “HT” part of “HTML” accessibility, but it’s always worth a brush-up.

    Right now, I’m looking for general recommendations about accessibility for more “app-like” content (e.g. a web app) – where the content is more like a ‘game’ with controls/HUD etc., where some of the content goes on in a space rendered independently of the DOM (such as a canvas or a plugin). We’d like to expose this non-DOM content to screen-readers and other accessibility tech, and we’re very curious what kinds of solutions, best practices or gotchas may be out there. Any tips on this? Thank you!

Subscribe and get a free puppy!

Well, maybe not a puppy but definitely some kick-ass design and development insights once a month.

Ooops, there was something wrong
You can expect Awesomeness in your inbox shortly!
Subscribe to Aerolab's Blog Ooops, there was something wrong
You can expect Awesomeness in your inbox shortly!