What is the purpose of the "role" attribute in HTML?

Question

I keep seeing role attributes in some people's work. I use it too, but I'm not sure about its effect.

For example:

<header id="header" role="banner">
    Header stuff in here
</header>

Or:

<section id="facebook" role="contentinfo">
    Facebook stuff in here
</section>

Or:

<section id="main" role="main">
     Main content stuff in here
</section>

---

Is this role attribute necessary, better for semantics, and does it improve SEO?

A list of roles can be found here, but I see some people make up their own. Is that allowed or a correct use of the role attribute?

Answer 1

TL;DR

ARIA roles provide semantic meaning to content, allowing screen readers and other tools to present and support interaction with an object in a way that is consistent with user expectations of that type of object. ARIA roles can be used to describe elements that don't natively exist in HTML or exist but don't yet have full browser support.

Roles defined on MDN

The banner role is for defining a global site header, which usually includes a logo, company name, search feature, and possibly the global navigation or a slogan. It is generally located at the top of the page.

The contentinfo role defines a footer, containing identifying information such as copyright information, navigation links, and privacy statements, found on every document within a site. This section is commonly called a footer.

The main landmark role is used to indicate the primary content of a document. The main content area consists of content that is directly related to or expands upon the central topic of a document, or the main function of an application.

---

WAI-ARIA Roles

By default, many semantic elements in HTML have a role; for example, has the "radio" role. Non-semantic elements in HTML do not have a role; and without added semantics return null. The role attribute can provide semantics.

ARIA roles are added to HTML elements using role="role type", where role type is the name of a role in the ARIA specification. Some roles require the inclusion of associated ARIA states or properties; others are only valid in association with other roles.

For example, will be announced as a 'tab panel' by screen readers. However, if the tab panel doesn't have nested tabs, the element with the tabpanel role is not in fact a tab panel and accessibility has actually been negatively impacted.

The ARIA states and properties associated with each role are included in the role's pages, with each attribute also having a dedicated page.

First rule of ARIA

The first rule of ARIA use is "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."

Note

There is a saying "No ARIA is better than bad ARIA." In WebAim's survey of over one million home pages, they found that Home pages with ARIA present averaged 41% more detected errors than those without ARIA. While ARIA is designed to make web pages more accessible, if used incorrectly, it can do more harm than good.

Answer 2

"role attributes" are developed to help people who have vision or eyesight issue. Screen readers inform the user about the elements. Even though this seems an easy task but it is not. if you are not expert and not sure, do not assign a role. you can read from here

It is important to understand that sometimes poor ARIA implementation can cause more problems than it can solve, making the content less accessible. This can happen because of a lack of knowledge of how and when to use ARIA.

Some HTML elements have implicit roles. For example:

h1,h2...h6            -> heading
ul,li                 -> list
button                -> button
a                     -> link
<input type="text"/>  -> text

You can override those, to be more descriptive

In the case of SEO, You can read the-accessibility-and-seo-myth/

A Google search for “Search engine ranking factors” displays a number of results featuring leaders in the SEO/ SEM industry that outline the many factors that improve SEO. The vast majority of the identified ranking factors have no relationship of any kind with Accessibility. In fact, even many of the google-ranking-factors don’t have much relationship with Accessibility.

You can also read: SEO OVERLAP

While it’s important to understand where SEO and accessibility (a11y) overlap in order to optimize correctly for both, it’s also important to note that optimizing for one is not necessarily akin to optimizing for the other. In other words, if you’ve optimized a page for search engines, it doesn’t mean you’ve necessarily made it accessible — and vice versa.

Answer 3

The role and other attributes improve the accessibility for screen readers. It can indirectly help search spiders identify and understand the individual section better. If I compare this and microdata schema, it improves SEO in a small way.

Answer 4

Most of the roles you see were defined as part of ARIA 1.0, and then later incorporated into HTML via supporting specs like HTML-AAM. Some of the new HTML5 elements (dialog, main, etc.) are even based on the original ARIA roles.

http://www.w3.org/TR/wai-aria/

While the First Rule of Aria states:

If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

there are a few primary reasons to use roles in addition to your native semantic element.

Reason #1. Overriding the role where no host language element is appropriate or, for various reasons, a less semantically appropriate element was used.

In this example, a link was used, even though the resulting functionality is more button-like than a navigation link.

<a href="#" role="button" aria-label="Delete item 1">Delete</a>
<!-- Note: href="#" is just a shorthand here, not a recommended technique. Use progressive enhancement when possible. -->

Screen readers users will hear this as a button (as opposed to a link), and you can use a CSS attribute selector to avoid class-itis and div-itis.

[role="button"] {
  /* style these as buttons w/o relying on a .button class */
}

[Update 7 years later: removed the * selector to make some commenters happy, since the old browser quirk that required universal selector on attribute selectors is unnecessary in 2020.]

Reason #2. Backing up a native element's role, to support browsers that implemented the ARIA role but haven't yet implemented the native element's role.

For example, the "main" role has been supported in browsers for many years, but it's a relatively recent addition to HTML5, so many browsers don't yet support the semantic for <main>.

<main role="main">…</main>

This is technically redundant, but helps some users and doesn't harm any. In a few years, this technique will likely become unnecessary for main.

Reason #3. Update 7 years later (2020): As at least one commenter pointed out, this is now very useful for custom elements, and some spec work is underway to define the default accessibility role of a web component. Even if/once that API is standardized, there may be need to override the default role of a component.

Note/Reply

You also wrote:

I see some people make up their own. Is that allowed or a correct use of the role attribute?

That's an allowed use of the attribute unless a real role is not included. Browsers will apply the first recognized role in the token list.

<span role="foo link note bar">...</a>

Out of the list, only link and note are valid roles, and so the link role will be applied in the platform accessibility API because it comes first. If you use custom roles, make sure they don't conflict with any defined role in ARIA or the host language you're using (HTML, SVG, MathML, etc.)

Answer 5

Role attribute mainly improve accessibility for people using screen readers. For several cases we use it such as accessibility, device adaptation,server-side processing, and complex data description. Know more click: https://www.w3.org/WAI/PF/HTML/wiki/RoleAttribute.

Answer 6

I realise this is an old question, but another possible consideration depending on your exact requirements is that validating on https://validator.w3.org/ generates warnings as follows:

Warning: The form role is unnecessary for element form.

Answer 7

As I understand it, roles were initially defined by XHTML but were deprecated. However, they are now defined by HTML 5, see here: https://www.w3.org/WAI/PF/aria/roles#abstract_roles_header

The purpose of the role attribute is to identify to parsing software the exact function of an element (and its children) as part of a web application. This is mostly as an accessibility thing for screen readers, but I can also see it as being useful for embedded browsers and screen scrapers. In order to be useful to the unusual HTML client, the attribute needs to be set to one of the roles from the spec I linked. If you make up your own, this 'future' functionality can't work - a comment would be better.

Practicalities here: http://www.accessibleculture.org/articles/2011/04/html5-aria-2011/

Answer 8

Is this role attribute necessary?

Answer: Yes.

• The role attribute is necessary to support Accessible Rich Internet Applications (WAI-ARIA) to define roles in XML-based languages, when the languages do not define their own role attribute.
• Although this is the reason the role attribute is published by the Protocols and Formats Working Group, the attribute has more general use cases as well.

It provides you:

• Accessibility
• Device adaptation
• Server-side processing
• Complex data description,...etc.