Begin Accessible Websites for Head Start

Nowadays, when making an app, accessibility is often ignored, or some developers think that aria-label is all they need. Some people also think that adding accessibility takes more work or makes the design less appealing, but that's not true.

Having accessibility on websites actually helps SEO, makes our apps easier to use, and simplifies how users interact with the app.

Building an app with accessibility in mind isn't hard. There are guidelines to follow that show us what to do. Accessibility starts with the most basic parts.

Starting with WCAG & Section508

My first question was also: How do I start with accessibility? How can I make sure I follow accessibility guidelines? You might have seen terms like WCAG 2.0, WCAG AA, or Section 508 on different websites or libraries, but what do they mean?

Each one is a set of guidelines to make your website accessible. Both 508 and WCAG (Web Content Accessibility Guidelines) help us make our product or website accessible to people with disabilities.

So, we have 508 and WCAG, but which one should I use?

Accessibility Guidelines

I first wondered why there are two guidelines when learning about Accessibility. The one you choose depends on your target audience. For example:

If your app is for the US government, you need to follow Section 508. This guideline sets the rules for websites used by the government and its agencies.

Read more about Section 508

If your app isn't for the US government, WCAG is suitable. But do you recall WCAG AA, A, or AAA?

WCAG, or Web Content Accessibility Guidelines, is part of the W3C and follows the global guidelines for accessibility.

In my case, I'll use WCAG 2.1, which has 13 guidelines and four principles:

Perceivable: Every user can perceive the information presented. The content must be available to any user, seen, and read, like images with captions.
Operable: Allow the user to interact with any element with a mouse, keyboard, or touch.
Understandable: The content must be easy to follow, clear, and predictable.
Robust: Access the content using technologies.

As I mentioned, there are levels A, AA, AAA. But what do they mean?

A: Basic accessibility features.
AA: Common accessibility features and barriers.
AAA: High level of accessibility.

Tip: To make my product suitable for the US government and all users, using WCAG 2.1 AA covers everything in Section 508.

Great, we've chosen WCAG. What's next?

Simple Accessibility Guide

You might think you need to add some aria-labels or roles to every element, but accessibility begins with basic markup.

By using HTML properties, we can create an accessible website. HTML is semantic, meaning we can enhance accessibility just by improving the markup correctly.

Let's get started!

Page Structure

Create an empty HTML file, add a valid doc type, and set the language using the lang attribute. This helps browsers and assistive technologies read the markup and code, making it easier for screen readers.

Set charset to UTF-8 and ensure compatibility for IE.
Include a unique title, which benefits both users and SEO 😎.
Adjust text size.
Use relative CSS units: rem or em.

<!doctype html>
<html lang="es">
   <meta charset="utf-8">
   <meta http-equiv="x-ua-compatible" content="ie=edge">
   <title>Market Store</title>
</html>

Ensure there are no duplicate ID's. Elements' attributes and tags should be closed properly.

But what about the body?

Can you recall the <header>, <nav>, <main>, <footer>, and <aside> elements?

Use only one of each per page.
This helps to keep a relationship between them.
Include only a single main element per page.
We can have multiple nav elements, but use aria-label to give context to the user.
Be mindful of content structure using h1, h2, h3, and so on. Please keep the relationship between them.
Use only a single h1 per page.
Instead of using <strong> or <b> to emphasize an area, use the h1, h2, h3 order.

<header>
    <nav>
        <a href="home">Home</a>
        <a href="about">About</a>
    </nav>
</header>
<main>
    <h1>Welcome to the store</h1>
    <p>We have a lot of products!</p>
    <h2>Electronics</h2>
    <!-- More content here -->
</main>
<aside>
    <p>Products</p>
    <nav aria-label="products">
        <a href="fruits">Fruits</a>
        <a href="phones">Phones</a>
    </nav>
</aside>
<footer>
    <nav aria-label="footer links">
        <a href="home">Home</a>
        <a href="about">About</a>
    </nav>
</footer>

What About List Elements?

When displaying a list of elements, HTML offers several options:

Ordered list: <ol> for items in a specific order.
Unordered list: <ul> for items without a particular order.
Description list: <dl> for items with description.

Learn more about HTML Lists

Screen readers handle these lists effectively, using the information to provide better context for each item.

Navigation is crucial for usability. Ensure consistent navigation, as well as consistent identification and link purpose.

<nav>
    <ul>
        <li><a href="home">Home</a></li>
        <li>
            <a href="offers">Offers
                <span class="k-sr-only">Products with Discounts</span>
            </a>
        </li>
        <li>
            <a href="about">About
                <span class="k-sr-only">About SuperMarket</span>
            </a>
        </li>
    </ul>
</nav>

Alternatively, create a sitemap using <ol> or <ul>. Make sure to include additional information for links without altering the layout.

To add extra information without changing your design, you can use the class .k-sr-only provided by Kendo UI.

Kendo UI Accessibility for Screen Readers

Tables

Tables are a commonly used element in our apps to display information in a structured format, with rows, columns, and cells. They can contain text, images, links, or buttons.

Always use <thead>, <tfoot>, and <tbody>. But what about <caption>, <th>, <scope> (col, row, colgroup), and <colgroup>?

Example:

<table>
   <caption>Title of Table</caption>
   <thead>
      <tr>
         <th scope="col">First Column Name</th>
         <th scope="col">Second Column Name</th>
         <th scope="col">Third Column Name</th>
      </tr>
   </thead>
   <tbody>
      <tr>
         <td>Data 1 in row 1</td>
         <td>Data 2 in row 1</td>
         <td>Data 3 in row 1</td>
      </tr>
      <tr>
         <td>Data 1 in row 2</td>
         <td>Data 2 in row 2</td>
         <td>Data 3 in row 2</td>
      </tr>
   </tbody>
</table>

Caption: This is like a title for the table, helping people understand its purpose.
Headers: The top row (inside <thead>) contains names for each column, acting as titles.
Rows and Cells: The main part of the table (inside <tbody>) consists of rows (<tr>) and cells (<td>), with each cell containing data related to its column.
Scope: The term 'scope' in <th> indicates whether the header is for a column or a row.

Ensure the table can be understood when read from top to bottom and left to right, as this is how screen reader users will perceive it.

Forms

Forms are often the main way users interact with web applications. To make them accessible, we need to ensure everyone can enter data, choose options, and submit information easily, regardless of their abilities. This includes thinking about screen readers, keyboard navigation, and clear visibility.

Make sure placeholders have good contrast.
Label inputs correctly. Connect labels to their input fields, so screen reader users know what each field is for.
Provide name, role, and value.
Avoid keyboard traps. If using shortcuts, allow remapping or disabling.
Show error validations in text; use novalidate for forms.
When an input or interactive element is focused, make it visually distinct to help users with limited focus or attention.

For example, Inputs:

<form id="subscribe">
    <label for="name">
        Name
        </label>
        <input id="name" required>
    </form>

However, when using a radio button, always utilize a fieldset.

<fieldset>
<legend>Get emails</legend>
<label>
   <input type="radio" name="yes" value="yes">Yes
    </label>
    <label>
   <input type="radio" name="no" value="no">No
    </label>
</fieldset>

The final example:

<form id="subscribe">
        <label for="name">
          Name
          <input id="name" required />
        </label>

        <label for="lastName">
          LastName
          <input id="lastName" required />
        </label>

        <fieldset>
          <legend>Get emails</legend>
          <label> <input type="radio" name="yes" value="yes" />Yes </label>
          <label> <input type="radio" name="no" value="no" />No </label>
        </fieldset>
        <button type="submit" role="button">Send</button>
      </form>

Recap

The world of accessibility is a vast adventure. I'm learning a lot, but embracing web accessibility is a journey that enhances your website, your knowledge, and positively contributes to a more inclusive digital world.

Danywalls | Angular | Kendo | Typescript

Danywalls | Angular | Kendo | Typescript

Web Accessibility: Head Start

How head start to build accessible websites

Table of contents