Leo

<aside role="note" class="update"> <p><strong>Update:</strong> There now exists a native HTML <code><search></code> element that maps to the ARIA <code>search</code> role. 🎊</p> <p>As of March 24th, 2023, the HTML specification added a new grouping element: <a href="https://html.spec.whatwg.org/multipage/grouping-content.html#the-search-element">The <code><search></code> element</a>. Read more about the element in <a href="https://www.scottohara.me/blog/2023/03/24/search-element.html">Scott’s introductory blog post</a>.</p> </aside> <p>There’s been <a href="https://twitter.com/domenic/status/1437891692926017537?s=20">a recent discussion on Twitter</a> about the idea of adding a new element in HTML that represents a search interface. A search form, basically.</p> <p>The idea is to create a semantic HTML element for <a href="https://www.w3.org/TR/wai-aria-1.1/#search">the ARIA <code>search</code> role</a>, which represents a landmark region “that contains a collection of items and objects that, as a whole, combine to create a search facility.”</p> <p>Opinions have been shared in the Twitter thread about whether adding a new HTML element is necessary. Many have argued that it was unnecessary because we can use the ARIA <code>search</code> role and repurpose a <code>form</code> element to create the same semantics. I disagree. And this article is the longer version of <strong>my personal opinion</strong> on the subject.</p> <h2 id="tl%3Bdr" tabindex="-1">tl;dr</h2> <p>I do strongly encourage the addition of a new HTML element that represents—and can consequently obviate the use of—the ARIA <code>search</code> landmark role. A search element would provide HTML parity with the ARIA role, and encourage less use of ARIA in favor of native HTML elements.</p> <p>The suggested element would be syntactic sugar for <code><div role="search"></code> like <code><main></code> is syntactic sugar for <code><div role="main"></code>. This means that it would an HTML sectioning element, not a replacement for another element.</p> <p>I would choose <code><search></code> as a name for that element. In my mind, <code><search></code> would be to <code>role="search"</code> what <code><nav></code> is to <code>role="navigation"</code>. But any other appropriate name would, of course, also work.</p> <p>The rest of this article is my reasoning for encouraging the idea of adding a semantic HTML element for search.</p> <h2 id="html-and-aria-landmark-roles" tabindex="-1">HTML and ARIA landmark roles</h2> <p>The ARIA specification includes a list of ARIA <strong>roles</strong> that are used to define regions of a page as landmarks:</p> <ul> <li><code>banner</code></li> <li><code>complementary</code></li> <li><code>contentinfo</code></li> <li><code>form</code></li> <li><code>main</code></li> <li><code>navigation</code></li> <li><code>region</code></li> <li><code>search</code></li> </ul> <p>HTML currently contains 112 elements. Eight of those elements are <a href="https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html">sectioning elements</a>: <code>main</code>, <code>nav</code>, <code>aside</code>, <code>header</code>, <code>footer</code>, <code>article</code>, <code>section</code>, <code>form</code>.</p> <p>Seven of these HTML sectioning elements are <a href="https://www.w3.org/TR/core-aam-1.2/">mapped</a> to ARIA landmarks, which are used by assistive technologies (ATs).</p> <ul> <li><code>header</code> is the HTML native equivalent for ARIA’s <code>role="banner"</code> (when it is scoped to the <code>body</code> element. See <a href="https://www.w3.org/TR/html-aam-1.0/">HTML Accessibility API Mappings</a> for more information.)</li> <li><code>footer</code> is the HTML native equivalent for ARIA’s <code>role="complementary"</code> (also in the context of the <code>body</code> element)</li> <li><code>nav</code> is the HTML native equivalent for ARIA’s <code>role="navigation"</code></li> <li><code>main</code> is the HTML equivalent for ARIA’s <code>role="main"</code></li> <li><code>form</code> is the HTML equivalent for ARIA’s <code>role="form"</code></li> <li><code>aside</code> is the HTML equivalent of ARIA’s <code>role="complementary"</code></li> <li><code>section</code> is the HTML native equivalent for ARIA’s <code>role="region"</code> (when it has <a href="https://www.w3.org/TR/wai-aria/#dfn-accessible-name">an accessible name</a>)</li> </ul> <p>It is because these elements exist that we often don’t need to use ARIA’s equivalent roles <small>(unless we absolutely <em>have</em> to repurpose another element using those roles, or expose an element to ATs when it is outside of its expected context)</small>.</p> <p>If <code><nav></code> exists, why should a <code><search></code> <small>(or whatever other name it gets)</small> not? If <code><search></code> is to be deemed unnecessary because <code>role="search"</code> exists, wouldn’t this also mean that <code><nav></code> (and other landmark elements) would be considered <em>redundant</em> because <code>role="nav"</code> (and other ARIA roles) exists?</p> <h2 id="html-and-aria-landmarks%2C-beyond-semantics" tabindex="-1">HTML and ARIA landmarks, beyond semantics</h2> <p><a href="https://w3c.github.io/aria/#landmarkroles">ARIA landmark roles</a> are roles assigned to regions of a page that are intended as <strong>navigational landmarks</strong>. Using ARIA landmarks (or their equivalent native HTML elements when they exist) is meant to also facilitate user navigation.</p> <p>From <a href="https://w3c.github.io/aria/">the W3C WAI-ARIA Editor’s Draft</a>:</p> <blockquote> <p>Assistive technologies SHOULD enable users to quickly navigate to elements with role search. User agents SHOULD treat elements with role search as navigational landmarks. User agents MAY enable users to quickly navigate to elements with role search.</p> </blockquote> <p>When HTML sectioning elements (and/or ARIA landmark roles) are appropriately used on a page, assistive technology users such as screen readers users could use those landmarks to navigate the page more efficiently, allowing them to jump to the area of the page that they want.</p> <p>For example, if the <code><nav></code> element (or, equivalently, the <code>role="navigation"</code> ARIA role on a qualifying element) is used to wrap a page’s navigation, the navigation shows up in the VoiceOver Rotor on macOS. Similarly, using the <code>main</code> element will make the main section of the page show up in the landmarks menu. The user can then quickly jump straight to the navigation section or to the main content area of the page if they want to, bypassing other regions of the page. This increases the user’s efficiency and improves their navigation experience.</p> <p>Similarly, when you use <code>role="search"</code> on a <code>form</code> element, that form will show up as a search region in the landmarks menu. The user can then jump to the search form if they need to quickly search for something.</p> <figure><img src="https://www.sarasoueidan.com/assets/images/articlesearch-html-element/search-vo-webaim.png" alt="A screenshot of VoiceOver's Rotor open on the homepage of Webaim.org, showing a search landmark in the Landmarks menu. The screenshot also shows the Web inspector of the page open and a code snippet highlighting the use of role='search' on the form element wrapping the search input field." /><figcaption>The search form on WebAIM's Web site shows up in the Landmarks menu by VoiceOver on macOS because <code>role="search"</code> ARIA role is present on the <code>form</code> element.</figcaption></figure> <figure><img src="https://www.sarasoueidan.com/assets/images/articlesearch-html-element/search-vo-smashing.png" alt="A screenshot of VoiceOver's Rotor open on SmashingMagazine.com, demonstrating the lack of a search landmark in the landmarks menu. The screenshot also shows the Web inspector of the page open and a code snippet highlighting the absence of role='search' on the form element wrapping the search input field." /><figcaption>The search form on Smashing Magazine's Web site is not recognized as a search landmark by VoiceOver on macOS because <code>role="search"</code> ARIA role is absent on the <code>form</code> element.</figcaption></figure> <div class="note"><em>If HTML sectioning elements are used without understanding the associated landmark structure, assistive technology users will most likely be confused and less efficient in accessing content and interacting with web pages.</em></div> <h3 id="but-is-a-native-search-landmark-worth-it%3F" tabindex="-1">But is a native search landmark worth it?</h3> <p>Yes, it is. Search is one of the most common and most used sections of many Web sites. Of course, a “It Depends” is warranted here, too.</p> <p>Depending on the Web site, search might be the first thing a user looks for and uses on a given site. E-commerce Web sites are a great example of where search forms are essential and heavily used. Educational and documentation sites are another example.</p> <p>Take MDN, for example. Search is so important and on MDN that the site even includes a Skip Link that enables keyboard users to skip straight to the search field.</p> <figure><img src="https://www.sarasoueidan.com/assets/images/articlesearch-html-element/mdn-search-skip-link.png" alt="A screenshot the MDN homepage with a 'skip to search' skip link highlighted at the top edge of the page." /></figure> <p>Now I don’t have any user research data or anything, but I would assume that the skip link was added because of how frequently users reach for the search field to look up documentation about specific topics they’re searching for.</p> <h2 id="just-because-an-aria-role-exists%2C-it-doesn%E2%80%99t-eliminate-the-usefulness-of-a-native-html-equivalent" tabindex="-1">Just because an ARIA role exists, it doesn’t eliminate the usefulness of a native HTML equivalent</h2> <p>I’ll just say it again: ust because an ARIA role exists, it doesn’t eliminate the usefulness of a native HTML equivalent.</p> <h2 id="the-purpose-of-aria" tabindex="-1">The purpose of ARIA</h2> <p>…is to provide parity with HTML semantics. It is meant to be used to <strong>fill in the gaps</strong> and provide semantic meaning where HTML falls short.</p> <p>ARIA is <strong>not meant to <em>replace</em> HTML.</strong> If anything, the need to use ARIA as ‘polyfill’ for HTML semantics could be considered as a sign and a constant reminder of the fact that HTML falls short on some semantics that benefit users of assistive technologies. This is due to the lack of native HTML elements that provide the meaning (and sometimes, by extension, the behavior) that these ATs need to convey to their users.</p> <p>If we can get an HTML element that fills a part of the gap, it’s only going to be a win—no matter how small of a win it might seem.</p> <blockquote class="twitter-tweet"><p lang="en" dir="ltr">> ARIA is not meant to replace HTML<br /><br />this! In fact, I think we might want it to go the other way around, with HTML replacing ARIA bit by bit until its services are no longer required</p>— Hidde (@hdv) <a href="https://twitter.com/hdv/status/1438197503095103494?refsrc=twsrc%5Etfw">September 15, 2021</a></blockquote> <script async="" src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> <h2 id="the-first-rule-of-aria" tabindex="-1">The first rule of ARIA</h2> <p>The first rule of <a href="https://www.w3.org/TR/aria-in-html/">ARIA use in HTML</a> states that you should <strong>avoid using ARIA if there is a native HTML element with the semantics of behavior that you require already built in.</strong> If such an element exists, you should reach for that element instead.</p> <p>This means that ARIA should be <strong>a second resort, not a first approach.</strong></p> <p>By providing HTML elements that are implicitly mapped to ARIA roles, we can encourage the use of proper HTML markup to convey semantic meaning, and spread more awareness to help avoid both overuse and misuse of ARIA in general.</p> <p>If we can get an HTML element that enables us to use ARIA less, then that element should, in my opinion, be a welcomed addition.</p> <h2 id="outro" tabindex="-1">Outro</h2> <p>A native search element might feel like a <em>small</em> technical win to many, but the consistency it provides, the HTML semantics gap it fills, and the awareness it could potentially help spread would all make it a useful and welcomed addition.</p> <p>112 to 113 HTML elements? I hope so.</p>