accessibility

Posted on: 16-05-2019

Practical web accessibility guide

Creating a website nowadays is much easier than it used to be several years ago. New tools, frameworks, and libraries allow you to create a unique and unforgettable experience for your users. But at the same time, new challenges emerge. Making the whole thing accessible is one of them.

# Web accessibility vs. Inclusive Design

To create a really accessible experience, you should first… stop thinking about web accessibility.

This term currently has a much narrower meaning than it used to have. When you think about the word “accessibility”, you often think about designing something in a way that would allow people with disabilities to use it. Accessibility has become a synonym of guaranteeing that some, often not precisely defined, “special needs” are met. This is simply not true, as web accessibility should mean making websites accessible for everyone.

This is why nowadays a new term is gaining momentum: inclusivity. This term is about including every person. It moves the focus from “customizing the basic experience to the needs of specific groups of people” to “creating the basic experience that fulfills the needs of all”. This is the primary goal of Inclusive Design Principles — to make a website accessible to everyone:

These Inclusive Design Principles are about putting people first. It’s about designing for the needs of people with permanent, temporary, situational, or changing disabilities — all of us really.

Starting the project with these rules in mind will result in a much more accessible experience, as inclusivity will be built into your product, not attached to it later. In this way you will be putting your customers in the center of the design, making them the reference for all your decisions.

This is, of course, the ideal situation. Yet most of us already have some kind of a website that should be accessible, but it is not… Fortunately, many aspects of websites can be repaired using a reasonable amount of work. Elements of inclusive design are quite easy to grasp and implement even on an already designed site.

# The significance of semantic HTML

The most basic way to make the website more accessible is to use semantic HTML. Semantic markup conveys the meaning rather than just presentation, so it puts focus on the roles that particular HTML elements play on a web page instead of how they look in the browser. As a matter of fact, the entire HTML concept is built around semantics. Without semantics, HTML is reduced merely to “T” — as in “text”. Yet, just like web accessibility, this term has become narrower over time. Nowadays, “semantic HTML” means “HTML with these fancy new HTML5 tags”, such as <main>, <article>, <section>, <nav>, <aside>, <header>, <footer>, <figure>, etc.

Using these tags will increase both User Experience (UX) and Developer Experience (DX). Users with some kind of assistive technology will be able to easily navigate throughout the page thanks to HTML5 landmarks. Developers, on the other hand, will be able to quickly discover how the page is divided into logical parts.

But this is just the beginning because almost every HTML tag has its own meaning, so almost every HTML tag is, in fact, semantic. And thanks to that you can mark nearly every intention in the text. Some fragment is more important than the rest? Use <strong>. A word should be stressed in a different way? Use <em>. A technical term? Add <i>. No longer relevant content, like an expired promotion? See, <s> will come in handy. A fragment of text with a non-textual annotation? Use <u>. Also, most of the interactions are represented as HTML elements, just to mention <a> for links and <button> for buttons. The intended use of every HTML element is described in details in the HTML specification (with examples!).

The biggest issue with HTML semantics is the fact that currently, some parts of it (especially those connected to text-level semantics, like <strong>, <em>, <i>, <u> etc.) are not represented at all in the accessibility tree. However, people at W3C are already working on it.

# More contrast for better readability

This is probably the most common issue connected with web accessibility: the majority of websites do not have enough contrast. This makes them difficult to read for many people, for instance, ones with eyesight deficiencies (like color blindness or vision defects) or ones that are just tired, having heavy eyes. And what may seem less obvious, sufficient contrast is also needed for users with worse monitors, sitting in incorrectly lit rooms or using mobile screens outside during the sunny day. The minimal levels of contrast are described inside the WCAG standard — a real bible for everyone that is serious about the best practices of web accessibility.

There are several tools that can help you test if the contrast is enough. One of such tools is contrast-ratio.com by Lea Verou. There are also several browser extensions, like ChromeLens, that allow for testing not only against contrast but also against color blindness. Additionally, some universal tools that can help you in checking many aspects of web accessibility in one go are listed below. Such extensions are really good in helping to notice why color is, in fact, just additional information and why underline in links is still needed.

# Making interactive elements accessible

Very often websites are created using non-semantic HTML. Even though the use of <b> instead of <strong> is debatable, there is a type of elements that should be used as intended by the specification: interactive elements. Consider the following example:

https://codepen.io/Comandeer/pen/MdYOVp

At first glance, these two buttons look the same and interact with the user in the same way. But there are several important differences that can be easily overlooked if you limit your interaction with buttons to a simple click:

The first button is not focusable. It means that it cannot be activated using the Tab key. A person navigating the website using only the keyboard will not be able to use this button.
The first button is not presented to assistive technology as a button. It is just a plain <div> element that happens to have the “Button 1” text inside.
The first button cannot be activated by pressing the Space key. It is the standard way to activate buttons (alongside clicking with the mouse). Even screen readers hint the users to “press Space”.
The first button cannot submit a form without some convoluted script. “Just Works™” does not apply to it, unlike the second one, which… Just Works™.
The second button is harder to style… But hey, you have all: unset just for such occasions!

The trap of choosing the wrong element for the job is an easy one to fall into which may have a negative effect on web accessibility. Using what appears to be the “safest” (semantically transparent) <div> element and adding the behavior with JavaScript and appropriate styles with CSS is not always the best way. However, in the case of interactive elements, the following rule of thumb applies: if you want to navigate the user to another page or website (or another place on the same page), use a link. If you wish to invoke some action on the page, use a button.

And if you find yourself doing something like this:

<button>
  <a href="/">Go to the homepage</a>
</button>

then you probably want to have links styled as buttons… and you might want to think if it is really a good design.

# Adding styles to buttons

Accessible buttons built using <button> elements are only 50% of success in implementing nice, usable buttons. You have probably noticed that the button you created is not as interactive as it should be. It does not have a click effect (like native buttons). The blue outline, visible after focusing the button, is also not visible — and without the outline, it is really hard to navigate using the keyboard. This is why you should always prepare styles not only for the initial state of your elements but also for the interactive ones (e.g. :hover or :focus). This is how you can improve the button:

https://codepen.io/Comandeer/pen/mYypPJ

The first button remains the same, while the second one has styles now. And it seems really usable.

# Is an image worth a thousand words?

This is true as long as you can see the image! However, some people cannot — not only due to their disabilities but often because of some other circumstances (like a poor network connection on a mobile). This is why describing every image with the [alt] attribute is so important.

The content of the [alt] attribute depends on the context. The description of the same image can vary depending on where it is placed. The best example of such an image can be a logo. If it is used inside the navigation bar as a link to the homepage, it should indicate the purpose of the link:

<nav class="navbar">
  <ul class="navbar__menu menu">
    <a href="/" class="menu__link">
        <img src="/images/logo.svg" alt="The name of the company" class="logo">
        <!-- alternatively:
        <img src="/images/logo.svg" alt="Return to the homepage" class="logo">
        -->
    </a>
    [...]
  </ul>
</nav>

However, if the same logo appears in a portfolio section of the site, it does not represent the company anymore — it represents itself as one of the presented works:

<section class="portfolio">
  <h2>Our works</h2>

  <ul>
    <li>
        <img src="/images/logo.svg" alt="The logo we created for ourselves: an orange circle with a black dot in the middle of it.">
    </li>
    [...]
  </ul>
</section>

The rule of thumb is simple: the context is king! Always think about what is important in the specified fragment of the page. Is the image communicating the role of some interactive element (e.g. being an icon inside a link or a button)? Is it adding some additional information (e.g. a chart inside an article about the company’s income)?

Defining what exactly you want to convey using the image helps in creating a good alternative text. And if you need some examples, the HTML specification is full of them.

# Labeling your field

All form fields need proper labels. The only exceptions are buttons and hidden fields. Every other field = label. It informs the user what type of information they should type into the field and it is really needed. In some sporadic cases, when labels do not fit your design, just improve your design.

Seriously, do something about it.

And if it is really impossible, then you can always add the label for the users of assistive technology (mainly screen readers), using some CSS sorcery.

# Be responsive to become accessible

Being responsive is not only SEO-friendly but also (and foremost) user-friendly. More and more people use their mobile devices to surf the net, so not having a responsive and accessible website means excluding this ever-growing group of people. This is why responsive web design became a part of Inclusive Design.

Being responsive means making no assumptions about the user’s browser or device. You should adapt to the situation, not the other way around. If something does not work, it is only your own fault. Yes, if the user is viewing your website on their microwave and something is not working, it is your fault. Do you want proof? Just test Google on Lynx!

Of course, sometimes such level of compatibility is not needed, but using good old Progressive Enhancement is actually doable. So if Google works in a text-based web browser, your site can easily work on Apple Watch!

# Do not employ ARIA

The first rule of ARIA usage: do not use it. If something can be achieved using HTML, do it in HTML.

ARIA is really powerful, but with great power comes great responsibility. And in many cases, there is really no need for it. Many patterns used inside web applications can be done using standard HTML elements (buttons or links) — with a little sprinkle of ARIA on top. Overusing ARIA can result in as inaccessible experience as not using ARIA at all.

Having said that, there is that one component on nearly every website that can make use of some ARIA: the hamburger menu toggler (that fancy button with an icon which opens the menu on mobile devices). Adding the [aria-expanded] attribute to it enhances web accessibility by informing the users with assistive technology that the menu has been opened.

# Test!

Last, but not least: test. Do not assume anything, check it. At the most basic level, the tests can be automated using tools like:

Additionally, you can “hear” your website using one of the screen readers, e.g. JAWS, NVDA or VoiceOver. Nothing will replace testing with real people. Testing only by yourself will inevitably lead to making some — even the smallest — assumptions that can distort the whole perspective. Showing the website to the “outsiders” allows for testing the site without any bias and with real users. And trust me: they always find something that you have not thought about before.

Last but not least, remember that your job is not done after you finish your tests and implement improvements. Thinking about website accessibility needs to be incorporated into your content creation workflow, so whenever you are adding a new blog post, article or section, you should examine it, too. A good WYSIWYG editor with a dedicated tool such as Accessibility Checker can alert you about web accessibility issues in real time.

Our Web accessibility testing — DIY! guide with a handy checklist can help you improve your website accessibility in a structured way.

# Web accessibility means more money

These are the most basic rules that can be used to create more inclusive websites. As you can see, they are not that difficult to adhere to and most of them are in fact identical to the best practices present in web development for years. Using even the subset of the recommendations from this article can help you make your website much more accessible.

If you reject the notion that web accessibility is about helping those few people with special needs, you will understand that making your websites accessible to everyone means that your audience, and your business, will significantly grow in a natural way. Your websites will simply work better for everyone, no matter their limitations, network connection, environment or whether they are human or not (waving at you, search engine crawlers!).

Many countries have implemented web accessibility standards that each public sector institution and business must adhere to. Making your digital presence accessible is thus often required by the law and, in recent years, the number of lawsuits filed for violation of accessibility guidelines has been steadily rising. In the US, more than 5,000 lawsuits were filed under the Americans with Disabilities Act in the first half of 2018, many relating to businesses’ online presence. This number is almost tripling from one year to the next and the trend is expected to continue. And as the Beyoncé class-action lawsuit has shown, no industry can afford non-compliance anymore.

So what can you do to avoid problems and, at the same time, benefit from getting access to new potential customers? It is really that simple: make your website accessible to everyone!

If you enjoyed the article, you would be happy to hear that we will be publishing two more articles about web accessibility within the next few days. You can follow us on Twitter to not miss them.

You can read more on the topic of Web Accessibility in our blog posts: