DEV Community

Cover image for Things You Need to Know About Web Accessibility
Maestro Trastanechora
Maestro Trastanechora

Posted on • Updated on

Things You Need to Know About Web Accessibility

Every website owner wants to attract as many visitors as possible. However, few take the steps necessary to ensure their site can be used by everyone. There are millions of users out there who rely on sites being accessible, and if you don’t take the time to understand their needs, everyone will be missing out.

The fact is that millions of internet users have special needs, disabilities, and impairments that can make it difficult or even impossible for them to use certain types of websites. By designing your site with these challenges in mind, you can ensure that it’s welcoming to as many users as possible.

While there are a lot of disabilities and conditions that can affect the way people use websites, let’s take a look at some of the most common categories of impairments:

  • Visual Impairment: This includes a partial or total inability to see or to perceive color contrasts.
  • Hearing Impairment: Some users have a reduced ability to hear.
  • Motor Skills/Physical Disabilities: Users may have difficulty moving parts of their bodies, including making precise movements (such as when using a mouse).
  • Photosensitive Seizures: Conditions such as epilepsy can cause seizures that are often triggered by flashing lights.
  • Cognitive Disabilities: There are also many conditions that affect cognitive ability, such as dementia and dyslexia.

To work around these issues, many people use assistive technologies to browse the internet. This includes screen readers that vocalize the text on each page, speech recognition software that converts speech into text, Braille terminals, and even alternative keyboards that accommodate special needs.


A Brief Introduction to Web Accessibility

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

Thus the impact of disability is radically changed on the Web because the Web removes barriers to communication and interaction that many people face in the physical world. However, when websites, applications, technologies, or tools are badly designed, they can create barriers that exclude people from using the Web.

The Web is an increasingly important resource in many aspects of life: education, employment, government, commerce, health care, recreation, and more.

Web Accessibility From Developer's Perspective

Accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services.

Web Accessibility From User's Perspective

Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.


Understanding the Four Principles of Accessibility

The guidelines and Success Criteria are organized around the following four principles, which lay the foundation necessary for anyone to access and use Web content. Anyone who wants to use the Web must have content that is:

  1. Perceivable - Information and user interface components must be presentable to users in ways they can perceive.
    • This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)
  2. Operable - User interface components and navigation must be operable.
    • This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)
  3. Understandable - Information and the operation of user interface must be understandable.
    • This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)
  4. Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
    • This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)

How to Meet Accessibility Standards

The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) develops web accessibility standards for the Web Content Accessibility Guidelines (WCAG), these guidelines overview addresses web content, and is used by developers, authoring tools, and accessibility evaluation tools.

The accessibility guidelines are based on the fundamental technical specifications of the web, and are developed in coordination with all W3C technical specifications (HTML, CSS, SVG, SMIL, etc.). W3C also develops technical specifications that directly address accessibility, including:

ARIA, the Accessible Rich Internet Applications Suite, which defines a way to make web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.


Where Should I Start

For many, the first step along the accessibility road is conducting an accessibility audit.

This is a manual review of a website against the latest WCAG 2.1 guidelines. This will identify where your website does and does not comply and give you an action plan of how to fix the issues.

This checklist uses The WCAG as a reference point. The WCAG is a shared standard for web content accessibility for individuals, organizations, and governments.

The issues this checklist prompts you to check for covers a wide range of disability conditions. There is no such thing as “perfect accessibility” or a site being “100% accessible.”

Once changes have been made, your website should be re-audited to check all the issues have been rectified.

You can also do the automated check with Lighthouse audit for accessibility from Chrome dev tools or web.dev if the site is already deployed.


Create Content With Accessibility in Mind

While designing your site for accessibility is hugely important, you should bear the same considerations in mind when creating content.

This means paying attention to relatively minor things, such as always fully writing out acronyms, to more important points, like making sure you give all your links unique, descriptive names and anchor text.

Look at a few ways you can make your website more accessible right away:

1. Make Sure Your Site Is Keyboard-Friendly

for a website to be accessible, it must work without the use of a mouse. This is because many assistive technologies rely on keyboard-only navigation. As such, it must be possible to use all of your site’s major features via a keyboard and nothing else. This includes accessing all pages, links, content, and so on.

A keyboard user typically uses the Tab key to navigate through interactive elements on a web page—links, buttons, fields for inputting text, etc. When an item is tabbed to, it has keyboard "focus" and can be activated or manipulated with the keyboard. A sighted keyboard user must be provided with a visual indicator of the element that currently has keyboard focus. Focus indicators are provided automatically by web browsers. While their appearance varies based on the browser, the focus indicator is typically shown as a border or highlight (called an outline) around the focused element.

More about Keyboard-Friendly please learn here.

2. Make Sure All Content Is Easily Accessible

In addition to making your site keyboard-friendly, you also need to ensure that all content on the page is actually accessible. While this is usually not a problem, it can be an issue when a page contains dynamic content.

In short, content is dynamic if it can change without the page it’s on reloading. This can become a problem if the site doesn’t inform assistive tools of the change. For example, many screen readers will only “read” the site as it appears when it first loads. As such, you need to make it aware when something shifts, or the user will miss the new content.

One way you can do this is by using ARIA landmarks. These are tags you add to content in order to clearly define it on the page. You can tag dynamic content as a “live region,” which enables screen readers and similar devices to understand the content as it changes.

ARIA is also useful for making navigation more straightforward as it lets users skip directly to specific content. This way, they won’t have to tab through every menu item just to get to your main content and can easily pass over other link-heavy sections. The same effect can be achieved using skip-to-main links, which are invisible links that let users skip menus. However, ARIA tends to be more flexible and efficient.

  • banner = contains the site-oriented content of each page, like the logo, usually located at the top of the page. There should only be one banner landmark per page.
  • complementary = a section of content that complements the main content but also retains its meaning when separated from the main content
  • contentinfo = contains content usually found in the footer of a page, like copyright and privacy statements. There should only be one contentinfo landmark per page.
  • form = contains form input elements which can be edited and submitted by the user
  • main = the main content of the page. There should only be one main landmark per page.
  • navigation = a collection of navigation links to navigate the site or page
  • search = a search tool
  • application = represents a unique software unit, and keyboard commands are handled by the application rather than the browser itself. This role should be used sparingly.

For Example:

<div id="nav" role="navigation">
  <ul>
    <li>Home</li>
    <li>Products</li>
    <li>Support</li>
  </ul>
</div>
Enter fullscreen mode Exit fullscreen mode

In this case the screen reader user will hear something like “navigation landmark.”

You should not place the “role” attribute on another element that already has semantic meaning, like a <ul>. It should only be placed on <div> and <span> elements.

More about ARIA please learn here.

3. Add Alt Text to All Images

This text acts as a replacement for the image if it fails to load.

Alt Text

example photo with alt text "photo of a green plant"
However, alt text (sometimes called alt attributes, alt descriptions, or alt tags) is also accessed by screen readers to “read” the picture. You can, therefore, use this field to describe an image, giving context to users who would otherwise miss it.

As if that weren’t enough, alt text can also help you improve your site’s SEO, giving search engines more information to crawl. Just make sure to write descriptive summaries of each image, and try to include your keywords whenever it makes sense.

More about Alt Text please learn here.

4. Choose Your Colors Carefully

We often talk about color blindness as if it’s a, no pun intended, black-and-white issue. However, it’s more of a spectrum since different people perceive colors in unique ways. As such, you need to make sure the colors you select on your site contrast well to ensure that everyone can distinguish between various elements on the page.

The most pressing issue is making sure text stands out against the background. Ideally, you should set a dark color against a light one, making sure that they don’t bleed into each other.

Let’s say you want to use a blue color scheme. You’d want to avoid creating a palette where the shades are too similar in hue and saturation, like this:

Alt Text

This is very difficult to read. Instead, a clearer color contrast works much better.

Alt Text

There are plenty of online tools you can use to find and test color combinations. You can try this one.

5. Use Headers to Structure Your Content Correctly

Another key task to make your site accessible is structuring your content by using headers carefully. Doing this will make your content much easier to understand and digest and improves flow.

Additionally, clear headers also help screen readers interpret your pages. This makes it much easier to provide in-page navigation. It’s also simple to do as you only need to ensure you use the correct heading levels in your content.

For instance, you should only use one H1 per page – usually as the page title. This can be followed by subheadings starting with H2, which can then be nested further with H3, followed by H4. These should always be used in order so you should avoid using an H4 directly after an H2 (and so on).

More about headers please learn here.

6. Design Your Forms for Accessibility

Forms are a useful addition to most sites but must be designed carefully. What’s most important is to ensure that each field is clearly labeled. You should also aim to place the labels adjacent to the respective fields. While a sighted user can easily match a label to the corresponding field or option, this may not be obvious for someone using a screen reader.

You should also aim to provide instructions and information in a clear way that the user can easily understand. To create accessible forms in WordPress, you can use a tool like the Caldera Forms builder. This is a plugin specifically focused on accessibility, which will make your job much easier.

More about headers please learn here.

Wrapping It Up

Making sure your site is welcoming to as many people as possible should be a top priority. There’s no reason to exclude anybody, especially since it’s relatively easy to avoid doing so. Not only will your users thank you, but you’ll also likely see benefits in the form of increased traffic and conversions.

Top comments (1)

Collapse
 
grahamthedev profile image
GrahamTheDev • Edited

Great article, have a ❤🦄!

A few suggestions to improve (I know this looks like a lot but they are only minor points I promise!):-

Section 2

WAI-ARIA is a last resort when you can't achieve the same with semantic HTML.,

As such your example shouldn't have any aria - it isn't a great example as your HTML should instead be:

<nav id="nav">
  <ul>
    <li>Home</li>
    <li>Products</li>
    <li>Support</li>
  </ul>
</nav>
Enter fullscreen mode Exit fullscreen mode

No need for WAI-ARIA there!

Also:

  • banner....use <header> instead
  • complementary...use <aside> instead
  • contentinfo...use <footer> instead
  • form...use <form> instead
  • main...use <main> instead
  • navigation...use <nav> instead
  • search....use this one!
  • application...you described this perfectly...basically never use this unless you are willing to completely rewrite all of the functionality of HTML! Sparingly is an understatement! 😋

There are loads of things to add such as labelling sections using headings and aria-labelledby being the best practice (perhaps a good example to use instead of the one above?) etc. but given the length of this comment I will leave that for you 🤣🤣.

example of how to label sections

<main aria-labelledby="main-heading">
   <h1 id="main-heading">Welcome to yyyyy site</h1>
</main>
Enter fullscreen mode Exit fullscreen mode

screen reader behaviour

Also you say that screen readers will only read content that is added to the page when it loads - this isn't true for 95% of screen reader / browser combinations just so you know.

And for screen readers that do not see newly added content WAI-ARIA will not help fix that (unless you are suggesting adding it to a aria-live region....which would be a terrible idea as you probably know!).

For AJAX loaded content triggered by a button / link click (i.e. in a SPA) you would use focus management to take users to newly added content as one way to aid discovery. Yet again a lot to cover on this but basically don't be scared of lazy loading info etc. most screen readers will handle this no problem.

Finally with regards to

"You should not place the “role” attribute on another element that already has semantic meaning,"

Your example is not great as adding role="menu" and role="menuitem" should go on ul and li 😋

A better example is:

<footer role="contentinfo"></footer>
Enter fullscreen mode Exit fullscreen mode

But even then there is nothing wrong with it as such and it is essential if you are supporting IE8 or less (I mean even I don't go to that extreme but you might have to one day!) or any other browser that doesn't support HTML 5.

Section 3

When adding alt attributes - your shouldn't really say "a photo of...." - it is unnecessary information. The only time when it becomes relevant is if it is an illustration, cartoon, graphic etc.

Other minor bits

Section 6 - minor mistake - the text reads "More about headers please learn here." - link is correct just the wording is wrong as that is the forms section.

Links - The golden rule of accessibility with links is not to use "here" as the link text.

Links should make sense on their own due to how some screen reader users navigate via links when trying to familiarise themselves with a page.

This applies to all of your sections.

For example in section 2 instead of

"More about ARIA please learn here"

it would be better to do

"Learn more about ARIA here"

as it makes sense on its own.

Anyway like I said minor points but important nevertheless, I hope you find the info useful and any questions just ask!