Posted on by Henny Swan in Design and development
Tags: Assistive Technology, Code, Foundations, WCAG
HTML semantics provide accessibility information about page structure and an element's role, name, and state, helping to convey the nature and purpose of content on web pages.
In this post we explore what HTML semantics are, and how they're experienced by people using assistive technologies like screen readers and speech recognition software.
HTML semantics are processed by web browsers, then used by assistive technologies so that people with disabilities can understand what elements are and how to interact with them. An assistive technology is a software that people use to access web content. This could be a screen reader which announces content to people who are blind, or speech recognition software that people with physical disabilities use to navigate content using their voice.
You can use HTML to give content structure by identifying things like headings, lists, paragraphs, and data tables. Writing semantic code means choosing the most appropriate element to identify the content and therefore the structure.
For example, HTML headings are identified using the elements <h1> to <h6>. A screen reader will announce "heading level one” for a <h1>, “heading level two” for <h2> and so on. This gives people who use a screen reader an understanding of the heading hierarchy of a page, much like a table of contents in a book.
In the following example, a screen reader will announce the headings as "Heading level 1, About TetraLogical" and "Heading level 2, Our principles".
<h1>About TetraLogical</h1>
<p>We’re a boutique company, with lots of experience and a whole new attitude.</p>
…
<h2>Our principles</h2>
<p>...TetraLogical is founded on four principles that mean everything we do is:</p>
<ul>
<li>Inclusive...</li>
<li>Sustainable...</li>
<li>Ethical...</li>
<li>Original...</li>
</ul>
…Lists are announced when the <ul> or <ol> elements and <li> are used. In the above example a screen reader will announce “List of four items” (or similar). It will also announce where in the list the item is and what it is, for example "Sustainable, two of four".
An element's role describes its purpose. Roles are announced by screen readers and indicate the type of element something is, for example a link, button, radio button, or checkbox. Many HTML elements have a default role, also known as the implicit role.
For example, the implicit role of the <a> element is "link". When the browser processes the following code it automatically assigns a role of "link" to the element:
<a href="https://www.tetralogical.com/">TetraLogical</a>This means people browsing with a desktop screen reader will hear "TetraLogical link" and people browsing with speech recognition software, can say "Click TetraLogical link" to interact with it.
Another example is buttons. The browser assigns a role of "button" to the <button> element when the following code is used:
<button>Next</button>People browsing with a screen reader will hear "Next, button" while people browsing with speech recognition can say "Click next button" to interact with it.
The role of an element is important because it lets people know how to interact with it. For example, when “link” is announced someone using a screen reader will know to press the Enter key to activate the link. For buttons, they will know to press the Enter key or Spacebar to activate it. The role also impacts the user experience; if you hear "link" you expect a new page to open, if you hear "button" you expect to trigger an action such as open a menu, dialog, or submit a form.
In the example form below, the text 'Sign in instead' is a link to a new page; it has a role of link, and looks like a link. The text 'Next' submits the form; it has a role of button, and looks like a button.
An element's name, or accessible name, is how it's identified. An element's name is announced by screen readers together with the role and used by speech recognition software to map an element to a voice command.
All interactive elements and components must have an accessible name. For example, the accessible name for a link comes from the content inside the anchor element. When a screen reader encounters the following code, it will announce "sustainable accessibility, link", while someone using speech recognition can say "Click sustainable accessibility link".
<a href="https://www.tetralogical.com/">sustainable accessibility</a>
The accessible name for a button comes from the content inside the <button> element. In the following example, a screen reader will announce "Sign in button", while someone who uses speech recognition can say "Click Sign in button".
<button>Sign in</button>
An element's state is its current condition. The state is announced by screen readers so that people know if, for example, a checkbox is selected or unselected, or a button is disabled or not.
In the following example a screen reader will announce “Show password, checkbox checked” because in the code it is indicated as "checked".
<label for="checkboxLabel">
<input type="checkbox" id="checkboxLabel" checked>
Show password</label>
There are times when the HTML semantics need to be extended because they don't do everything we want. For example, there is no way in HTML to indicate if a button is pressed. The Web Accessibility Initiative Accessible Rich Internet Applications specification 1.1, or WAI-ARIA or ARIA for short, can be used to extend HTML.
ARIA complements HTML semantics by providing a set of attributes that allow you to enhance the native roles of HTML elements to build more accessible user experiences. We'll introduce how ARIA can do this in our next foundations post.
Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。