Understanding Accessibility in Web Development

Imagine a web where everyone, regardless of ability, navigates effortlessly. Yet, 96.5% of websites fall short. With a few simple changes, you can help fix that. Let’s dive into the essentials of accessible development.

What is accessible development?

Accessible development ensures web content is usable by everyone, including people with disabilities, by making it easy to navigate, understand, and interact with using assistive technologies.

These are some technologies that benefit from accessible web content:

ATs - Assistive technologies:

• screen readers
• Speech recognition software
• Screen Magnifiers
• Alternative input devices

At the heart of web accessibility is the accessibility tree. This is a simplified representation of the page that contains elements like headings, links, and form labels. The HTML tree object is returned by browsers and used by assistive technologies.

In Chrome, go to inspect element and click on the accessibility icon at the top right corner of the elements section to see the accessibility tree.

Accessibility Testing

Accessibility testing ensures websites are usable for everyone by identifying issues through tools like screen readers, contrast checkers, and automated audits.

Tools:

• Using AT
• Contrast checkers
• Automated tools (Lighthouse, Accessibility inspector, aXe)
• AI assistants

You can use Chrome's Lighthouse tool to analyze your page and get a report on Performance, Best Practices, SEO, and Accessibility.

In Google Chrome, open DevTools, navigate to the Lighthouse section, select "Accessibility" under categories, and click "Analyze page load." You'll receive a report with an accessibility score and suggestions for improvement.

Accessibility guidelines

The Web Content Accessibility Guidelines (WCAG) are the global standards for making web content more accessible to people with disabilities. WCAG is organized into three levels of conformance:

• A (Minimum Level): Basic web accessibility features that are essential for some users but may still present barriers to others.
• AA (Mid Level): A more extensive set of requirements that addresses common barriers, ensuring a broader range of users can access the content.
• AAA (Highest Level): The most inclusive standard, which ensures maximum accessibility but is often difficult to achieve across an entire site.

Adhering to these guidelines helps ensure your web content is perceivable, operable, understandable, and robust for all users.

Text contrasts

Text contrasts refer to the color differences between text and its background, which are essential for readability and must meet specific minimum ratios according to WCAG standards to ensure accessibility for all users.

These are WCAG text contrast minimum requirements to have accessible web content.

By pressing Command + Shift + C on google chrome browser, you can inspect a text element, and under the Accessibility section, it will display the contrast ratio.

If you open Firefox DevTools and go to the Accessibility section, you will find the color and contrast ratio under the Checks tab.

contrast checker: https://webaim.org/resources/contrastchecker/

Alternative text

Provide clear and descriptive alt tags for images to ensure that users with visual impairments can understand the content and context of the visuals.

Example code:

<!-- Bad practice -->
<img src="image.jpg" alt="Image" />

<!-- Good practice -->
<img src="image.jpg" alt="A serene sunset over a mountain landscape, 
with hues of orange and purple in the sky." />

Links

Links should be created using the HTML <a> element, made recognizable and clear to users, and should include descriptive text rather than ambiguous phrases to enhance accessibility and user experience.

• Use the HTML <a> element to create links.
• Ensure links are easily identifiable as clickable elements.(It is advisable to underline links for better visibility.)
• Provide clear and specific link text that describes the destination. (Avoid vague phrases like “click here,” “more,” or “continue,” as they do not convey meaningful information about the link’s purpose.)

Example code:

<!-- Bad practice -->
<p>If you'd like to get in touch, send me an <a href="#">email</a>.</p>

<!-- Good practice -->
<p>If you'd like to get in touch, <a href="mailto:sardormdl@gmail.com">send me an email</a>.</p>

Example image:

Labels

According to WCAG standards, an input placeholder is not a replacement for a label and should only be used to provide a brief example of the text to be entered. The best practice is to include both a label and a placeholder to ensure accessibility.

<!-- Bad practice --> 
<input type="text" placeholder="Full name" />

<!-- Good practice --> 
<label for="name">Full name</label>
<input id="name" type="text" placeholder="Full name" />

Radio Buttons

We should use the <fieldset> and <legend> tags to group radio buttons and provide context for screen reader users. When a screen reader encounters a <fieldset> tag, it typically announces that the user has entered a new group or field, helping them understand that the following elements are related. Similarly, when a screen reader encounters a <legend> tag, it reads it as the title or description of the group.

Example code:

<fieldset>
    <legend>What is your favorite color?</legend>
    <label for="red">Red</label>
    <input id="red" type="radio" name="color" />
    <label for="green">Green</label>
    <input id="green" type="radio" name="color" />
    <label for="blue">Blue</label>
    <input id="blue" type="radio" name="color" />
</fieldset>

Semantic HTML

Using landmark regions in semantic HTML helps convey the layout and significance of different areas on a webpage, enabling users of assistive technologies (AT) to navigate these regions quickly.

Example code:

<!-- Landmark regions -->

<nav/>
<header/>
<main/>
<section/>
<footer/>

Lists

Any consecutive items in your lists should be organized using ordered (<ol>) or unordered (<ul>) lists with <li> list items, rather than just using a series of repeating <div> elements.

<!-- Bad practice -->
<h2>To-Do List</h2>
<div>Buy groceries</div>
<div>Walk the dog</div>
<div>Finish the report</div>

<!-- Good practice -->
<h2>To-Do List</h2>
<ol>
    <li>Buy groceries</li>
    <li>Walk the dog</li>
    <li>Finish the report</li>
</ol>

Text Size

The pixel unit is a fixed measurement that does not adjust with changes in the browser’s default font size. Instead, use rem units for setting text font sizes to ensure compatibility with users adjusting their browser settings.

In most browsers, the default font size is 1rem = 16px.

Example code:

h1 {
    font-size: 32px; /* Fixed size, does not scale with user settings */
}

p {
    font-size: 16px; /* Fixed size, does not scale with user settings */
}

h1 {
    font-size: 2rem; /* Scales with user settings (2rem = 32px if default is 16px) */
}

p {
    font-size: 1rem; /* Scales with user settings (1rem = 16px if default is 16px) */
}

Headings

Approximately 68.8% of screen reader users navigate websites using headings, making it crucial to apply them correctly. Here are three main rules to follow:

1. Use consecutive heading levels: Headings should follow a logical, hierarchical order without skipping levels (e.g., don’t jump from <h1> to <h3>).
2. Limit to one <h1> per page: Each page should have a single main heading that represents its content.
3. Use headings for structure, not style: Headings should define the content hierarchy rather than just be styled text.

Exmple code:

<!-- Bad practice -->
<h1>Main Title</h1>
<h3>Subsection Title</h3>
<h2>Another Subsection Title</h2>

<!-- Good practice -->
<h1>Main Title</h1>
<h2>Subsection Title</h2>
<h2>Another Subsection Title</h2>

ARIA - Accessible Rich Internet Applications

ARIA is a collection of attributes that enhance HTML elements by providing additional context for assistive technologies. The primary rule of ARIA is to avoid its use unless necessary; always prefer native HTML semantic elements with built-in behaviors. If you must repurpose an element, use an ARIA role to ensure accessibility.

Example code: Repurposed html element

<div class="custom-tab" role="tab" aria-selected="true" tabindex="0">
    Tab 1
</div>

ARIA Live Regions

ARIA live regions are designated parts of a webpage that are dynamically updated. When the content in these regions changes, screen readers announce the updates without requiring the user to navigate to the modified content.

Common Use Cases:

• Real-time notifications
• Status messages
• Updates from page filtering or searching

Key Attributes:

• aria-controls: Connects the triggering element (cause) with the affected element (effect).
• aria-live: Specifies how changes in the live region are announced:

aria-live settings:

• off: Default; changes are not announced.
• polite: Changes are announced during natural pauses in speech, without interrupting ongoing reading.
• assertive: Changes are announced immediately, interrupting the current reading.

Example code:

<div aria-live="polite" id="notification" role="alert">
    New message received!
</div>

<button onclick="updateNotification()">Receive Message</button>

<script>
    function updateNotification() {
        document.getElementById("notification").textContent = "You've got a new notification!";
    }
</script>

Accessible Ways to Hide Content

Avoid using visibility: hidden; and display: none;, as these methods remove elements from the accessibility tree, making them undetectable by assistive technologies. Instead, consider techniques that visually hide content while keeping it accessible.

Common Methods to Hide Content:

• Position Off-Screen: Use CSS to move the content off-screen.
• Use Opacity: Set the opacity of the element to 0, making it invisible but still present in the accessibility tree.

That concludes my notes on accessibility. Special thanks to Fredrik for his course on this topic. If you're interested in learning more, be sure to check out his free course on Scrimba.

Additional resources:

You Suck At Accessibility (But You Don't Have To): https://www.youtube.com/watch?v=1A6SrPwmGpg