SWE Blog
📰 Posts 🗂️ Categories #️⃣ Tags 💬 About
SWE Blog

Contents

Basic Web Accessibility

A Simple Approach for Accessibility Implementation in Web Development

Vincent Le included in Tutorial Front-end
   1210 words   6 minutes 

Want some music while reading? 🎵📻

Hello everyone!

It has been a long time since the last time I wrote a post. I’ve been really busy with my new job and I haven’t had time to write anything 😅. But today I have some time to write and I promise that I’m not going to let you down with this post.

I’m now working on a project for my current workplace. The project is a fully functional website to manage patients and their health data on a daily basis for doctors and nurses. Since I’m working in the Healthcare Industry, every line of code needs to be written carefully and optimized. Honestly, I’d be a lie to say that I haven’t struggled. The reason is that I have to adapt to the big corporation’s strict coding style. I’m used to code for my personal project with my own relaxed style, therefore, I have to try to learn many new things and adapt to the new ways of doing things.

Thanks to this big and important project, I now have a chance to practice my accessibility knowledge. I realized that there’s a lot of things I still have to learn. So let’s take a look on this topic!

What Is Web Accessibility

W3C has defined Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can:

  • perceive, understand, navigate, and interact with the Web
  • contribute to the Web

Why Do We Need Web Accessibility?

Web developers codes a fully functional website for all kinds of user to use. A website that lacks accessibility is a hindrance for the users with disabilities to use it. To avoid unintentional discrimination and bring the website nearer to all kinds of user out there, web developers should take accessibility into consideration when they start coding a website.

How To Get started

There are many sources out there on this topic, I could give you a couple of good ones:

  • Web Accessibility Initiative (WAI) - This source is very good for the basic ground knowledge
  • ARIA - If you want to make your HTML documents more accessible, this is the source you should take a look into
  • DigitalA11Y Cheat Sheet - This is a fantastic source to have a quick look into the ARIA roles, attributes and states for HTML elements
  • Accessibility Cheat Sheets - A list of different accessibility cheat sheets for common ARIA roles and attributes
Precaution
Web Accessibility is a huge topic and it’s pretty impossible to make it perfect. Therefore, this is only a basic guide and my recommendations for each HTML element. Don’t put your hopes up too much 😁

Document Structure

If you got used to using <div> tag for all of the website blocks, please stop doing this. <div> tag should only be used for generic blocks that make no sense if using any other tags.

HTML5 has implemented many different tags for us to structure the HTML document better and improve web accessibility from the root.

This is the recommended HTML body structure

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

<body>
    <! -- Header outside nav is optional -->
    <header>
        <! -- Our familiar navbar is here -->
        <nav>
            <! -- We should use anchor tag for nav links so that the tabs are keyboard accessible -->
            <a href="#">Nav Link</a>
        </nav>
    </header>

    <! -- This is where we place the main content of the page -->
    <! -- Only 1 main element should be used in a page -->
    <main>
        <! -- Header can be outside or inside main -->
        <header></header>

        <! -- Should be used more frequently than div tag to separate different sections of your website -->
        <section></section>

        <! -- Any block that is independently distributable or reusable should use this tag -->
        <article>
            <! -- Could have header as well -->
            <header></header>

            <! -- together will multiple sections -->
            <section></section>
            <section></section>
        </article>
    </main>

    <! -- For any side section that is not the main content -->
    <aside></aside>

    <! -- The tiny section at the end of the page where you include copyright etc. -->
    <footer></footer>
</body>

Common ARIA Roles and Attributes

Different ARIA roles can be checked here

Different ARIA attributes can be checked here

aria-label

This is one of the most common ARIA attribute used in web development. There are many elements that don’t have native <label> tag to go with them, therefore, we should use aria-label to provide more information for screen-reader. But please notice that this attribute should be used for interactive elements only such as <button>, menu, or dialog, etc. and don’t over use it.

If your input already goes with <label> element, your <iframe> has title, or images have <alt>, you don’t need this attribute.

Here’s a practical example:

1
2
3
4
5
6

<button 
    type="submit"
    aria-label="add new item button"
>
    Add Item
</button>

aria-checked / aria-selected / aria-pressed

These 3 attributes are used with <input type="checkbox">, <input type="radio"> and toggle button. The toggle button is not provided natively in HTML, but if you create a customized toggle button, aria-pressed can be used to indicate its pressed state.

1
2
3
4
5
6

<input 
    type="checkbox" 
    id="vehicle" 
    value="Car" 
    aria-checked="false"
/>

Practical example

Dialog

For example, you want to create a simple dialog that display some information. The code could be like this

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

<div 
    role="dialog" 
    aria-labelledby="dialogTitle" 
    aria-describedby="dialogDesc"
>
    <h2 id="dialogTitle">Simple Dialog</h2>
    <p id="dialogDesc">
        This is a accessibility-friendly dialog
    </p>

    <button aria-label="dialog close button">Close</button>
</div>

Since we don’t have any native HTML element for dialog, we use <div>. Because of this, we add role for this <div> to specify that it’s a dialog. The dialog is labeled by a heading with id dialogTitle so we add aria-labelledby for screen-reader to know that the dialog’s title has a dialogTitle id and it’s the same idea for aria-describedby.

Another example is a navigation bar that has dropdown menus. The following navbar is an example navbar for a bookstore’s website.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<nav aria-label="Main Navigation">
    <ul role="list">
        <li><a href="#">Home</a></li> 
        <li>
            <a href="#" aria-haspopup="true" aria-expanded="false">Categories</a>
            <ul role="menu">
                <li role="menuitem"><a href="#">Fiction</a></li>
                <li role="menuitem"><a href="#">Information Technology</a></li>
            </ul>
        </li>
        <li><a href="#">Contact</a></li>
    </ul>
</nav>

As we could see, the Categories navigation item has a dropdown menu so we should specify aria-haspopup attribute. The state of the menu is closed at the moment so the aria-expanded attribute value is false. The second <ul> element is now a dropdown menu, therefore, its role should be menu. Finally, the <li> elements are the menu’s items so they should have the roles menuitem.

Conclusion

If you read until now, you have seen the basics of accessibility and maybe you could imagine how far we can go with this. If you really want to take accessibility seriously, it would take hours to code a component so don’t overuse this.

Hope you enjoy the post and learn new things after this! Thanks for reading! 🙂

Updated on 08-06-2022
Read Markdown
 tutorial, front-end, accessibility, web-development
Back | Home