HTML Accessibility – Programming with an Inclusive Perspective

The importance of accessibility in web development

Imagine you want to go the beach. Imagine you worked hard all year and you earned it. Upon arrival, you find that the only access point to the beach is a stairway of approximately 20 steps. But the stairway has a problem…actually, it has several problems. Its angle of inclination is very steep, the steps are very narrow and the railings on the sides exceed one meter in height from the ground.

Access to the beach is difficult, isn’t it? Suppose you had no major complications to descend it. With a little effort and care you were able to do it. Now think about how impossible it is for many people to descend the stairway. People in wheelchairs, with crutches, older adults, people with balance problems, children, etc. All those people will never be able to visit that beach, because no one ever bothered to facilitate access.

The same goes for websites

When we create a website, we must consider overall accessibility. Since the nature of a web page is primarily visual, we must ensure our website can be visited and understood by people who are blind or visually impaired. In the year 2020, an estimated 49.1 million blind people were calculated in the world. This is more than the current population of Argentina.

As developers, we have a great responsibility to make websites more accessible to everyone. In this blog post, I will demonstrate some code guidelines to increase accessibility for more people.

How do blind people use the internet?

Unless we are designing and working on a specific project for blind people, we tend to forget about that population. Don’t worry, it’s common for this to happen; we tend to forget to solve problems that don’t personally affect us.

We want to rethink the way we write our code, the first question to ask ourselves as developers is: How do blind people use the internet?

The answer is: they use screen readers.

What are screen-readers?

Screen readers are software applications that read the content of web pages aloud. Visually impaired users rely on screen readers to navigate the web.

Screen readers use a Text-To-Speech (TTS) engine to translate on-screen information into speech, and can be heard through earphones or speakers. They are also capable of providing information in Braille. An external hardware device, known as a refreshable Braille display is needed for this.

Why is HTML code so important for a screen reader?

As you can imagine, blind users must fully trust screen readers to read the content of a website. Whether or not they can enjoy the site is entirely up to the screen readers.

Furthermore, unlike sighted people who generally use the mouse to navigate a web page, blind people use the keyboard for navigation.

How easy it is to access, read and navigate our site content will depend directly on how well our HTML code is structured.

If you want to understand more about how a screen reader works, I invite you to watch the following video:

How do we make our site more accessible?

Below are a few suggestions to consider when thinking about ease and accessibility for screen-readers.

Site reading language

By default, the screen reader uses the language of the operating system to translate the text. If our site is in any specific language we must include it as an attribute in the opening html tag. This attribute will indicate to the screen reader in which language should be carried out despite the operating system’s current one.

				
					<html lang="en">
...
</html>
				
			

This attribute can also be used in other tags to indicate that a certain section should be translated into a language other than the primary one.

				
					<html lang="en">
	<body>
		<h1>Welcome</h1>
		<p lang="es">Este párrafo está en idioma español.</p>
	</body>
</html>
				
			

Semantic HTML is the key

Although HTML is flexible (we can use the <div> tag to structure almost our entire website), not all HTML elements have the same function when it comes to accessibility.

We must use HTML elements that indicate what they are. HTML tags should introduce meaning to the website, not just play a presentation role. This is known as semantic HTML.

When a screen reader scans a site, it gets information about its HTML structure. Elements such as <div> or <span> have no semantic value. However, tags like <header>, <nav>, <main> or <table> are letting the screen reader know what type of content it is dealing with and how that content relates to the rest of the site. This helps the screen reader more accurately understand the structure so it can perform its job more efficiently.

Consider the next example:

  • We want to create a navigation menu for our website.
  • We can write it only with <div> tags (non-semantic :S):
				
					<div>
	<div>Home</div>
	<div>About</div>
	<div>Contact</div>
</div>
				
			

Or we can implement it with semantic HTML (correct way):

				
					<nav>
	<a href="/">Home</a>
	<a href="/about">About</a>
	<a href="/contact">Contact</a>
</nav>
				
			
The difference between semantic and non-semantic tags may not seem important to sighted users, but it matters considerably to blind users for many reasons. In this example, the

HTML Structure

Screen readers scan a website from top to bottom in a linear fashion, visiting HTML elements one by one. This is why it is important to structure content efficiently for the screen reader.

  • Use <header>, <main>,<footer> tags in order to define regions in your code.
  • Correct use of headings tags (<h1>,…, <h6>) to generate a hierarchy in the content. Text size has nothing to do with heading hierarchy. You can jump to the next/previous heading in many screen readers.
  • Use <p> tag to indicate paragraphs.

 

Here is an example of a well structured HTML code:

				
					<header>
	This is the header section   
</header>
<nav>
	This is the navigation menu section
</nav>
<main>
	<h1>This is the main heading</h1>
	<p>First paragraph</p>
	<h2>First subheading</h2>
	<p>First subsection</p>
	<h2>Second subheading</h2>
	<p>Second subsection</p>
</main>
<footer>
	This is the footer section
</footer>
				
			

Always use Alt attribute in images

The alt or alternative text attribute indicates the content of your image. When the screen reader finds alt text, it reads it to the user.

If the image is purely decorative, it is better to implement it as CSS background image or to leave the alt attribute empty. It’s important to not omit the alt attribute or the screen reader will read the image source name.

For blind users, these three examples are not the same:

Example 1:

				
					<img decoding="async" src="image-cat-45623.jpg" />
// acccesible name: image-cat-45623 
				
			

Example 2:

				
					<img decoding="async" src="image-cat-45623.jpg" alt="" />
// decorative image case. it will be ignored by screen readers
				
			

Example 3:

				
					<img decoding="async" src="image-cat-45623.jpg" alt="A stinky cat snoring" />
// accessible name: A stinky cat snoring
				
			

ARIA

ARIA (Accessible Rich Internet Applications) defines a set of attributes that provide screen readers with extra information about viewed HTML elements.

What are ARIA roles?

When semantic HTML is not enough to explain the content of our HTML elements by itself, ARIA role comes into play.

The ARIA Attribute role is used in two scenarios:

  1. To describe elements that conceptually do not exist in HTML.
				
					<ul role="tablist">
	<li role="tab">Tab 1</li>
	</li role="tab">Tab 2</li>
</ul>
				
			

        2. To correct code errors where semantic HTML was not used correctly.

				
					<a role="button">Button</a>
(Likewise, it is better to avoid this type of case 
and always use the correct tag)
				
			

aria-label

aria-label attribute allows the way HTML element is “translated” by the screen reader to be changed. By default, the screen reader will read the text content of an HTML element, but sometimes, the text does not explain its purpose by itself. The string passed in the aria-label attribute becomes the accessible name of this HTML element.

				
					<button>X</button>
// accessible name: x

<button aria-label="Close modal">X</button>
// accessible name: close modal
				
			

aria-label & aria-labelledby

When the text content is visible on screen, you should use aria-labelledby instead of aria-label.
				
					// Wrong way
<section aria-label="Content title">
	<h2>Content title</h2>
</section>


// Right way
<section aria-labelledby="section-title">
	<h2 id="section-title">Content title</h2>
</section>
				
			

Also, you can use aria-labelledby to combine multiple elements into a single accesible name.

				
					<section>
	<h2 id="h2">About us</h2>
	<p>...</p>
	<a href="go.html" id="l1" aria-labelledby="l1 h2">read more</a>
</section>
// accessible name: read more about us
				
			
If an element has both attributes, aria-labelledby value will be prioritized. If you have any doubt about choosing the right ARIA attribute for each case, check the ARIA in HTML official documentation.

Use self-descriptive links

Links are an essential tool within our code when it comes to redirecting the user within the website or directing to an external website.

That is why we must maintain the styles that differentiate it from the rest of the components of a website and prevent it from behaving in an unexpected way using JavaScript.

Another important aspect is the link text. What we write inside the <a> tags should clearly explain where the user will be sent. To a screen-reader, ‘Click here’ means nothing.

But if you find yourself in a case where the text is not self-descriptive, or a more detailed description is needed, the aria-label attribute can be used to easily add a proper name to the element.

				
					<p>
 If you want to know more about the position
	<a href="open-position.html" 
		 aria-label="Description and requirements for the fullstack developer open 
		 position">
		click here
	</a>.
</p>
				
			

Users who cannot use a mouse to scroll through the site can navigate through the links using the tab button. That is why we must assign a logical order to the links, no matter the order the HTML code.

The tabindex attribute takes care of that order for the links.

				
					<ul>
		<li><a href="home.html" tabindex="1">Home</a></li>
    <li><a href="about-us.html" tabindex="3">About us</a></li>
    <li><a href="contact-us.html" tabindex="2">Contact Us</a></li>
</ul>
				
			

Be careful with too many ads

Ads can be a headache for any user. Sighted users can easily ignore them but screen readers can’t. If the banner is crucial for the website, don’t forget the alt attribute in your banner image and add the ‘Ad’ or ‘Advertisement’ word at the beginning of the text value.

If an ad is not necessary to be read by a screen reader, try using aria-hidden=true attribute to hide it from the reader.

Always remember: screen readers treat every content as vital. Avoid showing the screen reader unnecessary content.

Now imagine you are going back to the beach

But this time, the stairs have wide steps, a firm and safe railing, and a correct incline. Now the beach has also a ramp and a wooden platform to the shore for wheelchair access. Everyone can now enjoy the beach thanks to improvements in its accessibility.

The same goes for websites.

People who are blind or visually impaired are not the only ones we need to think about when designing our site. There are also deaf people, those with cognitive, speech or physical disabilities. Modern societies advance with a perspective of inclusion and as web developers we must do our part.

Let’s transform people’s digital experiences!

See related posts