Accessibility: ARIA & Semantic HTML

Accessible Rich Internet Applications (ARIA) is essentially a set of attributes that you can add to your HTML to make web content more accessible to people with disabilities. When we talk about disabilities in the context of web accessibility, we're often referring to issues related to vision, hearing, mobility, and cognitive abilities.

ARIA roles, properties, and states help bridge the communication gap between the structure of web content and assistive technologies, like screen readers. Screen readers, for instance, rely on the information in the HTML to convey the content and functionality of a web page to users who might be visually impaired.

For example, imagine you have a dynamic web application with interactive elements like buttons, accordions, or modals. ARIA allows you to enhance the semantics of these elements, ensuring that assistive technologies can convey their purpose and state accurately to users. For example, if the accordion is open or closed. It's like providing an additional layer of information for those who might not interact with your website in the traditional visual way.

ARIA is a powerful tool in the realm of web accessibility, enabling developers to create a more inclusive and user-friendly web experience for a diverse audience. It's a crucial consideration for anyone involved in web development, ensuring that the digital landscape is accessible to everyone, regardless of their abilities or disabilities.

ARIA (Accessible Rich Internet Applications) introduces three key concepts: attributes, roles, and properties.

• Attributes are the individual values added to elements to convey specific information.
• Roles define the overarching purpose or type of an element.
• Properties provide additional details about the current state or properties of an element, often used in conjunction with roles

ARIA Attributes:

• What they are: ARIA attributes are specific values added to HTML elements to provide additional information about their roles, states, or properties.
• How they're used: They are typically added directly to HTML tags as attributes. Examples include aria-labelledby, aria-hidden, and aria-live.

ARIA Roles:

• What they are: ARIA roles define the type or category of an element, indicating its purpose or function. Roles provide semantic information to assistive technologies.
• How they're used: They are added using the role attribute, specifying the desired role for an element. Examples include role="button", role="alert", and role="menu".

ARIA Properties:

• What they are: ARIA properties are additional state or property values associated with an element, providing more detailed information beyond what is conveyed by native HTML attributes.
• How they're used: They are often combined with ARIA roles or used independently to convey specific information. Examples include aria-checked, aria-selected, and aria-disabled.

W3C ARIA Authoring Practices Guide

Roles

1. role="button": Indicates that the element should be treated as a button, which is interactive and can trigger actions.

2. role="link": Specifies that the element is a hyperlink, similar to an anchor (<a>) tag.

3. role="heading": Indicates that the element is a heading, and you should specify the level using aria-level.

4. role="checkbox": Represents a checkbox, commonly used in forms to allow users to make binary choices.

5. role="radio": Represents a radio button, often used in groups where users can select one option from several.

6. role="textbox": Signifies that the element is an input field for text.

7. role="alert": Represents an element that contains important and usually time-sensitive information for the user.

8. role="status": Indicates that the element represents the status of a live region, like an update or notification.

9. role="navigation": Specifies that the element contains navigation links.

10. role="combobox": Represents a composite widget that combines a single-line text input with a listbox.

11. role="menu": Defines a menu of choices.

12. role="banner": Indicates that the element is a banner or header for a page or a region.

13. role="region": Defines a large section of content, often used to group content for assistive technologies.

14. role="dialog": Represents a dialog or window, typically used for pop-up windows or modal dialogs.

15. role="contentinfo": Role defines a footer, containing identifying information such as copyright information, navigation links, and privacy statements

Properties

1. aria-labelledby: Associates an element with another element that serves as its label.

2. aria-describedby: Points to another element that provides a detailed description of the current element.

3. aria-hidden: Indicates whether an element is visible or hidden, helping assistive technologies understand the current state.

4. aria-haspopup: Indicates whether an element has a popup or sub-level menu.

5. aria-expanded: Indicates the expanded or collapsed state of content, such as in an accordion or dropdown menu.

6. aria-checked: Indicates the current "checked" state for checkboxes and radio buttons.

7. aria-selected: Indicates the current selection state for elements like tabs or list items.

8. aria-live: Defines how updates to content should be conveyed to assistive technologies, such as announcing changes dynamically.

9. aria-controls: Establishes a relationship between an element and another element, typically the one it controls or influences.

Attributes

1. aria-label: Defines a string value that labels the current element, providing a user-readable description.

2. aria-labelledby: Associates the current element with another element, typically used to provide a label for the current element.

3. aria-describedby: Indicates the ID of another element that contains a description or explanation for the current element.

4. aria-hidden: Indicates whether an element is visible or hidden, allowing developers to control what is presented to assistive technologies.

5. aria-live: Defines the live region properties, determining how updates to content within the region are announced to screen readers.

6. aria-expanded: Indicates whether a collapsible element, like an accordion section, is currently expanded or collapsed.

7. aria-disabled: Indicates whether an interactive element is currently disabled or not.

8. aria-checked: Specifies whether a checkbox or radio button is checked, unchecked, or in an indeterminate state.

9. aria-selected: Indicates whether an option within a list is selected.

10. aria-haspopup: Indicates whether an element, like a button, has a popup or sub-level menu.

Both ARIA and semantic HTML (HyperText Markup Language) play crucial roles in web accessibility, but they address accessibility in different ways.

ARIA: ARIA comes into play when dealing with dynamic content, complex widgets, or single-page applications where the semantics provided by HTML might not be sufficient.

ARIA attributes, like role, aria-labelledby, aria-describedby, and others, allow developers to supplement the information provided by semantic HTML. They help in conveying additional details about the roles, states, and properties of elements to assistive technologies.

For instance, if you have a dynamically updated section on your page, ARIA attributes can be used to inform screen readers about the live updates and changes.

Semantic HTML: Semantic HTML refers to using HTML tags that carry meaningful, semantic information about the structure and content of a web page. Examples include <header>, <nav>, <main>, <article>, <section>, and others. Semantic HTML provides a clear and logical structure to your content, making it understandable not only to browsers but also to assistive technologies such as screen readers.

For instance, using <nav> for navigation links or <button> for interactive elements inherently conveys their purpose to both browsers and assistive technologies. Semantic HTML alone goes a long way in creating an accessible and well-structured web page.

Semantic HTML focuses on using appropriate HTML elements to create a well-structured and semantically meaningful document. ARIA, on the other hand, provides additional accessibility information for situations where HTML alone may not convey the complete context, such as in dynamic web applications.

Ideally, developers should strive to use both semantic HTML and ARIA appropriately to ensure a rich and accessible user experience across a wide range of scenarios.

Most common semantic HTML elements used in LibGuides:

For Templates/Navigation/Footer:

• <header>: Defines a header for a document or a section. Typically contains introductory content or navigation links, such as a website's logo, primary navigation menu, or search bar.

• <nav>: Represents a section of a page that links to other pages or to parts within the page. Commonly used for navigation menus, allowing users to move between different sections or pages of a website.

• <main>: Specifies the main content of a document or application. It should not contain content that is repeated across multiple pages, such as navigation links or copyright information.

• <aside>: Defines content that is tangentially related to the content around it, often presented as a sidebar or a section that complements the main content. It can contain information such as related links, advertisements, or supplementary content.

For on-page elements: 

• <details>: Defines a disclosure widget, which can be used to show or hide additional information. It typically contains a summary and additional content that can be toggled visible or hidden by the user.

• <summary>: Represents a summary or caption for the content of the <details> element. It serves as a clickable heading or title for the disclosure widget, allowing users to toggle the visibility of the associated content.