It seems redundant to use an ARIA landmark if the most semantic and accessible way to define the main section of your content is the standard <main> element. Is adding role="main" to the element really necessary?
Not all modern browsers have already mapped the aria-role main to the <main> element (so far only Firefox 21+ and Chrome 26+ have mapped it). When all browser will support this feature, then the attribute role="main" could be dropped, but in the meanwhile it's better to still use it.
Sources:
http://html5doctor.com/the-main-element/#comment-35495 (and Steve Faulkner's answer)
http://html5doctor.com/the-main-element/#comment-36407 (last citation and answer)
It depends on your reason that why you are indent to use 'role'.
The two primary reasons to use roles in your native semantic element is:
Reason 1. Overriding the role where no host language element is appropriate or, for various reasons, a less semantically appropriate element was used.
Example:
Delete
In the above example, a link was used, even though the resulting functionality is more button-like than a navigation link.
Screen readers 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 a buttons w/o relying on a .button class */
}
Reson 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 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.
You can check the below link for more info...
Accessible Rich Internet Applications (WAI-ARIA) 1.0
Related
I am designing a website for our small company and would like to make
use of both semantic tags (<article>, <section>, etc.) and JSON-LD structured data snippets.
In addition to semantic tags and JSON-LD, we want to make out website more accessible to people with disabilities, and I have been learning about WAI-ARIA attributes.
Can the WAI-ARIA attributes be used simultaneously alongside semantic tags and structured data?
Or, is there a risk of a conflict that would affect their functionality?
WAI-ARIA support is iffy between both browsers and screen reader technologies.
I would recommend only using ARIA attributes in situations where you can not achieve the same result in native HTML, as HTML5 has greatly improved semantics. Adding ARIA attributes unnecessarily will do nothing to improve the accessibility of your website, and is just more work for you. Only use it as needed.
The first rule of ARIA states:
If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour 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.
For example, you wouldn't want to add aria-label to an image when you can just use an alt. There is also no need to explicitly assign roles with aria-role when many are already implied through their equivalent HTML elements (eg: button, nav, article). It's also prefered to use HTML states such as required and disabled rather than the ARIA equivalents: aria-disabled and aria-required.
WAI-ARIA Resources
PowerMapper WAI-ARIA Screen Reader Compatibility - This is a really good mapping of which ARIA attributes are compatible with which screen readers and browsers.
What is WAI-ARIA, what does it do for me, and what not? - Key sections I'd recommend reading are "When should I not use it?" and "When should I use it?".
I have decided to start using the html5 main element, of which I haven't used in the past because of lack of support in some browsers.
I knew you could just "fix" the lack of support by doing something like this:
main {
display: block;
}
However I came across one answer that states you should do the below to add it to the DOM as well:
document.createElement('main');
My question is - shouldn't we first check if the browser supports the main element before we do this? I'm not sure the best way to do that would be though? ....or is this not really needed and is safe to use on all page loads regardless of support?
The linked answer isn't really accurate.
document.createElement('main');
is only needed for IE9 and earlier, by helping those versions parse the <main> and </main> tags correctly to form a working main element. As the linked answer says though, calling this on its own is harmless, so you can just do it without worrying about it being called inappropriately. You should however include its containing script synchronously in JavaScript before the first (and normally only) <main> tag in the markup if you are supporting IE versions of 9 or earlier.
IE10 and IE11 parse the tags correctly, but treat the main element created as an inline element. To make it styled like other browsers, use
main {
display: block;
}
The other aspect to consider is the accessibility landmark role. IE will not expose the main landmark role by default, so you may wish to do <main role="main"> to make it do so, although it should be noted that the HTML5 spec discourages this.
What I am seeing on the Internet a lot is that the ARIA roles on HTML5 tags are mostly an exact duplicate (in meaning) of the tag name itself. Why would you want to do that? I'd say you could deduct certain roles just by looking at the tag name.
For example on this "ARIA Role Cheat Sheet website" I see the following:
<nav role="navigation></nav>
<main role="main"></main>
<aside role="complimentory"></aside>
Also in Twitter Bootstrap in the examples a form has the role form: e.g <form role="form">
I'd say, no kidding? When it has something like a search role <form role="search"> it actually provides context what cannot be deducted from the tag itself.
Is it correct to leave the roles empty in the earlier mentioned cases? Where it does not give any apparent extra information about the tag.
The ARIA (Accessible Rich Internet Applications) attributes are meant to be used for elements that are used to create a user interface in a manner that cannot be deduced from the markup otherwise. The reason is that this may help user agents and assistive software to help the user with such elements. Think about a span element that acts as a submit button, or as a checkbox, or as text input widget.
So we are not expected to use ARIA attributes for elements used in their simple, natural meanings. Thus, it is in principle redundant to declare role=navigation for a nav element, since that element has this role as the default and as the only permitted role (as per current specs and drafts). But as #Alohci points out, the attribute may still help, if a user agent is advanced enough to recognize the attribute but not new enough to know the element.
The document Using WAI-ARIA in HTML (Working Draft, 3 October 2013) presents some recommendations on explicitly specifying ARIA attributes, based on information about user agents. Such information is of course mutable, but we can expect that any attibute specified as redundant there will remain redundant. In particular, it says that for nav, main, and aside a role attribute should be specified, but not for form (because user agents surely know the form element).
In contrast, the W3C HTML5 draft, which was recently moved back to LC status, says: “In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.” It specifically says that the role attribute should not be set for nav, main, or aside when its value would match the default value.
WAI-ARIA is older than HTML5. Screen readers implemented support for ARIA roles before HTML5 was mainstream, so for some users the ARIA roles provide benefit even when the equivalent HTML5 elements do not.
Although screen readers are catching up, remember that upgrading a screen reader (unlike upgrading a browser) is an expensive process, so old screen readers are in use far longer than old browsers.
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?
Is this attribute better for semantics?
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?
Any thoughts on this?
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.
Delete
<!-- 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.)
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/
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.
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.
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.
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.
"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.
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?
Is this attribute better for semantics?
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?
Any thoughts on this?
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.
Delete
<!-- 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.)
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/
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.
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.
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.
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.
"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.