The term du jour is web accessibility—in my opinion, one of the most frequently misunderstood and poorly applied aspects of web design. The common misconception is that accessibility is designed solely for disabled people. In fact, everyone benefits from accessible content, and your audience will increase by gaining access to accessible content on different platforms or in different ways, because they can use your content with fewer constraints.

Unfortunately, a lot of web developers do not make their content accessible and do not follow web accessibility guidelines; thus, many people experience unnecessary difficulties using their designs and enjoying content. In extreme cases, certain groups of users can’t use such a website effectively at all.

Building accessible content should be second nature to any developer, designer, or content creator, the same way the consideration of ramps, stairways, and lifts is to an architect designing a new building.

Let’s take a closer look at what’s behind the scenes and why so many developers seem to overlook web accessibility standards for no good reason.

1. What Does “Accessible Design” Mean?

Accessible content is content everyone can use. We don’t know all the aspects of how the users are accessing our content, so we need to design with accessibility in mind ahead of time.

As I highlighted earlier, this does not concern people with disabilities, accounting for about about 15% of the world’s population. In real life, users often end up not consuming content and interacting with devices in the exact same way as envisioned during development. Accessible content is also required for legal reasons in many jurisdictions. Read “Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization” for additional information on accessibility compliance.

Consider the following scenarios while thinking about accessible content for users that may be:

  • Unable to hear well. 360 million people worldwide have hearing disabilities. Audio content should have transcriptions and video should have captions.

  • Unable to see well. 285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 have low vision. Users that are visually impaired they use screen readers (that read the content using synthesized speech), refreshable braille displays (screen content appears on the braille display, and the user can navigate and interact with their device using the keys on the display) or high-contrast mode.

  • Affected by dyslexia. People with dyslexia find difficulty in reading and understanding content, especially, e.g., justified text or all caps.

  • Suffering from physical limitations. Not all people can use all devices. For example, navigation through the content must be available not only for mouse users, but also for users that can’t use a mouse.

  • Using mobile devices. Adapt your content for small screens. Allow the user to zoom or increase the font size.

2. How to Ensure Good Web Accessibility

People use very different ways of navigating and consuming content. There are users that need to be supported by additional software tools that helps them access content easier. These tools, known as assistive technologies, range from screen readers to touchscreens and head pointers.

However, your application and assistive technology need to talk to each other. Not everything that is written in HTML is fully understandable for assistive technologies. In order to help “translate” content from “technical language” to more human readable language, additional accessibility API standards have been created.

This basic web accessibility diagram should give you a better idea of how assistive technologies work.

Source: W3C
Source: W3C

To illustrate how it works, let’s look at a simple code example:

<a href="#” class=”button”>Delete</a>

This simple code, for people who use the screen reader, doesn’t mean much. It’s even misleading and reads only as a link with the text “Delete”. In order to help users to understand what kind of method is used to perform the action, we can use ARIA (Assistive Rich Internet Applications) attributes (specified at to override the original role. We change the meaning of a link to a button by adding attribute role="button". In that way, screen readers will read it as a button, not a link. Which is more appropriate.

In short, attribute ARIA:

  • Gives or enhances semantics of non-semantic or other-semantic elements,

  • Ensures that dynamic (live) content is still accessible.

  • Provides the role to describe the type of defined widget (menu, tree item, slider, progress meter, etc.).

  • Provides the role to describe the structure of the web page (headings, regions, and tables).

  • Provides the state of the widgets (checked, has popup, etc.).

  • Provides properties for drag-and-drop that describe drag sources and drop targets.

What Is Accessibility in Web Design?

Whenever you design a content think about two things: how the content is perceivable and how it is operable. Let’s examine some examples to illustrate accessibility in web design.

Let’s say you are going to design a custom select dropdown element. Here are the things to consider while designing the element:

  • Mark different states: enabled, disabled, read-only.

  • Mark the element when it gets the focus/hover state.

  • Mark every option element when it gets focus/hover state.

  • Make sure the content is still readable when only the text is zoomed up to 200% level.

  • Make sure that there is enough contrast between the text and its background. It helps people with moderately low vision or on devices in extreme lighting conditions, e.g., exposed to direct sunlight or on a display with low brightness, to read the content.

Another example could be selecting a color to describe a state. Here are the things to consider while designing a section where the user will be able to pick up a color:

  • There are people that have difficulty distinguishing certain colors. So green doesn’t mean green for all your visitors. To fix it, add a description for every color that describes the purpose.

  • Mark each element when it gets the focus/hover state.

  • Make sure there is enough space between elements so that every element can be easily activated, e.g., on devices with a smaller viewport.

3. Accessibility Testing: Where to Begin?

There is no one way to check and be sure that web content is fully accessible. Multiple techniques need to be used in order to verify and fix the accessibility issues. You may start by defining issues, solutions, and priorities.

Defining issues

While working on accessibility issues, always try to create one ticket per problem with a clear title. This should simplify understanding the issue and help to define a priority.

Bad example: The user can’t use the keyboard on the page.

Good example: Unable to use keyboard navigation in the main menu.

The bad example leads to a case that will be quite difficult to close in a short time. Discussions on multiple topics might start in the comments section as well, as the ticket title is too generic.

The good example points exactly to the problem and focuses only on one thing: keyboard navigation in the main menu.

Prioritize Web Accessibility Issues

Priorities are important because they define which problems must be fixed first. For example, WCAG is divided by three conformance levels: A, AA, AAA, which means you should start from a minimum level A, but that doesn’t automatically mean that AA and AAA levels are merely “nice to have.” All of the levels are important, and it’s important not to prioritize assuming that level A alone is sufficient.

However, WCAG levels (or any other guidelines) might be quite difficult to understand sometimes and in order to simplify it a bit, you may also consider the following priority definitions:

  • Critical – Issues that prevent users from using an application. No workarounds available.

  • Major – Issues that make using an application difficult and/or disorienting, but don’t block a user’s ability to complete the operation.

  • Minor – Issues that are annoying but do not hamper use, or enhancements that could be made to the application.

  • Info – Does not adhere to best practices. General recommendations for improvements.


None of the guidelines—by which I mean WCAG, Section 508 or ADA—will give you a straight solution in terms of technical code for how a specified problem should be fixed. They only define expected behavior. However, WCAG additionally has defined test procedures that should help to understand how to reproduce the issue and there is an Automated WCAG Monitoring community group, a W3C community with a focus on developing reliable rules for web accessibility testing, both automated and semi-automated.

An example for WCAG technique G4 (“Allowing the content to be paused and restarted from where it was paused”):

Test Procedure

On a page with moving or scrolling content,

  1. Use the mechanism provided in the web page or by the user agent to pause the moving or scrolling content.

  2. Check that the moving or scrolling has stopped and does not restart by itself.
  3. Use the mechanism provided to restart the moving content.
  4. Check that the movement or scrolling has resumed from the point where it was stopped.

Expected Results

No. 2 and No. 4 are true.

As we can see there are no technical solutions, but defined expected behavior. How web developers implement it is up to them.

Web Accessibility Guidelines and W3C Standards

Following basic web standards should be your starting point:

Web Accessibility Testing: How do I know if my content is accessible or not?

Here are basic, fundamental checkpoints that should help you make your web content more accessible from step one:

  • Validate your HTML. Make sure that the HTML structure has no errors, as the assistive technologies can have problems interpreting the page content.

  • Test with a keyboard alone. Make sure that all actionable elements are accessible using only keyboard. Also, you have to be able to perform all actions using a keyboard as well, e.g., submitting a form.

  • Test with accessibility testing tools and validators. Use tools that scan and verify potential accessibility errors.

  • Dynamic content. Notify screen reader users about dynamic changes, e.g. when the search results have changed.

  • Do not rely on colors to describe the meaning. Use color along with description, e.g., [yellow box] warning.

  • Do not remove the outline on focus. This is a commonly removed feature using the CSS property outline: 0; Do not do that, as the keyboard users will lose the orientation on the page. You may consider removing the focus outline for non-keyboard users, but always provide a focus outline for keyboard users.

  • Error messages. Always tell the user how to correct an error. Don’t just state that the data is invalid.

  • Tab order. Ensure that tab-based navigation follows the conventions established in the graphical user interface. At a minimum, it should follow the reading direction of the application’s default language. In English, for example, reading order is top to bottom, left to right; in Arabic it is top to bottom, right to left.

  • Zoom. Make sure the page content is still readable while zooming text up to 200%.

  • Turn off images. Are you still able to use the page in a comfortable way? Are there alternative texts for all images?

  • Screen reader. Test to see if you can read and navigate through the content using at least one screen reader, e.g., VoiceOver, Windows Narrator, or NVDA.

  • High contrast mode. Check to see if the content is still readable while switching to high-contrast mode.

  • Font size. Make sure the font size on the page has size no less than 10px.

4. Common Mistakes in Web Accessibility

The most common mistake is failing to identify accessibility requirements prior to development. Unfortunately, the later accessibility will be a part of development, the harder it will be to implement solutions.

Here is a list with some of the most common mistakes developers make while implementing accessibility:

  • No ability to navigate through the content using only a keyboard.

  • Misusing the CSS outline property. In most cases, outline: 0; is used, which means that the outline around each actionable element is not visible anymore. Do not use outline: 0; or outline: 0 !important;. The user will lose the ability to see the currently focused element while navigating through the content, unless there is any other alternative to that, e.g., using the border CSS property.

  • Losing focus from the current element, e.g., due to DOM manipulations or using the blur() method. This often happens for single-page applications.

  • No notifications for the screen reader users that something has changed, e.g., content has been downloaded using XMLHttpRequest API and new changes on the UI have been rendered, but the user hasn’t been notified. This often happens with single-page applications.

  • Inaccessible date picker. In many cases, inaccessible date pickers are used. Users aren’t able to navigate through the calendar options using keyboard.

  • Using extensions that claim to automatically fix accessibility issues. Use them carefully and check the results. Misusing them can create more problems than solutions.

  • Adding to the element tabindex attribute with an index number of more than 0. The purpose of using tabindex with an index of more than 0 is mostly to “correct” the navigation path. However, consider rather changing the HTML structure in order to get the natural path of navigation. Manipulating it using tabindex can lead to maintenance troubles and an unpredictable navigation path.

  • Wrong heading hierarchy. Unfortunately, it’s still quite often seen, but the header hierarchy is not properly built, e.g., <h1>, <h5>, and <h2>. The screen reader users are using headers to navigate through the sections and improper structure is confusing as it’s hard to understand the context.

  • Missing high-contrast support. There are people who are using their software in high contrast mode. Make sure your content is still perceivable.

  • Using an inaccessible CAPTCHA solution. Unfortunately, all CAPTCHAs known to me are either inaccessible or very hard to use.

  • Too many and/or non-pausable animations. Autoplaying videos, advertisements, or image carousels are very distracting.

  • Large chunks of text. Text that is condensed in a very large, single block, without spaces, commas, or dots. Very hard to read. Splitting into smaller chunks, more paragraphs, and subheadings helps better organize the text content.

  • Zooming problems. Make sure the content is still readable and navigable when zoomed up to 200%.

  • Relying on colors. Very often the state of an element is marked only by a color, e.g., a warning state is marked only by a yellow bullet; this color is not perceived in the same way for colorblind people.

  • Small clickable/tappable targets. The clickable/tappable areas are often too small. Making it bigger allow users to activate them more easily.

But How Do I Improve Web Accessibility?

Defining the issues is one thing. Fixing it is quite another and very often not that easy as it looks. That’s because accessibility API implementations are not consistent and sometimes we need to find workarounds or even accept the fact that something will not work at all when we are trying to fix the problem.

In terms of tools, there is no single tool that can check all the possible combinations, but as a good start, these tools should help:

Always keep in mind that no accessibility tool can replace manual testing, as not all scenarios can be fully or at all automated, e.g., checking luminance contrast ratio on elements with position: fixed;.

Focus on issues that block usage of your application, e.g., the user is unable to navigate through the menu using keyboard.

Why It’s Important to Make Content Accessible

Everyone wants to spread their content as widely as possible. Accessibility helps in that area, on many levels, from reaching a bigger audience to improving the user experience for all users. Moreover, accessibility isn’t just for what you might traditionally think of as people with disabilities. Whether it is an individual who is aging and going through the accompanying physical changes, someone jogging on a sunny day who needs automatic contrast adjustment on their phone, or a parent with hands full of shopping bags wanting to send a text message by voice, accessible technology is technology all users may use from time to time.

As an added bonus, the positive effect is that accessible content that fully meets WCAG 2.0 standards is easier to crawl and understand by search engines, and that can have a significant effect on how a site ranks. Thus, accessible design can drive additional traffic to the website.

Finally, here are some statistics you need to consider:

  • More than one billion people worldwide experience some type of disability.

  • Aging of the population. Between 2015 and 2030, the number of older persons — those aged 60 years or over — in the world is projected to grow by 56 per cent, from 901 million to more than 1.4 billion.

  • Universal design is key. Universal design refers to a broad spectrum of ideas and practices for producing services, products, and environments that are inherently accessible and usable by people of all abilities.

  • Types of disabilities: There are five broad categories of disabilities, including visual, mobility, speech, cognition, and hearing.

We all require high-quality services. Let’s deliver them, too.

Understanding the Basics

What is accessibility in web design?

Web accessibility is the practice of removing various obstacles to access and user interaction with online content. Its purpose is to ensure web access to people with disabilities, as well as all other users that may need to access content unconventionally.

About the author

Cezary Tomczyk, Czech Republic
member since October 27, 2015
Cezary has over ten years of experience in web technologies, and he is passionate about managing projects and people. He has experience in the complete product life-cycle from beginning to the end. He is experienced in hand coding, using the Semantic Web, writing usable code that is cross-browser compliant and upholds to the web content accessibility guidelines from W3C. He specializes in search engine and performance optimization solutions. [click to continue...]
Hiring? Meet the Top 10 Freelance Front-End Developers for Hire in September 2017


comments powered by Disqus
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Relevant Technologies
About the author
Cezary Tomczyk
JavaScript Developer
Cezary has over ten years of experience in web technologies, and he is passionate about managing projects and people. He has experience in the complete product life-cycle from beginning to the end. He is experienced in hand coding, using the Semantic Web, writing usable code that is cross-browser compliant and upholds to the web content accessibility guidelines from W3C. He specializes in search engine and performance optimization solutions.