Create User Interfaces with Semantic Markup

Learning Objectives

After completing this unit, you’ll be able to:

• Explain why semantic markup is necessary to make content accessible.
• Define the three types of attributes in ARIA.

Introduction

Many factors go into building accessible user interfaces, and generally speaking, the more complex the interface, the more factors you need to consider. For instance, a simple blog post or news article has fewer considerations for accessibility than a news article with commenting, social media features, or other interactive features. A complex web application, such as a report or dashboard builder, a page layout editor, or even a Kanban-style list view has even greater needs in terms of accessibility.

The more complex the web page or application, the more you need to do to make sure it’s accessible for users with disabilities. That said, for any web page or application to be accessible, you need to start with the basics. 

Let’s Talk Semantic Markup

Semantic markup is at the base of all accessibility. Content that appears on a web page should be presented using markup that represents the type of content that is being presented. For instance, tabular data should be presented using <table>-based markup, lists should be presented using <ul>-based markup, visual headings should use heading tags, and so on.

Semantic markup makes content readable and understandable by machines and software—specifically, assistive technologies—which is necessary for content to be accessible. A blind user can use a screen reader to navigate a report builder created with properly formed HTML <table> elements. However, this same user can’t properly navigate or understand the same thing marked up using <div> elements, even though they may look the same to sighted users.

The HTML structure of web pages and applications gives their content meaning to assistive technologies, and users who rely on assistive technologies. We recommend that you use semantic HTML5 elements wherever possible, and that you validate your markup using a checker such as the Nu HTML Checker.

Get Started with ARIA

ARIA, which stands for Accessible Rich Internet Applications, is an extension of HTML that acknowledges that web pages are used for much more than markup or display purposes. ARIA understands that the web is a platform for building complex applications, and provides options to communicate much more advanced interactions to users with disabilities, through assistive technologies.

ARIA works by applying special attributes to HTML DOM nodes. There are three types of attributes available in ARIA: roles, states, and properties.

Roles

Roles are a way to give semantic meaning to HTML elements that traditionally do not have any semantic meaning, such as <div> or <span>. For instance, you can use ARIA roles to identify a set of non-semantic elements as a button or a link, or even more complex components such as menus, comboboxes, modals, or interactive grids. 

Roles are a promise to users. If you add an ARIA role to an element, such as adding role="button" to a <div>, you are telling the <div> to identify itself as a button. This <div> now shows up in the browser’s accessibility tree as a <button>. The browser accessibility tree is a snapshot of the information that is presented to the screen reader. This means you must also provide all of the functionality that a button natively has to this <div>. This includes focus states, keyboard interactivity, mouse interactivity, and so on. Calling a <div> a button but not making it function like a button is breaking that promise to your users.

States

States are attributes that describe the status of an ARIA component to a browser’s accessibility tree. A state describes whether or not a dropdown menu is expanded, whether its input type is disabled or readonly, if a checkbox is checked, if an item in a listbox is selected, and so on. When creating complex components using ARIA, it’s vital to accurately update its various states through a control’s operation. This is all part of keeping that promise to users that you gave when using a role attribute. 

Properties

The W3C defines ARIA properties as, “Attributes that are essential to the nature of a given object, or that represent a data value associated with the object.” These are attributes that describe the nature of an object. Consider the difference between a <select> element with the multiple attribute and a <select> element without the multiple attribute. The former is a combo box where one can make multiple selections, whereas the latter is one where a user needs to click on the collapsed state in order to open the box and select a single item. In this case, multiple is a property of our native <select> element. 

In the same way, ARIA has many property attributes that are used to describe objects, but don’t necessarily change regularly to update an object’s state.

Knowing the which, when, and how of ARIA attributes can be very tricky. In general, we strongly recommend following our component blueprints in the Salesforce Lightning Design System (SLDS). SLDS contains over 900 blueprints of HTML, with detailed accessibility guidelines for markup, attributes, and keyboard interactions. These blueprints include all the correct ARIA roles, properties, and states, in the correct places. Additionally, our blueprints include accessibility information, detailing how to properly associate and manage states and properties of the components you’re building. 

The ARIA in SLDS component blueprints have been tested with assistive technology and are based on the ARIA Authoring Practices Guide. This document is regularly updated, and is the current source of truth for ARIA and many common design patterns. 

You may not find every interaction pattern you need in the SLDS component blueprints. For anything you don’t see in our design system, reference the ARIA Authoring Practices Guide and the ARIA specification itself. Do not trust anything else on the internet—there are many years’ worth of ideas, explorations, and straight-up bad, inaccessible components masquerading as modern, accessible solutions.

Now that you’ve been introduced to the basics of building accessible user interfaces, let’s explore accessibility navigation. 

Resources

• Documentation: ARIA Authoring Practices Guide
• Documentation: Accessible Rich Internet Applications (WAI-ARIA) 
• Tool: Nu HTML Checker
• Salesforce Help: Salesforce Lightning Design System