Kompletný sprievodca webovou prístupnosťou pre rok 2024

Web accessibility is no longer just a luxury or an afterthought; it’s a necessity. As of 2024, there are more than a billion people globally who live with some form of disability. This means that every time a website is not accessible, a significant portion of the population is excluded. Beyond legal mandates, like the Americans with Disabilities Act (ADA) and Web Content Accessibility Guidelines (WCAG), web accessibility is fundamental for inclusivity, improved user experience, and even business success.

This article dives deep into web accessibility by focusing on native HTML elements, ARIA roles and attributes, screen readers, and color accessibility to create a truly inclusive web experience.

Importance of web accessibility

Web accessibility ensures that websites and digital services are usable by everyone, regardless of their abilities. A well-designed accessible site is easier to use for people with disabilities, which include visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

Accessibility impacts SEO, usability, and mobile responsiveness, directly affecting how users experience your site and how search engines rank it. For instance, a website that follows accessibility guidelines will naturally have semantic structure, better navigation, and more readable content, all of which benefit SEO.

To align your web project with accessibility best practices, the Web Content Accessibility Guidelines (WCAG 2.1) should be your main point of reference. These guidelines are divided into three levels:

Level A: Minimum level of web accessibility.
Level AA: Addresses the biggest and most common barriers for disabled users.
Level AAA: The highest and most comprehensive level of accessibility.

Native HTML Elements: Accessibility by Design

One of the most effective ways to ensure accessibility is to use native HTML elements as much as possible. These elements are designed to be accessible out of the box. Unlike custom-built elements (which require extensive ARIA roles and JavaScript to emulate native behavior), native HTML components work seamlessly with assistive technologies like screen readers.

Let’s explore some of the most useful native HTML elements and why they are essential for accessibility.

Marking the Page's Main Content

Using the <main> tag, instead of applying role="main" to a <div>, ensures that assistive technologies like screen readers can quickly locate the primary content of your page. The <main> element represents the dominant content of the <body> of a document, eliminating the need for redundant ARIA roles.

The <header>, <footer>, and <aside> tags allow developers to provide clear, semantic markup to define different sections of a page. Unlike generic <div> elements with roles, these HTML5 elements are inherently understood by browsers and assistive technologies. The <header> tag represents introductory content, typically a group of navigational aids or a heading, while the <footer> marks the footer of the section or page, often containing metadata about the content.

Using <aside> instead of a generic <div> with ARIA roles like role="complementary" provides better readability and recognition for assistive technologies. The <aside> tag indicates content that is tangentially related to the main content, such as sidebars or notes.

While both <article> and <section> are used to create sections within a webpage, they serve distinct purposes. The <article> tag is used for independent, self-contained content that could stand alone (like blog posts or news articles), whereas the <section> tag is used for grouping related content within a webpage. The <article> element contains standalone content that could be independently distributed or repurposed, while the <section> element defines thematic groups of content, generally with a heading. Both elements help screen readers identify sections of content more effectively.

Native HTML form elements like <button>, <input>, and <label> come with built-in keyboard and focus management, making them inherently accessible. For example, the <button> element responds correctly to keyboard interactions (such as the Enter or Space key), whereas custom button implementations might require additional JavaScript to replicate that behavior. Additionally, <label> elements help to associate form controls with descriptive text, making forms easier to navigate using screen readers.

<header>
  <a href="" rel="home">My Awesome website logo</a>
  <nav aria-label="Primary">
    ...
  </nav>
</header>
<main>
  <article>
    <h1>My awesome article main title</h1>
    <section>
      <h2>Article section title</h2>
      <p>Lorem ipsum, dolor sit amet consectetur adipisicing elit. Ratione maxime error nesciunt esse aliquam et unde veritatis. Delectus blanditiis ad praesentium, ut expedita corrupti ipsa obcaecati at. Labore, error eaque.</p>
      <section>
        <h3>Article sub-section title 1</h3>
        <p>Lorem ipsum, dolor sit amet consectetur adipisicing elit. Ratione maxime error nesciunt esse aliquam et unde veritatis. Delectus blanditiis ad praesentium, ut expedita corrupti ipsa obcaecati at. Labore, error eaque.</p>
      </section>
      <section>
        <h3>Article sub-section title 2</h3>
        <p>Lorem ipsum, dolor sit amet consectetur adipisicing elit. Ratione maxime error nesciunt esse aliquam et unde veritatis. Delectus blanditiis ad praesentium, ut expedita corrupti ipsa obcaecati at. Labore, error eaque.</p>
      </section>
    </section>
  </article>
  <aside>
    <h2>Table of Contents</h2>
    <nav aria-label="Table of Contents">
      ...
    </nav>
  </aside>
</main>
<footer>
  ...
</footer>

ARIA Roles and Attributes: Enhancing Non-Semantic HTML

While native HTML elements provide inherent accessibility, there are situations where custom components (like modals, tooltips, or custom dropdowns) require ARIA roles and attributes to ensure full accessibility. ARIA (Accessible Rich Internet Applications) helps developers describe elements and their behaviors to assistive technologies, but it’s important to use ARIA judiciously. If a native HTML element is available, prioritize using it.

ARIA Roles

ARIA roles help communicate the purpose of an element to screen readers. For example, if you create a custom widget (e.g., a modal dialog or a custom slider), ARIA roles can be used to define the element’s purpose and behavior.

There are six categories of ARIA roles:

Document structure roles: These roles provide a structural description for sections of content. However, many of these roles are now redundant, as modern browsers support semantic HTML elements that convey the same meaning. Examples include: toolbar, tooltip, presentation / none.
Widget roles: These roles define interactive elements such as buttons, sliders, and checkboxes. Similar to document structure roles, some widget roles overlap with native HTML elements and should be avoided if native elements suffice. Examples include: scrollbar, searchbox, separator, slider, spinbutton, switch, tab, tabpanel, treeitem.
Landmark roles: These roles identify important sections of a webpage, such as navigation bars or banners, and assist screen readers in facilitating keyboard navigation. Use them sparingly, especially when native HTML5 elements can fulfill the same purpose. Examples include:
- banner (equivalent to <header>)
- complementary (equivalent to <aside>)
- contentinfo (equivalent to <footer>)
- form (equivalent to <form>)
- main (equivalent to <main>)
- navigation (equivalent to <nav>)
- region (equivalent to <section>)
- search (equivalent to <form> with a search functionality)
Live region roles: These roles are applied to elements with content that changes dynamically. While sighted users can visually detect these changes, live region roles notify users with screen readers about updates in real-time, ensuring they do not miss critical information. Examples include: alert, log, marquee, status, timer.
Window roles: These roles define sub-windows within the main document, such as pop-up modal dialogs. Examples include: alertdialog,dialog.
Abstract roles: These roles are intended for internal use by browsers to help organize and structure documents. They should not be used in HTML markup, as they do not provide meaningful information to assistive technologies.

ARIA States and Properties

ARIA states and properties communicate the current state or relationships of elements to assistive technologies, ensuring users are aware of changes and context.

There are four categories of ARIA states and properties:

Widget attributes: These attributes define the state or properties of interactive elements. Examples include: aria-autocomplete, aria-checked, aria-disabled, aria-expanded, aria-haspopup, aria-hidden, aria-invalid, aria-label, aria-pressed, aria-readonly, aria-required, and others.
Live region attributes: These attributes notify users of dynamic content changes. Examples include: aria-busy, aria-live, aria-relevant, and aria-atomic.
Drag-and-Drop attributes: These attributes provide information about elements involved in drag-and-drop interactions. Examples include: aria-dropeffect and aria-grabbed.
Relationship attributes: These attributes describe relationships between elements. Examples include: aria-activedescendant, aria-controls, aria-describedby, aria-description, aria-labelledby, and aria-owns.
Global ARIA attributes: These attributes can be applied to any element, providing additional information about the element’s state or role. Examples include: aria-atomic, aria-busy, aria-controls, aria-current, aria-describedby, aria-description, aria-details, aria-disabled, aria-dropeffect, aria-grabbed, aria-haspopup, aria-hidden, aria-invalid, aria-label, aria-labelledby, aria-live, aria-owns, aria-relevant, and many others.

Screen Readers

Screen readers are software that assist blind and visually impaired users by reading the contents of a webpage aloud. Popular screen readers include JAWS (otvorí sa v novom okne), NVDA (otvorí sa v novom okne), and VoiceOver (otvorí sa v novom okne) (for macOS and iOS).

To create content that is friendly to screen readers:

Use semantic HTML: This helps screen readers understand the structure and meaning of your content.
Provide descriptive alt text for images: Include meaningful alt attributes to describe the content of an image, or mark it as decorative (using alt="").
Use headings appropriately: Maintain a logical heading structure (<h1> to <h6>). Avoid skipping heading levels.

Example of appropriate alt text:

<img src="image.jpg" alt="A sunny beach scene with palm trees and a clear blue sky">

Color accessibility: Ensuring perceivable contrast and information

Color accessibility is critical for people with color vision deficiencies, such as color blindness. Designers should avoid relying solely on color to convey meaning and ensure there is sufficient contrast between text and background elements.

Contrast ratios

WCAG 2.1 specifies minimum contrast ratios to ensure text is legible for people with visual impairments:

Normal text: A minimum contrast ratio of 4.5:1.
Large text: A minimum contrast ratio of 3:1.

There are numerous tools available for checking contrast ratios, such as the Contrast Checker by WebAIM.

Avoid relying solely on color

Color should not be the only method of conveying information. For example, an error message should not depend solely on the color red but should also include icons, text, or labels to indicate the issue.

Simulating color blindness

Using simulators like Color Oracle (otvorí sa v novom okne), you can see how your website appears to people with different types of color blindness (e.g., protanopia, deuteranopia, tritanopia). This allows you to ensure your designs are accessible and effective for all users. Consider incorporating alternative indicators such as text, patterns, or icons alongside color to improve accessibility.

Tools for testing and validating accessibility

Developers and designers have access to a wide range of tools that assist in ensuring web accessibility. These tools help automatically check for violations against WCAG standards, simulate different user conditions (such as color blindness or screen readers), and provide insights into how to fix issues. Below are some essential tools:

WAVE (Web Accessibility Evaluation tool): WAVE is a popular, user-friendly tool that provides a visual breakdown of your webpage’s accessibility issues. It highlights problematic areas in both the layout and code, offering suggestions for improvement. WAVE can detect missing alt text, improper use of ARIA roles, contrast issues, and more. It’s available as a browser extension or can be used directly on their website.
Axe accessibility checker: Axe is an open-source tool developed by Deque Systems that automatically analyzes websites for WCAG compliance issues. It integrates with browser developer tools and is one of the most robust and widely-used accessibility checkers. It is especially useful for testing dynamic web applications and single-page applications (SPAs).
Lighthouse: Lighthouse is integrated into Chrome’s developer tools and provides a comprehensive audit of your website. It evaluates accessibility, performance, SEO, and best practices. Its accessibility audit highlights missing ARIA roles, issues with focus management, and other accessibility barriers.
NVDA and VoiceOver screen readers: Testing your website with real screen readers is a crucial step in ensuring accessibility. NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows, while VoiceOver is built into macOS and iOS devices. Testing with these tools ensures that your content is readable and navigable by users who rely on assistive technology.
Color contrast analyzer: Tools like the Color Contrast Analyzer by The Paciello Group and Contrast Checker by WebAIM allow you to measure the contrast ratios between foreground and background colors to ensure they meet the required WCAG standards.

Practical steps for implementing accessibility

The following steps summarize key best practices for creating an accessible web experience:

Start with semantic HTML

Prioritize using semantic HTML elements. Tags like <main>, <header>, <article>, <section>, <nav>, <form>, <button>, and <label> are inherently accessible and work seamlessly with assistive technologies.

Provide text alternatives

Ensure that all non-text content has a text alternative. This includes providing alt text for images, captions for videos, and transcriptions for audio files. For example, an image used solely for decoration should have an empty alt attribute (alt=""), while meaningful images should be described accurately.

Use ARIA judiciously

Use ARIA roles, states, and properties only when necessary. Native HTML elements should be used whenever possible as they are inherently accessible. ARIA can be complex and, if misused, may hinder accessibility rather than improve it. However, ARIA is invaluable for custom components where native HTML elements are not suitable.

Ensure keyboard accessibility

All interactive elements should be navigable and operable with a keyboard. Users with motor impairments often rely on keyboard navigation, so ensure that forms, buttons, menus, and other interactive components are fully keyboard accessible.

Test your website using the Tab key to ensure that:

Interactive elements receive focus in a logical order.
Focus is visibly indicated through outlines or other visual cues.
Custom components, such as modals, properly trap focus while they are open.

Maintain focus and state management

After interactions like form submissions, ensure that focus is managed correctly. For example, if a modal closes or a new page loads, make sure focus shifts appropriately to an actionable or meaningful element.

Test with real users

Accessibility testing should include people with disabilities. While automated tools and simulators are useful, there is no substitute for real user feedback. Engaging users who rely on screen readers, keyboard navigation, or other assistive technologies provides critical insights that automated tools might miss.

Validate color contrast

Ensure that all text has sufficient contrast against its background. This is particularly important for users with low vision or color blindness. Avoid relying solely on color to convey information (e.g., “The red button”) and include alternative cues like icons, text labels, or patterns.

Provide closed captions for videos

Include closed captions for all video content. Captions provide a text alternative for audio content, making videos accessible to deaf and hard-of-hearing users. Ensure captions are synchronized with the video and accurately reflect spoken dialogue and important sounds.

Avoid duplicate links

Ensure that each link on your website points to a unique URL. Avoid creating links with identical text that lead to different destinations, as this can confuse users and impair navigation. For example, avoid having multiple links with the text “Services” pointing to different pages or sections with the same name but different URLs.

Avoid "click here" links

Avoid using vague link text such as "click here." Descriptive link text provides context and helps users, including those using screen readers, understand the purpose of the link without needing additional information. For example, instead of "Click here to learn more about our services," use "Learn more about our web accessibility services."

Properly label input fields

Ensure that all input fields in forms are properly labeled. Each <input> field should have a corresponding <label> element that clearly describes its purpose. This helps users with screen readers and those who rely on keyboard navigation to understand and interact with the form. For example:

<label for="email">Email Address:</label>
<input type="email" id="email" name="email">

Legal implications of inaccessible websites

Ensuring web accessibility is not just about inclusivity—it's also a matter of legal compliance. Many countries have laws mandating that websites must be accessible to people with disabilities. Non-compliance can result in legal consequences, including lawsuits and fines. For example:

United States: The Americans with Disabilities Act (ADA) mandates that websites be accessible to individuals with disabilities. Recent court rulings have affirmed that public-facing websites are required to comply with the ADA.
European Union: The European Accessibility Act (EAA) and the Web Accessibility Directive ensure that public sector websites and apps meet accessibility standards.
Canada: The Accessible Canada Act (ACA) and the Accessibility for Ontarians with Disabilities Act (AODA) set forth accessibility requirements for both government and private-sector websites.

Ignoring web accessibility not only exposes organizations to legal risks but also limits their audience and potential customer base. Committing to accessibility demonstrates a dedication to inclusivity and fairness, fostering a positive reputation and broadening market reach.

Conclusion

Creating accessible websites is a fundamental responsibility for web developers and designers. By utilizing native HTML elements, applying ARIA roles appropriately, accommodating screen readers, and ensuring adequate color contrast, we can make the web accessible to everyone.

Accessibility should be integrated into the web development process from the start, rather than being an afterthought. Proper implementation enhances the overall user experience, expands the reach of your content, and ensures adherence to legal standards. Most importantly, it contributes to a more inclusive web environment for all users.

As technology evolves, so too must our commitment to accessibility. Every user deserves equal access to online information and services. By following these best practices, we can create a better, more inclusive web for everyone. If you're ready to elevate your website's accessibility and ensure compliance with modern standards, let Playful Sparkle help. Contact us today to discover how we can assist you in creating a more inclusive online experience.

Resources

Autor článku Zsolt Oroszlány

Vedúci kreatívnej agentúry Playful Sparkle, prináša viac ako 20 rokov skúseností v oblasti grafického dizajnu a programovania. Vedie inovatívne projekty a vo voľnom čase rád cvičí, pozerá filmy a experimentuje s novými funkciami CSS. Zsoltova oddanosť svojej práci a záľubám poháňa jeho úspech v kreatívnom priemysle.