use of role presentation

• Skip to main navigation
• Skip to main content
• Continue about your business

Black Lives Matter, contribute.

Tim Wright dot Org

The difference between role=”presentation” and aria-hidden=”true”.

In dealing with  role="presentation" and aria-hidden="true" you may find that they both have deceptively similar functions when it relates to how they interact with assistive technology (screen readers). Before we dig into the difference between these two attributes we first need to learn a little bit about how accessibility in a Web browser works and this thing called:  The Accessibility Tree

The Accessibility Tree

The accessibility tree is a mapping of objects within an HTML document that need to be exposed to assistive technology (if you’re familiar with the DOM , it’s a subset of the DOM ). Anything that communicates aspects of the UI or has a property or relationship that needs to be exposed, gets added to the tree. This happens automatically for most elements when you use a strong semantic HTML structure, but you can also add or remove objects programmatically with accessibility hooks like:   role="presentation" and aria-hidden="true" (and some CSS properties). In a nutshell, this means… if I have a text input on a page, a screenreader will be able to interact with it, because it has been added into the accessibility tree.

If  role="presentation" and aria-hidden="true" do the same thing and interact with the accessibility tree the same way, then what’s the difference? Why do we even need both of them?

It’s true, that both these attributes will remove objects from the accessibility tree, but they act at different levels and report varying semantics to assistive technology.

Presentational Roles

Most of the documentation you’ll find online about the role="presentation" attribute mentions removing spacer images,and layout tables. Well that’s not very helpful in 2016, because we don’t use spacer images anymore and table layouts have long since been removed from our minds. If that’s true, then what good is this attribute?

Presentational roles are used when elements need to be in the DOM, but the semantics of them are inaccurate or unnecessary. We’re basically telling a screen reader that the semantics of an element are wrong, so ignore them. Which is why the example <table role="presentation"> is often used to present it to the world.

In the below example you’ll see an unordered list that is using  role="presentation" to remove it’s semantics:

Below, is that gets reported to assistive technology. Note that the <span> elements could also be <div> because neither have a semantic meaning.

Something important to notice here is that all children of the original <ul> have had their semantics removed as well. The exception to this is the link in the second list item. Using role="presentation" will not remove and content or semantic definition from focusable elements. That means your links, buttons, and inputs will remain as they should, along with all the content. There are some elements, like images, that will get completely removed from the tree when this attribute is applied (you’d use it when it doesn’t make sense for an image to have alternative text so it can be removed from the tree).

This is an important distinction to make when comparing to aria-hidden="true" , which is a little more aggressive in how it interacts with the accessibility tree.

ARIA Hiding

Completely hiding an element from a screen reader is pretty common in a couple different situations:

• A UI element is detrimental or unimportant to assistive technology (you see this a lot with icons – for better or worse)
• You’re mimicking the visual UI (like menus opening and closing)

The aria-hidden attribute has two states: true and false and they correspond to an element’s state within the accessibility tree. aria-hidden="true" means the element is removed from the tree, and aria-hidden="false" means the element is present in the tree; the default state for an element is “false”. Elements can be added or removed in the HTML or programmatically in JavaScript and combined with other accessibility attributes to create robust interactions with assistive technology.

If you’re changing an element’s hidden state from true to false, this should always happen within JavaScript to provide a fallback for someone browsing with JavaScript turned off. If an element’s state is “hidden” and it will always remain hidden, it’s fine to add aria-hidden="true" right into the HTML.

The code block below shows two examples. One is hidden via the HTML , and the other within JavaScript to show a toggle interaction ( you can also check it out in this pen ):

Using aria-hidden="true" will completely remove all elements, child elements, and content from the accessibility tree regardless of the default semantic nature and they will remain removed until the aria state is changed to false it functions in much the same way as CSS’s display:none . This is where it differs from role="presentation" .

When you’re thinking about removing an element from the accessibility tree first think, “Am I removing the element all together or just the semantics?” If you do that, it will be sure to lead you down the right path and make your UI all the more pleasurable for assistive technology to consume.

Resources and Further Reading

• The Accessibility and DOM Tree
• The Presentational Role
• aria-hidden (state)
• Practical ARIA examples
• Back to main navigation
• Back to main content

 Understanding the HTML Role ‘Presentation’ and Its Impact on Accessibility

• Post author: Geoff Graham
• Post category: HTML
• Post last modified: December 18, 2023
• Post comments: 0 Comments

In the HTML, the ‘role=”presentation” attribute conveys that it is for presentational purposes only and does not have a semantic meaning. Explore the intricacies of HTML role presentation and its associated elements in this article.

In HTML, the role=”presentation” characteristic explicitly implies that the element is purely presentational or decorative and does not bring any semantic meaning. This characteristic is, in particular, useful for elements that can be blanketed for styling or format purposes but no longer contribute to the shape or means of the file. 

When an element is assigned role=”presentation”, it informs assistive technology, which includes screen readers, that the content within that element ought to be dealt with as decorative and should not be presented to users in a manner that indicates it has a selected role or which means.

HTML Role Presentation: Importance of Accessibility in Web Development

Accessibility in web development is paramount because it ensures that digital content is usable and perceivable using people with diverse abilities.

The HTML role presentation contributes appreciably to accessibility by facilitating net pages that can be navigable and understandable for everyone, including those using display readers or different assistive devices.

Builders can carry semantics by assigning appropriate roles to factors, enhancing overall consumer enjoyment, and making the internet more inclusive. In precis, the role attribute in HTML is a powerful device that aids in creating handy and well-established internet content.

Understanding the Accessibility Tree

The Accessibility Tree (or “a11y tree”) is a critical idea in internet improvement, specifically within the context of making accessible websites. It is a hierarchical illustration of the shape and homes of a web page, specially designed to be interpreted through assistive technology.

The Accessibility Tree complements the DOM (Document Object Model) by supplying extra information about the semantics and accessibility roles of the report.

In the context of HTML, the Accessibility Tree reflects the relationships and roles of HTML elements, permitting assistive technology like display readers to bring significant statistics to users with disabilities.

For instance, a heading element (<h1> to <h6>) in HTML no longer simplest defines the document’s shape but conveys hierarchical information to the Accessibility Tree, assisting display readers in imparting content in a dependent and understandable way.

The role characteristic in HTML plays a huge role in shaping the Accessibility Tree.

Role of the role=”presentation” attribute within the accessibility tree​.

The role=”presentation” attribute is particularly beneficial, while developers must encompass non-semantic factors for styling or layout roles without affecting the file’s standard meaning.

Using role=” presentation,” developers sign to assistive technology that the element is not intended to convey extensive records and has to be handled as ornamental or presentational.

In conclusion, understanding the Accessibility Tree and utilizing the role attribute, specifically with the role=”presentation” price , empowers developers to create internet content that isn’t the best structurally sound but also on hand to customers with various wishes. 

Presentational Roles and Their Significance

HTML role presentation talks about using the role attribute to define elements that might be, in basic terms, presentational or ornamental.

The role=”presentation” attribute explicitly tells assistive technologies that the associated HTML element needs to be handled as having no semantic meaning, ensuring that it no longer contributes to the Accessibility Tree’s structural or informative components.

Presentational roles, mainly role=”presentation”, allow developers to encompass factors for styling or format roles without deceptive assistive technologies or affecting the record’s meaning. It affords a way to split the visual presentation of content from its underlying structure.

This is for helping developers create visually attractive designs without compromising accessibility.

Historical context and evolution of role=” presentation” usage.

The role=”presentation” attribute’s ancient context originates in the evolution of web development practices.

In the early days of the web, builders regularly used HTML factors in more presentational than semantic ways, leading to confusion for assistive technologies. For instance, builders may use a <div>; element for styling roles without conveying any semantic that means.

To deal with this issue, the WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) specification introduced the role attribute, and the value “presentation” turned into, in particular, added to indicate that an element had no semantic role.

As web development standards and best practices evolve, the significance of setting apart content material structure from presentation becomes more apparent. The adoption of role= ”presentation” grew to ensure that assistive technology may want to.

This may be as it should be interpreted: net content enhances the overall accessibility of websites. In modern net improvement, using presentational roles is considered a precise practice, selling a clean separation of worries among content shape and visual presentation.

The Role of ARIA in Hiding Semantics

Accessible Rich Internet Applications (ARIA) is a set of attributes introduced to enhance the accessibility of applications . These are mainly those advanced using JavaScript, Ajax, and dynamic technologies. ARIA presents a way to supplement HTML semantics by conveying additional information to assistive technology.

One key aspect of ARIA is its role in modifying the presentation of particular elements while preserving their semantic meaning. Role= “presentation” and aria-hidden=”real” are two commonly used attributes for this motive. The choice among them depends on the developer’s purpose — whether they want to deliver that an element is presentational.

Comparison of role=”presentation” and aria-hidden=”true” attributes​​.

The role=”presentation” characteristic is carried out to HTML elements to imply that they have no explicit semantic meaning. This is to split visual styling from the report’s structural semantics. On the opposite hand, the aria-hidden=”authentic” attribute is to hide elements from assistive technology.

When aria-hidden=”actual” is implemented in a component, it alerts screen readers and other assistive technologies. The alert is that the content material inside that element must be ignored and not provided to users. The role=”presentation” is specifically for factors that are meant to be in basic terms presentational.

On the other hand, aria-hidden=”real” is a broader attribute for any element to hide from assistive technology.

Common Uses of the role=”presentation” Attribute

In web development, the HTML role presentation attribute becomes a valuable tool, explicitly indicating that an HTML element should be treated purely as presentational or decorative, devoid of semantic significance.

This attribute is beneficial when developers want to decorate the visual presentation of content without introducing misleading information for assistive technology.

Here are some everyday use instances for the role=” presentation” attribute:

1.) Decorative Images:

Decorative snapshots used for classy roles often do not contribute to the content material . By applying role=”presentation” to the related <img> element, developers inform display screen readers and other assistive technologies that the image is only ornamental and is not applicable.

<img src=”decorative-image.jpg” alt=”” role=”presentation”>

2.) Styling Containers:

Div elements or other containers are in basic terms for styling purposes and have no semantic significance. Applying role=” presentation” to these elements guarantees they do not intrude with the Accessibility Tree, preserving a clean separation between visual styling and record structure.

<div class=”styling-container” role=”presentation”>

<!– Content for styling purposes only –>

</div>

3.) Spacer or Separator Elements:

When builders use non-semantic elements to create spacing, html role presentation is to clarify their reason for assistive technology.

<div class=”spacer” role=”presentation”></div>

Impact of role=” presentation” on specific HTML elements

1.) lists (ul, ol):.

Applying role=” presentation” to lists suggests that the listing gadgets do not convey a semantic order or hierarchy. This can be useful whilst builders use lists for layout roles in preference to representing a significant sequence.

<ul role=”presentation”>

    <li>Item 1</li>

    <li>Item 2</li>

    <li>Item 3</li>

</ul>

2.) Tables:

People use tables for layout or presentation rather than displaying tabular information.By applying role=”presentation” to a table, builders ensure screen readers recognize that the desk is not conveying records relationships.

<table role=”presentation”>

    <!– Table content for layout purposes only –>

</table>

Therefore, the role=”presentation” attribute is a powerful device for web developers to beautify visible layouts without compromising accessibility.

Limitations and Considerations

The role=”presentation” attribute is usually effective in instructing browsers and assistive technology. This is to deal with an element as merely presentational. There are concerns that builders have to be aware of:

1.) Interactive or Focusable Elements:

Browsers may overlook the role=”presentation” attribute in certain cases when applied to interactive elements. For example, assigning role=”presentation” to a button or hyperlink might lead the browser to recognize it as interactive.

Also, display screen readers may additionally announce it as such. Developers must work cautiously while using role=”presentation” on factors customers would engage with for steady behavior.

<!– The role=”presentation” may not prevent interaction behavior –>

<button role=”presentation”>Click me</button>

2.) Global ARIA States:

Certain global ARIA states, such as aria-stay and aria-busy, can affect the effectiveness of HTML role presentation. For instance, if an element with role=”presentation” is inside a region with aria-live=”assertive”, it would display reader customers.

Developers should consider the broader context and how global ARIA states might influence the visibility of factors with role=”presentation”.

<div aria-live=”assertive”>

    <span role=”presentation”>This message will be announced.</span>

3.) WAI-ARIA Authoring Practices:

Seeking advice from the WAI-ARIA Authoring Practices pointers and specifications is essential. This is for the maximum up-to-date hints on using ARIA attributes, along with role=”presentation”.

As net standards evolve, new considerations and first-rate practices might also emerge, and builders need to live knowledgeable about adjustments.

<!– Always refer to the latest WAI-ARIA Authoring Practices guidelines –>

<div role=”presentation”>Content following best practices</div>

Therefore, while role=” presentation” is a valuable device for reinforcing internet accessibility, builders need to be privy to its barriers in unique contexts, along with interactive factors and global ARIA states.

See Also: How to Make a Quiz in HTML? What to do?

The Role Attribute: Categories and Usage

The HTML role presentation is flexible, supplying several classes to define the motive or element. These classes consist of:

1.) Abstract Roles:

Outline abstract standards with roles not limited to specific elements. For instance, use role=”variety” to define variety input and role=”institution” to group elements.

2.)Widget Roles:

Widget roles are for interactive consumer interface factors. Examples include role=”button” for clickable buttons and role=”textbox” for input fields.

3.)Document Structure Roles:

Define record shape and semantics. Examples include role=”article” for representing independent content material and role=”navigation” for navigation menus. 

4.)Landmark Roles:

Landmark roles become aware of particular regions of a page, assisting navigation for users. Examples include role=”header” for the header phase and role=”major” for the principle content material vicinity. 

To use the role attribute effectively, remember the following guidance:

1.) semantic html first:.

Whenever possible, depend upon semantic HTML factors instead of adding roles. HTML5 introduces elements like <nav> <article>, and <phase> that deliver meaning.

2.) Use Roles for Custom Elements:

When growing custom additives or interactive elements that do not have native HTML equivalents, use suitable ARIA roles to bring their motive to assistive technologies. 

3.) Avoid Overusing Presentation Roles:

While role=” presentation” is beneficial in simple terms and decorative factors, it’s crucial to apply it judiciously. Ensure that it honestly adds price to accessibility without compromising the overall shape of the file.

By understanding the kinds of roles and adhering to excellent practices, builders can leverage the role attribute to enhance accessibility.

See Also: Understanding Data Formats: Plain Text, XML, HTML, JSON, and Beyond

In conclusion, the role attribute in HTML is a pivotal device in internet development, presenting a way to enhance accessibility and convey essential facts to assistive technologies.

We explore its diverse packages, together with the categorization into Abstract, Widget, Document Structure, and Landmark roles, every serving precise purposes in defining the character of HTML factors.

We look at scenarios wherein the role=”presentation” characteristic proves beneficial without compromising the semantic integrity of their content material. However, it is vital to recognize the limitations, such as the capability to disregard the attribute for positive interactive factors.

See Also: Achieve Stylish HTML Tables without CSS: Border Techniques and Examples

Encouragement to prioritize accessibility in web design.

As we navigate the dynamic landscape of net development, the overarching subject matter is prioritizing accessibility. By adhering to excellent practices and staying in the loop about evolving requirements, developers contribute to an extra-inclusive digital realm. 

See Also: Troubleshooting HTML Audio Autoplay Not Working

Hi, I’m Geoff. I design. I develop. I do lots of things in between. What that really boils down to is that I make websites.

Leave a Reply Cancel reply

Save my name, email, and website in this browser for the next time I comment.

DigitalA11Y

Your Accessibility Partner

WAI-ARIA: role=presentation

An element whose implicit native role semantics will not be mapped to the accessibility API.

Description

An element whose implicit native role semantics will not be mapped to the accessibility API. See synonym none.

Note regarding the ARIA 1.1 none role.§

In ARIA 1.1, the working group introduced none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word “presentation” or “presentational.” Many individuals erroneously consider role=”presentation” to be synonymous with aria-hidden=”true”, and we believe role=”none” conveys the actual meaning more unambiguously.

Until implementations include sufficient support for role=”none”, web authors are advised to use the presentation role alone role=”presentation” or redundantly as a fallback to the none role role=”none presentation”.

The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.

Example use cases:

• An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);
• An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
• An element used as an additional markup “hook” for CSS; or
• A layout table and/or any of its associated rows, cells, etc.

For any element with a role of presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of presentation. Thus, the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.

Role=Presentation Example 1

For example, according to an accessibility API, the following markup elements would appear to have identical role semantics (no role) and identical content.

1. [role=”presentation”] negates the implicit ‘heading’ role semantics but does not affect the contents.

2. There is no implicit role for span, so only the contents are exposed.

3. Depending on styling and other factors, this role declaration is redundant in some implementations.

4. In all cases, the element contents are exposed to accessibility APIs without any implied role semantics.

The presentation role is used on an element that has implicit native semantics, meaning that there is a default accessibility API role for the element. Some elements are only complete when additional descendant elements are provided. For example, in HTML, table elements (matching the grid role) require tr descendants (the row role), which in turn require th or td children (the gridcell, columnheader, rowheader roles). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as required owned elements.

When an explicit or inherited role of presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has required owned elements, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined. Also, when an explicit or inherited role of presentation is applied to a host language element which has required children as defined by the host language specification, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any required children that do not have an explicit role defined.

In HTML, the img element is treated as a single entity regardless of the type of image file. Consequently, using role=”presentation” or role=”none” on an HTML img is equivalent to using aria-hidden=”true”. In order to make the image contents accessible, authors can embed the object using an object or iframe element, or use inline SVG code, and follow the accessibility guidelines for the image content.

For any element with an explicit or inherited role of presentation and which is not focusable, user agents MUST ignore role-specific WAI-ARIA states and properties for that element. For example, in HTML, a ul or ol element with a role of presentation will have the implicit native semantics of its li elements removed because the list role to which the ul or ol corresponds has a required owned element of listitem. Likewise, although an HTML table element does not have an implicit native semantic role corresponding directly to a WAI-ARIA role, the implicit native semantics of its thead/tbody/tfoot/tr/th/td descendants will also be removed, because the HTML specification indicates that these are required structural descendants of the table element.

Note: Only the implicit native semantics of elements that correspond to WAI-ARIA required owned elements are removed. All other content remains intact, including nested tables or lists, unless those elements also have a explicit role of presentation applied.

For example, according to an accessibility API, the following markup elements would appear to have identical role semantics (no roles) and identical content.

1. [role="presentation"] negates the implicit 'list' and 'listitem' role semantics but does not affect the contents .

2. There is no implicit role for "foo", so only the contents are exposed.

Note: There are other WAI-ARIA roles with required children for which this situation is applicable (e.g., radiogroups and listboxes), but tables and lists are the most common real-world cases in which the presentation inheritance is likely to apply.

For any element with an explicit or inherited role of presentation, user agents MUST apply an inherited role of presentation to all host-language-specific labeling elements for the presentational element. For example, a table element with a role of presentation will have the implicit native semantics of its caption element removed, because the caption is merely a label for the presentational table.

Authors SHOULD NOT provide meaningful alternative text (for example, use alt=”” in HTML) when the presentation role is applied to an image.

In the following code sample, the containing img and is appropriately labeled by the caption paragraph. In this example the img element can be marked as presentation because the role and the text alternatives are provided by the containing element.

In the following code sample, because the anchor (HTML a element) is acting as the treeitem, the list item (HTML li element) is assigned an explicit WAI-ARIA role of presentation to override the user agent’s implicit native semantics for list items.

Presentational Roles Conflict Resolution

There are a number of ways presentational role conflicts are resolved.

Host languages elements, having implicit presentational roles for which no roles, may be applied, MUST never be exposed to in the accessibility tree. With this exception, user agents MUST always expose global WAI-ARIA states and properties to accessibility APIs. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics. However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied.

For example, aria-haspopup is a global attribute and would always be applied; aria-level is not a global attribute and would therefore only apply if the element was not in a presentational state.

Here [role=”presentation”] is ignored due to the global aria-haspopup property.

Explicit roles on a descendant or owned element override the inherited role of presentation, and cause the owned element to behave as any other element with an explicit role. If the action of exposing the implicit role causes the accessibility tree to be malformed, the expected results are undefined and the user agent MAY resort to an internal recovery mechanism to repair the accessibility tree.

If an element with a role of presentation is focusable, or otherwise interactive, user agents MUST ignore the normal effect of the role and expose the element with implicit native semantics, in order to ensure that the element is both understandable and operable.

User agents MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics. However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied.

HTML Example

Html example 2, html example 3.

1. [role=”presentation”] is ignored due to the global aria-haspopup property.

2. [role=”presentation”] negates the both the implicit ‘heading’ and the non-global level.

Characteristics

Superclass Role

Inherited States and Properties

• aria-atomic
• aria-busy (state)
• aria-controls
• aria-current (state)
• aria-describedby
• aria-details
• aria-disabled (state)
• aria-dropeffect
• aria-errormessage
• aria-flowto
• aria-grabbed (state)
• aria-haspopup
• aria-hidden (state)
• aria-invalid (state)
• aria-keyshortcuts
• aria-labelledby
• aria-relevant
• aria-roledescription
• author (if role discarded by error conditions)

Semantic HTML

No HTML element equivalent.

• WAI-ARIA 1.2 Specification Refer to the notes from the WAI-ARIA 1.2 specification for more information on role=presentation
• HTML5 Accessibility Chops: notes on using ARIA by TPGi

Explore more on DigitalA11Y Insights

Description A document structural element. Roles for document structure support the accessibility of dynamic web…

Description A form widget that allows the user to make selections from a set of…

A form of widget that performs an action but does not receive input data. Note:…

Description A structure that labels or summarizes the topic of its related section. Note: sectionhead is…

Description A renderable structural containment unit in a document or application. Note: section is an abstract…

Raghavendra Satish Peri empowers enterprises with his expertise in digital accessibility and marketing. Through his impactful work, he collaborates with both small businesses and large enterprises, spearheading digital transformation initiatives. Raghavendra is the author behind the influential Accessibility Blog hosted at DigitalA11Y.com , where he delves into the intricate realm of digital accessibility and its significance. Passionate about fostering change within the tech landscape, Raghavendra actively inspires local tech communities through engaging meetups and mentorship. He is the driving force behind HelloA11Y.com , a vibrant platform that unites accessibility professionals, developers, and enthusiasts, propelling the adoption of accessible practices. Beyond the digital realm, Raghavendra seeks diverse experiences. You might find him exploring various cuisines at local cafes and restaurants or immersing himself in thought-provoking audio books. His insights and musings also find a home on his Personal Blog at raghava.in , where he shares his thoughts and experiences with a wider audience.

Similar Posts

WAI-ARIA: Role=Navigation

A collection of navigational elements (usually links) for navigating the document or related documents. Description A collection of navigational elements (usually links) for navigating the document or related documents. User agents SHOULD treat elements with the role of navigation as navigational landmarks. Screen Reader Support For Role=Navigation Expectation JAWS Narrator NVDA Orca TalkBack VoiceOver (iOS) VoiceOver (macOS)…

WAI-ARIA: Role=Columnheader

A cell containing header information for a column. Description A cell containing header information for a column. columnheader can be used as a column header in a table or grid. It could also be used in a pie chart to show a similar relationship in the data. The columnheader establishes a relationship between it and…

WAI-ARIA: Role=Banner

A region that contains mostly site-oriented content, rather than page-specific content. A region that contains mostly site-oriented content, rather than page-specific content. Description A region that contains mostly site-oriented content, rather than page-specific content. Site-oriented content typically includes things such as the logo or identity of the site sponsor, and a site-specific search tool. A…

WAI-ARIA: Role=Status

Description A type of live region whose content is advisory information for the user but is not important enough to justify an alert, often but not necessarily presented as a status bar. Authors SHOULD ensure an element with role status does not receive focus as a result of change in status. Status is a form…

WAI-ARIA: Role=Listitem

Description A single item in a list or directory. Authors MUST ensure elements with role listitem are contained in, or owned by, an element with the role list or group. ROle=Listitem Example Pseudo-list with ‘list’ and ‘list-item’ roles Characteristics Superclass Role Subclass Roles Required Context Role Supported States and Properties Inherited States and Properties Name…

WAI-ARIA: Role=Scrollbar

A graphical object that controls the scrolling of content within a viewing area, regardless of whether the content is fully displayed within the viewing area. Description A graphical object that controls the scrolling of content within a viewing area, regardless of whether the content is fully displayed within the viewing area. A scrollbar represents the…

One Comment

Role presentation on a DIV or SPAN element is one that confuses me. In the post you state ‘3. Depending on styling and other factors, this role declaration is redundant in some implementations. Sample Content ‘. However you have not given an example of when, styling and other factors’ cause it is to not be redundant, and how this applies.

I often see the presentation role placed on DIVs and SPANs of a webpage and would like to understand when this has an effect on the end user, and why.

Thanks. Laurence

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

The difference between aria-hidden, role="presentation" and role="none"

To provide a better user experience in many cases is important to know what to hide to assistive technologies..

Table of contents

• What is aria-hidden?

Limitations of role="presentation"

• What is role="none"?

When to use aria-hidden, role="presentation", and role="none"

We have already discussed, in a previous article , the different ways to hide something from displaying but not from assistive technologies. This time we'll see the opposite: how to hide something to assistive technologies: that's where aria-hidden , role="presentation" , and role="none" come into play. These attributes basically serve the same scope but have different purposes. Let's try to clear up any confusion and make sure we're using them correctly.

What is aria-hidden ?

Think of aria-hidden as a cloak of invisibility for screen readers and other assistive technologies. You can use it to hide non-essential or decorative elements that would only clutter up the screen for people with disabilities. By adding aria-hidden to these elements, you can make your website less overwhelming and quicker to read for users with disabilities.

Aria-hidden doesn't actually remove the content from the page, it just makes it disappear for screen readers or, being more specific, removes that element and all of its children from the accessibility tree.

What is role="presentation" ?

With role="presentation" is like putting on a mask to your element and letting it go in incognito. It's a way to indicate that an element is purely presentational and has no semantic meaning. This attribute is commonly used for decorative images or spacers that don't add any value to the content.

Unlike aria-hidden, role="presentation" actually doesn't remove the element from the accessibility tree altogether, but strips it of its semantic meaning, leaving the element like a <span>.

Applying this role to an element, automatically spreads also to all its children.

Elements with role="presentation" are not part of the accessibility tree anymore and then is useless (and not correct) to have an accessible name: don't use aria-labelledby or aria-label on them then.

Browsers will ignore declarations like role="presentation" and role="none" when on focusable elements (even if they're focusable thanks only to tabindex attribute). Browsers also ignore the inclusion of the role if any of the element contains any global ARIA states and properties, such as aria-describedby .

What is role="none" ?

The role="none" is exactly like role="presentation" . It has been introduced just to help avoid confusion with the word "presentation": both are identical in their behavior and usage.

role="none" and aria-hidden="true" serve similar purposes in that they both indicate to assistive technologies that an element should be ignored or skipped over. However, there is a subtle difference between the two.

role="none" is used to indicate that an element has no semantic meaning and should be ignored by assistive technologies. It is typically used for elements that are purely presentational or decorative in nature, aria-hidden="true" , on the other hand, is used to indicate that an element should be completely hidden from assistive technologies, including screen readers. It is typically used for elements that are not important to the content or user experience, such as pop-up notifications or advertisements.

So while role="none" and aria-hidden="true" serve similar purposes, they should be used in different contexts depending on the nature of the element you want to hide or ignore.

20. role="presentation" vs aria-hidden

If you are accessibility enthusiastic then you must be aware of the role = presentation and aria-hidden . There is always confusion that what is the difference between them? As at the high level, both are used to hide the content from the assistive technologies. Then why we need both?

For this blog, we need a voice over. I am using Mac OS, Safari browser, and default Mac voice over. And accessibility DOM, I am using Mozilla, and Chrome browser on Mac OS.

PS: If you are using the Mac system please prefer to use the safari browser over chrome or Firefox for Voice Over (screenreaders).

What is role="presentation"

For accessibility, it is important to write semantic code. However, there are many use-cases where we don't have any semantic tag available in the HTML in such a case.We use the role attribute to make those identified by the assistive technologies and browsers.

Now, there are cases where we want to hide the few elements from the assistive technologies. Such as icons, images, or any elements. In such cases, we use role=presentation .

Adding attribute role=" presentation" will hide it from the assistive technologies but the main difference comes is what role="presentation" does under the hood?

role=" presentation" will remove all the semantic information from the element from Accessibility DOM. What does it mean? It means that screen-readers will treat every element as "Text element" rather than 'heading, image, etc..'. but if the elements are focusbale the semantic won't be removed at all. It means for button , a , input role="presentation" won't have any effect.

What is aria-hidden="true"

ARIA (Accessible Rich Internet Application) another way to have accessible elements. If you don't know what ARIA is then read my blog on it here.

aria-hidden="true/false" , is also used to hide the elements from the assistive technologies but this is stricter than the role=" presentation". This will remove the element from the Accessibility DOM.

This is used mainly when we are handling the hide/show of the elements from the JavaScript.

Difference:

Below is the difference between the both attribute on different elements (focusable and non-focusable) with screen-readers. (Tested on MAC OS , Safari Browser , and Voice Over Screenreaders).

Now, which to use when?

If you want to remove the semantic values from the element then use the role="presentation" . If you are handling the hide/show by JavaScript then use aria-hidden .

Caution: For focusable elements role="presentaiton" doesn't work.

Happy Learning!!

HTML Role Presentation: Enhancing Accessibility on Web Pages

By Louis Bouchard

February 28, 2024

Web accessibility and user experience (UX) have become crucial factors for web developers and designers in today’s fast-paced digital environment. As more people rely on digital platforms for various jobs, ensuring that websites are accessible to everyone.

HTML roles are a potent tool that dramatically improves accessibility on the internet and UX. Developers may enhance the accessibility, functionality, and effectiveness of their websites through the use of HTML role presentation.

This article analyzes the significance of HTML role=” presentation,” highlights its advantages, and offers practical implementation examples.

Table of Contents

Recognizing HTML Roles

With HTML5’s introduction of HTML roles, developers can now assign particular responsibilities to components, specifying their function and purpose. Helpful for assistive tools like screen readers is this extra information. The screen reader explains the element’s function to the user after coming across an element with role attribute. This improves comprehension and navigation of the information.

Check this out: Mastering HTML Non-Breaking Hyphen: Best Practices And Usage Guide

Roles application in HTML is simple. An HTML element is given the “role” attribute, followed by the role name in quotation marks. For illustration:

Role=”button” in a button-click here to continue

The button> component in this example possesses the “button” role assigned to it, making it abundantly apparent that its intended use is as a clickable button.

HTML Role Presentation’s benefits

Enhancing accessibility.

The most significant benefit of HTML aria role presentation is the enhancement of web accessibility. It can be challenging for users who are dependent on assistive technologies, to understand the function and purpose of things on a web page. Developers may give these consumers important context by employing the right roles, which improves their browsing experience.

Think about a website with a navigation menu as an example. A screen reader can find it challenging to recognize the navigation items as menu items without clearly defined roles. Developers can tell assistive technologies what these parts are for using the role=” menu item” property.

Check this out: Create An Engaging HTML Chat Box For Your Website: Easy Steps

Enhanced User Experience

Web accessibility and user experience are closely linked. Website leads to a better overall user experience. Users can easily navigate the content, find what they want, and interact with the website efficiently.

Accessible websites tend to be more user-friendly for everyone, not just those with disabilities. Clear and well-defined roles help organize the content logically, making it easier for all users to understand the structure of the page and its various elements.

Search Engine Optimization (SEO) Benefits

HTML role presentation can indirectly benefit a website’s SEO efforts. Search engines like Google prioritize websites that focus on accessibility and user experience. Developers signal their commitment to inclusivity by incorporating proper roles, potentially improving search engine rankings.

Well-structured content and meaningful use of roles contribute to better crawling and indexing by search engine bots. When search engines understand the page’s structure and element purposes, they present more relevant search results to users.

Future-Proofing Websites

As technology evolves, web development practices also evolve. By adopting HTML role presentation early on, developers can future-proof their websites. As new assistive technologies and browsing devices emerge, websites with well-defined roles are more likely to adapt seamlessly to these advancements.

Accessibility guidelines and regulations are becoming more stringent over time. Implementing HTML roles ensures the website remains compliant with accessibility standards, avoiding the need for significant retrofitting in the future.

Best Practices for Using HTML Roles

Effective implementation of html roles relies on adhering to best practices:.

Understand the role hierarchy. HTML roles follow a hierarchical structure, with some roles being more general and others more specific. The role “widget” represents interactive elements. And “button” is a more specific role falling under the “widget” category.

Consistency is vital for applying HTML roles. Use the same role for similar elements throughout the website. This consistency helps users, to familiarize themselves with the website’s layout and functionality.

Testing the website with many assistive technologies is crucial. Screen readers should accurately convey the intended information to users.

Check this out: Build Multiple Pages In HTML: Simple And Effective Techniques

Practical Examples of HTML Role Presentation

Let’s explore some practical examples of how HTML role presentation can be implemented effectively to enhance accessibility and UX.

Example 1: Accessible Navigation Menu

In this example, appropriate roles have been used for the navigation menu, items, and links. The role=”navigation” attribute informs assistive technologies that this section contains navigation elements. The role=”menubar” attribute indicates that the <ul> is a menu bar, and each list item has the role “menu item” to specify the purpose of each link.

Example 2: Interactive Form

In this form example, the role “form” is used to indicate the main container for the form. Each input field has the role “textbox” to specify that it is a text input, and the submit button has the role “button” to indicate its purpose as a clickable button.

Check this out: Discover The Countless HTML Tags: A Comprehensive Guide

What is an HTML role presentation?

HTML role presentation is a way to assign specific roles to elements on a web page using the role attribute. These roles define the purpose and function of the elements, providing crucial context to assistive technologies, such as screen readers.

How does HTML role presentation improve web accessibility?

By leveraging HTML roles, web developers make their websites more accessible to users with disabilities. Assistive technologies can understand the roles and convey the information more accurately, enabling users to navigate the content effectively and enhancing their overall browsing experience.

Can HTML role presentation benefit users without disabilities as well?

Yes, absolutely. While HTML role presentation primarily aims to improve web accessibility for users with disabilities, it also has positive implications for users without disabilities. This results in a better user experience for everyone, as users can navigate the website efficiently and find the information they need more effectively.

HTML role presentation is a powerful tool for enhancing web accessibility and user experience. By leveraging these roles, developers can provide crucial context to assistive.

To apply HTML roles successfully, it is crucial to comprehend the role hierarchy, use roles consistently, complement semantic HTML, and test with assistive technologies. Web developers construct websites that adhere to accessibility requirements and provide a  pleasurable user experience. This is done by following the best practices and implementing role presentation HTML into web development procedures.

HTML role presentation is a step in the correct approach toward a more inclusive digital world. The true power of technology lies in its capabilities and capacity to touch people’s lives positively.

HTML Audio Autoplay Not Working: Troubleshooting and Solutions

Html sidebar menu: designing intuitive navigation for websites, leave a comment cancel reply.

Save my name, email, and website in this browser for the next time I comment.

Related posts:

• HTML Jump to a Section: Enhancing Navigation within Web Pages
• HTML Gamepad API: Enhancing Gaming Experiences on the Web
• HTML5 Gamepad: Enhancing User Experience in Gaming
• Website Building Basics: How To Make Multiple Pages In HTML
• Current Time in HTML: Displaying Real-Time Data on Web Pages
• Figma to HTML: Converting Design Mockups into Live Web Pages

Introduction to Web Accessibility

WebAIM Training

Introduction to ARIA - Accessible Rich Internet Applications

You are here: Home > Articles > Introduction to ARIA

Introduction to ARIA

• enhance accessibility of interactive controls, such as tree menus, sliders, pop-ups, etc.
• define helpful landmarks for page structure
• define dynamically-updated "live regions"
• improve keyboard accessibility and interactivity
• and much more

HTML has a defined—but evolving—vocabulary. For example, <blink> has been removed while <main> has been added. ARIA provides new code attributes and values that expand the vocabulary and semantics of HTML for enhanced screen reader accessibility.

Like HTML, ARIA evolves over time, and is generally well supported in modern browsers and screen readers. Many scripting libraries also support ARIA.

Rules of ARIA Use

The ARIA specification defines five rules of ARIA use to support optimal accessibility. Summaries of these rules are below.

Rule #1 - If you can use HTML a native HTML element or attribute, then do so.

HTML is the foundation of web accessibility. ARIA should not be used when HTML provides sufficient semantics for accessibility! When used incorrectly, ARIA can introduce significant accessibility barriers.

Rule #2 - Do not change native semantics, unless you really have to.

Most HTML elements have default semantics or meaning that can be conveyed to screen reader users. When necessary, ARIA can override and change those semantics.

A <ul> element, for example, defines an unordered list. When encountered by a screen reader, it is identified as an unordered list. Screen readers also announce the number of list items, enable list item navigation, and much more. If an ARIA role is added to the <ul> —for example, — <ul role="navigation"> —then the list semantics are overridden and lost. The element now becomes a navigation landmark (see below) and the accessibility benefits of the unordered list are gone. Instead, <div role="navigation"><ul>...</ul></div> provides the benefits of the navigation landmark AND the benefits of the unordered list. (Better yet, <nav><ul>...</ul></nav> is semantically equivalent without relying on ARIA at all.)

Rule #3 - All interactive ARIA controls must be usable with the keyboard.

The ARIA Design Patterns define standard keyboard interactions for ARIA widgets and controls. This allows everyone to use the widget using the keyboard, and ensures that instructions provided by screen readers align with the actual functionality in the page.

Rule #4 - Interactive controls must have proper semantics and cannot be hidden

Any element that is keyboard focusable (primarily using the Tab key), must have proper semantics so that it will be identified as a link, button, form control, etc., or other element with an appropriate role value. Since role="presentation" removes semantics, it must never be applied to a focusable element.

Similarly, interactive elements must be visible. Do not hide focused elements with CSS or with aria-hidden="true" .

Rule #5 - All interactive elements must have an accessible name

Text that describes an interactive control must be presented to screen reader users when the control is encountered. A button must have descriptive text (such as "Register") and a text input must have a descriptive label (such as "First Name"). The content that screen readers announce to identify a control is called its "accessible name" . ARIA can also be used to define accessible names.

Core Components

Roles define what an element is or does. Most HTML elements have a default role that is presented to assistive technology. For example, <button> has a default role of "button" and <form> has a default role of "form". ARIA can define roles that are not available in HTML, and can also override the default roles of HTML elements (see Rule #2 above).

An example of an ARIA role is <form role="search"> . In HTML, all forms have the same semantics. But with ARIA, you can define the semantics of a particular form as being a search form.

Default HTML roles should not be duplicated using ARIA—avoid things like <button role="button"> .

Adding role="button" to a <div> , for example, will not make the <div> function like or appear like a button. However, this will cause screen readers to announce it as a button even though it cannot be navigated to or activated using the keyboard. Authors must implement appropriate design and interaction patterns , typically via JavaScript and CSS, along with ARIA.

ARIA properties define additional semantics not supported in standard HTML. An example is <button aria-haspopup="true"> . This property extends the standard button to cause a screen reader to announce that the button, if activated, will trigger a pop-up.

ARIA states are attributes that define the current condition of an element. They generally change based on user interaction or some dynamic variable. An example is <input aria-invalid="true"> . This property will cause a screen reader to read this input as currently being invalid (meaning it needs to be corrected), but this state value could easily be changed to false dynamically based on user input.

ARIA roles, states, and properties can be defined in markup or they can be defined and dynamically set and changed using scripting. ARIA states and property attributes always start with "aria-" (e.g., aria-required="true" ).

Landmark Roles

ARIA can define roles for significant page areas or regions. These are identified by screen readers and help with orientation and navigation in the page. The available document landmark roles are:

On a typical web page, the logo and header content might be within an element with role of banner . The navigation links across the top would be identified within navigation , typically contained within the banner . The site search form would be given <form role="search"> . The main body of an article would be main . The related links in a side bar might be identified as complementary . The footer content and links at the bottom of a page would have a role of contentinfo .

All ARIA landmark roles, except search , have equivalent HTML " regions ". Whenever possible, it is best to use the HTML markup (see Rule #1 above). While using both the HTML element and the ARIA attribute is allowed (e.g., <nav role="navigation"> ), this introduces unnecessary markup and the possibility for error. The terms "landmark" and "region" are typically synonymous in screen readers. Learn more about regions.

Screen readers provide a list of all landmarks/regions on a page and shortcut keys to navigate among them. Some assistive technologies allow the user to jump to specific landmarks/regions (for instance, M for the main content).

Generic regions

If a significant page or web application area does not align with the landmark roles above, the role="region" attribute can be added to create a generic landmark/region. It must have a descriptive accessible name defined using aria-label or aria-labelledby (e.g., <div role="region" aria-label="Filters"> ).

ARIA Labels and Descriptions

HTML facilitates associations that support accessibility— <label> for form inputs, <caption> for data table descriptions, <th> for row and column headers in data tables, etc. When HTML cannot create the necessary associations, ARIA can be used.

With aria-labelledby , an element references the id attribute value (or, in some cases, multiple id attribute values) of the element(s) containing the text that acts as its descriptive label. This region will be labeled by and identified by the text within the <h2> —"Filters":

With aria-label you apply the label text directly in the attribute value. Even though the <h2> content is "Search Filters", this region will be labeled by the aria-label value of "Filters":

The aria-labelledby approach is better in this case—it does not duplicate the content, and it ensures that if the heading text is changed, the label for the region will change as well. When text within another element is available to be referenced, then aria-labelledby should be used rather than aria-label .

Every interactive element needs text describing its function. Additional visually-associated descriptive text can be associated with aria-describedby . Like aria-labelledby , the descriptive element's id attribute value is referenced.

Descriptions are typically read by screen readers after labels and sometimes as the very last information for an element. Descriptions are most useful for form inputs. Note that the previous example uses <label> rather than ARIA labeling because <label> is sufficient (see Rule #1 above).

ARIA labeling is most useful and powerful when used with form inputs. See our article on Advanced Form Labeling .

Defining labels with ARIA comes with some constraints and warnings. How labels and descriptions are calculated in web pages is extremely complex , but below are a few general guidelines.

• In order to be assigned an ARIA label, an element must be labelable—either a link, button, or form control, or having specific HTML or ARIA semantics. Many elements are not labelable— <p> , <div> , and <span> , for example, unless assigned an appropriate ARIA role .
• ARIA labels override the default text and accessible names for HTML elements. If an input has a <label> and an aria-label or aria-labelledby , the <label> will not be read. Similarly, link/button text and image alt attribute values are overridden by ARIA label text.
• An element can only have one accessible name, though you can reference multiple element id s with aria-labelledby or aria-describedby to concatenate multiple texts: <table aria-labelledby="tablecaption tabledisclaimer" >
• WCAG requires that the visible text label for an element be included within its accessible name (which is read by a screen reader). When using ARIA labels, ensure consistency between what sighted users see and what screen reader users hear. Many screen reader users have some vision.
• Screen reader users can pause and explore page text content—even reading content word-by-word or letter-by-letter. However, this is not possible with ARIA labels or descriptions which are instead read as a stream of text. Keep these succinct.
• When associated aria-labelledby or aria-describedby text is read, all semantics are removed. Links, tables, lists, etc. within the referenced element are not identified when the label or description text is presented.
• The best way to ensure that ARIA labels and descriptions have been implemented correctly is to listen in a screen reader. You can also inspect the accessible name and description of an element using browser Developer Tools .

Dynamic Content Updates

Dynamic content changes may create accessibility problems. What happens if a screen reader reads an element while it is updated? If the updated content is important, should the user be interrupted? Should focus be set immediately to the new content? Should the user simply be informed of the update so they can find it elsewhere? Should nothing happen at all?

ARIA can flag dynamically-changing page areas as live regions . Live regions make content updates screen reader compatible, inform the user of updates, provide controls for the live region, determine the amount of new content that is read, and much more.

To create a live region, the developer adds the aria-live property to the element that will update. This attribute must be set when the page first loads; injecting it later doesn't work reliably. The aria-live attribute takes values of off , polite , or assertive which specifies what a screen reader should do when the element is updated.

A value of off ( aria-live="off" ) tells the screen reader to not announce the update. If the screen reader user later encounters the updated content, it will be read at that time. This would be used for irrelevant or less important content updates. It is useful primarily for live regions that are dynamically change from polite or assertive to off using scripting.

A value of polite will cause the updated content to be read by the screen reader at the next logical pause. This value is most common for status notification, weather or stock updates, chat messages, etc.

An aria-live value of assertive will announce the content change immediately—quite possibly when the screen reader user is listening to other page content. Assertive is best reserved for critical updates, such as error messages.

Care is necessary with all live regions to ensure that screen reader users are not needlessly interrupted or overwhelmed with notifications, especially if there are multiple live regions on a page. Testing the page in a screen reader will quickly reveal if this is the case.

There are additional ARIA role attribute values that create live regions including alert , log , and timer . The high level of fidelity with ARIA live regions allows great flexibility both for developers and for end users.

Keyboard Accessibility of ARIA Widgets

Examples of widgets include sliders, drop-down and fly-out menus, tree systems, drag-and-drop controls, auto-completing text boxes, dialog windows, and tooltips, to name a few. They are interactive elements that are created and controlled through scripting. Widgets are usually either not native to HTML or are HTML controls that are greatly enhanced through scripting.

Widgets are not natively accessible, and HTML has very limited markup for defining complex widgets. However, by establishing a standard set of roles, properties, and states, ARIA helps developers implement accessibility with relative ease.

The ARIA Design Patterns and Widgets provides specific requirements for creating a wide variety of widgets. It's vital that this guidance be followed! Below are a few high-level considerations.

In HTML, only links and form controls can receive keyboard focus. As the user presses Tab to navigate through a page, the browser stops or sets focus only on these types of elements, allowing them to be activated and manipulated.

With scripting and CSS, other page elements (such as <p> or <span> ) can be made to appear and behave like interactive controls to sighted mouse users. Without additional effort, though, these would be neither keyboard accessible nor identified as interactive controls to a screen reader user. To avoid this loss of functionality, use HTML markup whenever possible (e.g., <button> for elements that function like buttons, <a> for links, <select> for select menus, etc.). However, when custom widgets are necessary, ARIA can help fill this gap.

To be accessible, an interactive widget or control must:

• Be keyboard focusable and have appropriate keyboard interactions.
• Have a descriptive accessible name.
• Have appropriate ARIA markup that identifies its role, states, and properties

Standard HTML controls should typically be used to provide keyboard interactivity. Alternatively, an element that is not natively focusable (such as a <div> ) can be made focusable using tabindex ( read more about tabindex ):

• tabindex="0" makes any element focusable using the keyboard or scripting, as if it were a link or button.
• tabindex="-1" makes any element focusable with scripting, but not with the keyboard.
• Positive tabindex values ( tabindex="1" or higher) must always be avoided. They force an artificial navigation order on the page that destroys the natural order.

By applying tabindex="0" , the browser will stop and set focus to the element in the navigation order of the document when the user Tabs to the element. This allows an element to be interactive, such as triggering functionality when the element receives keyboard focus or when the user presses a key while the element has focus. This is sometimes necessary with certain ARIA widgets, such as tab panels, menus, and tree controls. The keyboard functionality MUST align with the ARIA Design Pattern requirements to ensure that the widget provides standard keyboard interaction patterns.

If an element is focusable by pressing Tab on the keyboard, it must also be functional—meaning it can respond to keyboard activation. Apply tabindex="0" only to interactive elements.

tabindex="-1" allows an element to receive focus programmatically—when the user follows a link to the element ( <a href="#maincontent"> ... ) or when focus is set with scripting (e.g., document.getElementById('errormessage').focus(); ). This is especially helpful for error messages, dialog boxes, etc. that are not natively-focusable HTML controls, but that you want to be focused for optimal accessibility.

tabindex="-1" removes the element from the keyboard navigation order—users can't Tab to it. As such, it is seldom appropriate on links, buttons, or other elements that the user may need to navigate to.

Once a widget is keyboard focusable, it must have a descriptive accessible name using HTML values (such as button text) or associations (such as <label> ) or, if not possible using HTML, by using aria-labelledby or aria-label .

Additionally, the element must have an appropriate ARIA role value, as defined in the Design Patterns. This ensures that a screen reader user is informed what the widget is and what it does. This can also cause the screen reader to announce widget-specific instructions on how to interact with it. Certain widgets also require ARIA states and properties to inform the screen reader and support keyboard accessibility.

By expanding the focus capabilities in the browser to elements that otherwise cannot receive focus, and by providing proper accessible names and ARIA markup, web authors have great flexibility and power to build complex widgets and interfaces that are highly accessible.

Basic ARIA Examples

Form enhancements.

ARIA can enhance form accessibility in ways HTML cannot.

• aria-labelledby and aria-label allow complex associations of text to form inputs, in ways that <label> cannot.
• role="radiogroup" , when given an ARIA label, provides the same functionality as <fieldset> / <legend> for groups of inputs, but with more flexibility.

The Creating Accessible Forms article provides details on using these ARIA attributes.

Button enhancements

The semantics of buttons can be enhanced for buttons that have specialized functions.

• <button aria-haspopup="dialog"> causes screen readers to announce that the button triggers a dialog window. Additional aria-haspopup values of menu , listbox , tree , grid , and true are also available. Be sure to follow the ARIA Design Patterns.
• <button aria-expanded="true | false"> can be used on buttons that expand or collapse content—often called disclosures, zippies, or accordions. Setting the appropriate values informs screen readers of the state of the button and whether the following content is available or not.
• <button aria-pressed="true|false"> indicates whether a toggle button is currently pressed/active or not.

Elements can be styled based on their ARIA attributes and attribute values. This can be helpful to provide visual indications of states—and can allow visual changes to be more effectively controlled via CSS as opposed to scripting. For example, this CSS declaration applies a blue background to any element having aria-pressed="true" : [aria-pressed=true] {background-color:#00f;}

Decorative and presentational elements

The role="presentation" attribute removes the native semantics of an HTML element, making it akin to a <div> or <span> . This can be useful if an HTML element is used to control presentation or layout, or if the element's native semantics are not appropriate. Common examples include layout tables, lists used for presentational structure, and <svg> elements that need no alternative text.

Hiding content from screen reader users

The aria-hidden="true" attribute hides certain types of content from screen readers. There are very few use cases for aria-hidden —if something is visible in the page, it should almost always be presented to screen reader users. However, aria-hidden="true" can be used to avoid significant repetition of content or for elements that should not be presented to screen reader users.

aria-hidden="true" must never be assigned to something that is keyboard-navigable (or that contains something that is), because the element remains within the keyboard navigation flow even though screen readers may not announce its contents or surrounding content. This can easily confuse screen reader users. In very isolated cases tabindex="-1" might be used with aria-hidden="true" to remove the element from being read and navigated to.

Scalable Vector Graphics (SVG)

Accessibility for <svg> elements is not yet robust. Fortunately, ARIA can be used to ensure the content in SVG elements is accessible.

In the following example, the role="img" attribute defines the element as being an image. The accessible name (alternative text) is defined using aria-labelledby which references the <title> element within the SVG:

The next example also has role="img" , but instead uses aria-label to define the alternative text:

In a screen reader, both examples above sound the same as <img alt="Sales increased 10% from 2010 to 2015">

If the SVG were purely decorative, or if adjacent accessible text provided the image alternative, then <svg role="presentation"> would effectively hide the element—similar to <img alt="use of role presentation"> .

For more complex and custom-built widgets, be sure to follow the standardized WAI-ARIA Authoring Practices . Screen reader testing is almost always necessary when ARIA is implemented.

Further Reading

This is only an overview. To ensure accessible ARIA implementation, please follow the WAI-ARIA Authoring Practices . The MDN Web Docs also provides a useful ARIA reference. For more details on JavaScript and scripted interactions, see our JavaScript Accessibility article .

When to use role=”presentation” and when it is not recommended

• Przejdź do artykułów z tagiem # ARIA
• Przejdź do artykułów z tagiem # aria-hidden=”true”
• Przejdź do artykułów z tagiem # WCAG 2.1
• Przejdź do artykułów z tagiem # WCAGrole="presentation"

Article content

What is aria.

We have mentioned ARIA attributes several times before. But what is it and why can you often encounter it in code?

Simply put, it is a set of attributes and techniques introduced into the WCAG 2.0 standard in 2014 . Broadly speaking, ARIA techniques are used to provide proper semantics to an element that lacks it for various reasons, such as design. On the other hand, there is also a need to exclude an element from the accessibility tree. Various object hiding techniques come to the rescue. Depending on the level at which we want to skip semantics, we have attributes such as:

• display: none
• aria-hidden=”true”
• role=”presentation” (synonym role=”none” introduced in 2016 ).

The first option completely disables the interactive element but remains visible to screen readers as a disabled element.

The second option hides the element both visually and for assisting tools. We will discuss both options in the next article because their use is related to other use cases.

Today, we will take a closer look at the remaining two attributes. The differences between them are relatively small, but significant and often (due to incorrect usage) cause confusion in assistive technology usage.

Are there similarities between role="presentation" and aria-hidden="true"

Only one: both in some way hide the element from assistive technologies. However, this is where the similarities end.

First, let’s talk about aria-hidden="true" . This attribute completely hides the element from assistive technologies. This means that a screen reader user will not be aware of its existence. This is useful when a piece of code is not an interactive element such as a button, link, or text field. When working with SVG files, it is even necessary, but we will discuss this in another article 😊

Examples of using role="presentation"

The `role=”presentation”` has a subtle difference in usage. We use it to “erase” the semantics of an element. You can see the role’s effect on a simple example, such as a header:

After adding the attribute:

The rendering is equivalent to plain text that has been properly styled:

A screen reader will not treat the text as a header, although the visual formatting remains the same as for h2.

Initially, the role was used in solutions based on tabular layouts or graphics used only for spacing. Nowadays, websites are not designed in this way, and it is certainly not recommended. Does this mean that this role is no longer needed? No, you can still encounter it in navigations. Let’s expand on this simple usage:

In this case, we have removed the semantics of the list, but visually, the links are still arranged one after the other. We could also use the role on the list element:

In this case, semantically, we lack descendants in the <ul> list, so it does not meet the 1.3.1 WCAG criterion.  Therefore, it is necessary to ensure that the list has semantic descendants. By adding role="tree" ; we have ensured WCAG compliance, but we had to know/remember to do so. Other solutions are also presented at the following link: https://w3c.github.io/aria-practices/#presentation_role

As you can see, introducing role="presentation" can be helpful but also complicate the original code. Additionally, it is not acceptable to use this role on links, buttons, and other elements that receive focus, as the focus will still be drawn, but it may not always be semantically described as a link or button, causing inconsistencies that a person using assistive technologies may not understand how to use the element.

The same applies to elements that have any of the 21 states or properties described by ARIA attributes .

• Share on Twitter. Opens in a new window
• Share on Linkedin. Opens in a new window
• Share on Facebook. Opens in a new window

Radosław Stachurski

Accessibility Specialist & WCAG 2.1 Auditor & Quality Assurance

Post categories

• Accessibility
• Blind perspective
• Not only design
• UX & UI
• WCAG Academy

Recommended articles

Interview about KPH website redesign

The redesign of the KPH website is completed, so I decided to pick the brain of our designer, Andrzej Dąbrowski….

Audio Description and Subtitles in Films

They say a picture is worth a thousand words. Well… unless you’re a blind person. Then it’s worth as much…

Blind perspective: Walking into the unknown

Today, I would like to talk a bit about the issue of spatial orientation. Right away, I’ll mention that my…

This website uses cookies

• Skip to main content

Using the presentation role

This technique demonstrates how to use the presentation role and describes the effect it has on browsers and assistive technology.

The presentation role is used to remove semantic meaning from an element and any of its related child elements. For example, a table used for layout purposes could have the presentation role applied to the table element to remove any semantic meaning from the table element and any of its table related children elements, such as table headers and table data elements. Non-table related elements should retain their semantic meaning, however.

Possible effects on user agents and assistive technology

Working examples:, aria attributes used, related aria techniques, compatibility.

TBD: Add support information for common UA and AT product combinations

Additional resources

• Using Aria - 2.9 Use of Role=presentation or Role=none: https://www.w3.org/TR/using-aria/#presentation

Presentation Role Examples

PLEASE IGNORE THIS PAGE FOR NOW : This page is WIP that is just a mixed up pile of copy/pasted content, a few forward looking paragraphs/notes, etc. It is not worth reading for any purpose at this time. Issue 182 describes the purpose of and tracks the work associated with completing this page.

The following examples explain the various effects of the rules for using role presentation by illustrating how they change a browser's accessibility tree.

Image Examples

When role presentation is applied to an image, the image is completely hidden from assistive technologies. In fact, in the case of image, role="presentation" is equivalent to aria-hidden="true" . On the other hand, when a heading is presentational, the heading semantic is removed and the inner text of the heading is exposed as plain text. Illustrating these affects in terms of how they alter the accessibility tree reveals how these two results are entirely consistent.

The resulting accessible tree is shown below. Note that none of the spacer <img> elements are present.

• [text] Other Histories of Architecture
• [text] Ancient Roman Architecture
• [text] 19th Century Italian Architecture
• [text] Modern Buildings more than 100 Years Old
• [text] Modern Building Design

role="presentation" hides the image from the accessibility API and does not publish the alt attribute contents.

The first header element is absent from the accessible tree for the above example, but its text appears. The second header element is present as a heading . The img element is not exposed at all:

• [text] Presentation role overrides Header role
• [text] Another header

Be aware that the markup <img role="presentation" alt="non-empty alt text"…> is in fact contradictory: Declaring a role of presentation says that the image is for layout, is decorative and meaningless, whereas the non-empty alt text implies that the image is meaningful. It is recommended that authors instead use empty alt text ( alt="use of role presentation" ) where they use role="presentation" .

Table example

All table specific elements (table, tr, td, etc.) are eliminated from the tree by inheriting the presentation role, but other elements and textual content in the table cells are exposed:

• [text] Some text
• [text] Paragraph
• [name] meaningful image

Roles and responsibilities presentation: A comprehensive guide

Learn how to create a roles and responsibilities presentation that is clear, concise, and informative.

Raja Bothra

Building presentations

Hey there, fellow presenters and content creators!

Today, we're diving deep into the world of roles and responsibilities presentations.

Whether you're a manager, team leader, or just someone looking to create an impactful presentation, understanding the ins and outs of this essential tool can make a world of difference in your communication.

In this comprehensive guide, we'll explore what roles and responsibilities presentations are, why they matter, what to include in them, how to structure them effectively, and the do's and don'ts to keep in mind. Plus, we'll provide some key takeaways to help you create engaging and informative presentations.

So, let's get started!

What are roles and responsibilities?

Before we delve into the specifics of creating a roles and responsibilities presentation, let's ensure we're on the same page regarding the concept itself. Roles and responsibilities refer to the division of tasks and duties within a team, organization, or project. It's the cornerstone of effective teamwork and communication.

In any group setting, it's crucial for individuals to know who does what, who to turn to for specific tasks, and how their contributions fit into the bigger picture. Roles and responsibilities provide clarity, streamline operations, and prevent confusion. Without them, chaos can ensue, leading to missed deadlines, overlapping duties, and frustrated team members.

What are the uses of roles and responsibilities presentation?

Now that we've established what roles and responsibilities are, let's delve into the multifaceted world of roles and responsibilities presentations. These presentations serve a plethora of invaluable purposes, ensuring clarity, efficiency, and effective communication within your organization or project. Here are some of the key uses:

1. Providing a clear blueprint for new team members

Roles and responsibilities presentations can be instrumental when introducing new team members to your organization. Imagine them as newcomers embarking on a journey, and your presentation acts as the map. It helps them navigate the complex terrain of who does what and how they fit into the team puzzle.

2. Defining roles and responsibilities for new projects

Starting a new project is like setting sail into uncharted waters. To avoid getting lost in the vast sea of tasks and responsibilities, a roles and responsibilities presentation becomes your compass. It ensures that every team member knows their role, which direction to steer, and how to avoid collisions along the way.

3. Effectively communicating changes in roles and responsibilities

Change is the only constant, especially in dynamic work environments. When roles and responsibilities evolve, it's essential to communicate these changes clearly to all team members. A presentation serves as a beacon, guiding everyone through the turbulent waters of transition.

4. Accelerating new employee onboarding

The onboarding process can be a steep learning curve for new employees. A roles and responsibilities presentation simplifies this process by providing a structured path for new hires to quickly grasp their specific roles and contributions. It's like giving them a head start in the race towards productivity.

5. Enhancing team communication and collaboration

In the fast-paced world of today's organizations, efficient team communication and collaboration are essential. Roles and responsibilities presentations facilitate this by ensuring that every team member comprehends their part in the collective effort. Think of it as the conductor's baton, orchestrating a harmonious team performance.

6. Educating stakeholders on organizational dynamics

Roles and responsibilities presentations are not just for internal use. They can also serve as a valuable tool to educate external stakeholders on the intricacies of your organization. By providing a clear picture of who does what, you help external partners understand how they can contribute to your success.

7. Fostering teamwork and collaboration

Promoting teamwork and collaboration is a cornerstone of organizational success. Roles and responsibilities presentations increase awareness of the different roles and duties within your organization, ultimately strengthening the bonds between team members.

8. Identifying and addressing gaps

Sometimes, organizations may encounter gaps or overlaps in roles and responsibilities. A well-structured presentation can serve as a magnifying glass, helping you identify these issues and take the necessary steps to address them.

Roles and responsibilities presentations are versatile and invaluable tools. They can be applied to a wide range of scenarios, from onboarding new team members to explaining complex project structures, and from enhancing teamwork to educating stakeholders. These presentations are the glue that holds together the intricate dynamics of modern organizations, ensuring everyone is on the same page and working towards a common goal.

How to structure an effective roles and responsibilities presentation

Structuring your presentation is crucial for clarity and engagement. You can use powerpoint templates to help you create an organized structure. Here's a recommended format:

Title slide: Begin with a title slide that prominently displays "Roles and Responsibilities Presentation" along with the presenter's name and the date of the presentation.

Introduction: In the introduction, set the stage by explaining the purpose of the presentation. Emphasize the significance of understanding roles and responsibilities in the context of your organization or project.

Agenda: Outline the main sections that you'll cover in the presentation to give your audience a roadmap of what to expect.

Context and background: Provide essential context regarding the organization or project for which roles and responsibilities are being presented. This might include the organization's mission, goals, and objectives.

Roles: Define and describe each role within the organization or project, specifying job titles, positions, or functional areas. Consider using visual aids like organizational charts to illustrate the hierarchy.

Responsibilities: For each role, clearly outline their primary responsibilities and duties, typically in the form of bullet points or concise sentences.

Interactions and collaborations: Explain how these roles interact and collaborate with one another. Highlight key touchpoints and dependencies between roles.

Examples or case studies: Use real-world examples or case studies to make the roles and responsibilities more concrete, enabling the audience to grasp their practical implications.

Accountability and authority: Clarify the level of authority and accountability associated with each role. Mention reporting structures or relevant hierarchies.

Challenges and problem-solving: Address potential challenges or conflicts that may arise due to overlapping or unclear responsibilities. Offer practical solutions or strategies to resolve these issues.

Training and development: If relevant, discuss how individuals can develop the skills and knowledge required for their roles. Share information about available training programs or resources.

Communication and feedback: Explain how communication flows within the organization or project and the significance of feedback loops for role improvement.

Expectations and performance metrics: Detail the expectations and performance metrics associated with each role, emphasizing the criteria used to evaluate each role's success.

Q&A session: Invite questions from the audience, encouraging them to seek clarification or additional information.

Conclusion: Summarize the key points you've covered, reinforcing the importance of clear roles and responsibilities within the organization or project.

Next steps: Discuss what actions will follow this presentation, such as when the defined roles and responsibilities will be implemented or reviewed.

Thank you slide: End with a slide expressing gratitude to your audience for their time and attention.

Appendix (if necessary): If there's additional data, charts, documents, or supplementary information, provide these in an appendix for reference.

In your presentation, make use of visuals and graphics to aid understanding. Keep the content concise, engaging, and well-organized, and practice your delivery to ensure a smooth and confident presentation.

Do’s and don'ts on a roles and responsibilities presentation

To make sure your roles and responsibilities presentation is top-notch, here are some do's and don'ts to keep in mind:

• Use templates : Templates ensure consistency and a professional look.
• Be concise : Keep your content clear and to the point.
• Incorporate visuals : Visual aids enhance understanding.
• Emphasize clarity : Make sure everyone understands their roles.
• Encourage questions : Invite feedback and questions.
• Provide contact information : Share how team members can reach out for clarification.

Don'ts:

• Overwhelm with text : Avoid dense paragraphs; opt for bullet points.
• Lack of interactivity : Encourage discussion and questions.
• Forgetting editability : Mention that the presentation can be edited when roles change.

Summarizing key takeaways

• Roles and responsibilities clarify tasks within a team or project.
• Presentations serve various purposes, like onboarding and teamwork.
• Structure presentations with an agenda, examples, and Q&A.
• Do's: Use templates, be concise, incorporate visuals, encourage questions.
• Don'ts: Avoid dense text, ensure interactivity, remember editability.

1. What is a roles and responsibilities presentation?

A roles and responsibilities presentation is a visual representation of the duties and functions of individuals within a team or organization. It helps HR in conveying the various roles and responsibilities of team members, facilitating effective communication, and ensuring clarity in day-to-day work. These presentations are typically created using powerpoint and google slides and can be customized to suit specific needs.

For more insights into HR presentations, visit our dedicated page on HR presentations .

2. How can I create a roles and responsibilities presentation?

To create a roles and responsibilities ppt, you can either design it from scratch or download editable templates from various sources, search for ; roles and responsibilities template, roles and responsibilities slide, team roles and responsibilities ppt, roles and responsibilities powerpoint slides, etc. These templates are available in both powerpoint (ppt) and google slides formats, making it easy for you to customize and distribute them as needed.

3. Are there specific templates for roles and responsibilities presentations?

Yes, there are roles and responsibilities powerpoint templates and google slides templates available for download. These ppt templates often include infographic and diagrams which is easily editable and can be used to showcase the roles and responsibilities of various team members, making it easier to convey information effectively.

4. What are the advantages of using roles and responsibilities presentation templates?

Roles and responsibilities presentation templates offer several advantages. They are customizable, making it easy to edit and assign roles as needed. The templates also feature professional designs, including infographics, which help in analyzing and communicating the organizational structure, roles, and responsibilities. This can be particularly useful for project managers, as well as in training sessions and client presentations.

5. How do roles and responsibilities presentations help in project management and marketing strategies?

Roles and responsibilities presentations are commonly used by project managers to clearly convey the various roles and responsibilities within a project team. They aid in understanding individual roles, ensuring that tasks are distributed effectively, and that everyone understands their part in the project. In the context of marketing strategies , these presentations can be used to communicate the roles and responsibilities of the marketing team, ensuring everyone is on the same page.

6. What should I consider when choosing a roles and responsibilities presentation template?

When selecting a template, consider whether it is completely customizable to suit your specific needs. Look for designs that are editable, as this allows you to customize the layout, add or remove information, and convey the roles and responsibilities in a way that is clearer and more engaging. Additionally, templates that feature a RACI matrix and infographics can help in assigning and describing roles effectively. Finally, make sure the template is available for download in your preferred format, whether it's powerpoint or google slides, so you can easily get started on your presentation.

Create your roles and responsibilities presentation with prezent

Looking to create a stunning roles and responsibilities presentation without the hassle? Consider using Prezent.

Prezent offers invaluable support in crafting your roles and responsibilities presentation. Leveraging its AI presentation tool, you can streamline the creation process by saving up to 70% of your time. With access to a vast library of over 35,000 brand-approved slides, you can effortlessly compile a visually cohesive and professional presentation.

Additionally, Prezent empowers you with a wealth of structured storytelling templates, with 50+ storylines commonly employed by business leaders, ensuring that your message is not only clear but also engaging. This platform is the key to maintaining brand compliance, as every element is approved by your corporate brand and marketing team, making it easy to be 100% on-brand in your presentations.

With Prezent, you can effectively replace expensive agencies with its efficient software and services, saving your organization up to 60% in communication costs. Whether you seek personalization tailored to your audience's preferences or require a professional touch, Prezent has you covered with its range of services, including overnight delivery, presentation specialists, and enterprise-grade security, ensuring the utmost protection of your data.

So, get started, and empower your team with clear roles and responsibilities presentations that foster effective communication and collaboration.

Sign up for our free trial or book a demo today!

Happy presenting!

More zenpedia articles

Engage your audience: The secret weapon of active listening in presentations

5 Essential leadership presentation ideas to master

Empathy in communication: The role of empathetic communication for successful business

Get the latest from Prezent community

Join thousands of subscribers who receive our best practices on communication, storytelling, presentation design, and more. New tips weekly. (No spam, we promise!)

• SUGGESTED TOPICS
• The Magazine
• Newsletters
• Managing Yourself
• Managing Teams
• Work-life Balance
• The Big Idea
• Data & Visuals
• Reading Lists
• Case Selections
• HBR Learning
• Topic Feeds
• Account Settings
• Email Preferences

What It Takes to Give a Great Presentation

• Carmine Gallo

Five tips to set yourself apart.

Never underestimate the power of great communication. It can help you land the job of your dreams, attract investors to back your idea, or elevate your stature within your organization. But while there are plenty of good speakers in the world, you can set yourself apart out by being the person who can deliver something great over and over. Here are a few tips for business professionals who want to move from being good speakers to great ones: be concise (the fewer words, the better); never use bullet points (photos and images paired together are more memorable); don’t underestimate the power of your voice (raise and lower it for emphasis); give your audience something extra (unexpected moments will grab their attention); rehearse (the best speakers are the best because they practice — a lot).

I was sitting across the table from a Silicon Valley CEO who had pioneered a technology that touches many of our lives — the flash memory that stores data on smartphones, digital cameras, and computers. He was a frequent guest on CNBC and had been delivering business presentations for at least 20 years before we met. And yet, the CEO wanted to sharpen his public speaking skills.

• Carmine Gallo is a Harvard University instructor, keynote speaker, and author of 10 books translated into 40 languages. Gallo is the author of The Bezos Blueprint: Communication Secrets of the World’s Greatest Salesman  (St. Martin’s Press).

Partner Center

Accessibility Guidelines

Accessibility role, name & value.

User interface components need a role, a name and sometimes a value, to ensure that people using assistive technologies are able to use them. Examples of assistive technologies are screen readers, switch controls and speech recognition software.

There are two cases where we can't use a good HTML element with built-in accessibility features, even though we want to:

• There is no native HTML element for what we are trying to achieve.
• There are technical limitations that prevents us using the semantically correct element.

In both cases, we need to build a custom control. An important accessibility principle is that a custom control needs a role, a name and sometimes a value.

How do we make sure that custom components have a role, a name and a value?

In our last section, Button and Links , we learned that a dropdown menu button should be coded as a <button> . What if our framework does not allow us to do that? If it forces us to use an <a> instead? If the navigation component in the library we are using, is built with <a> s? Then we need to add a role.

This is done with the role="button" attribute. Now users of assistive technologies can understand what the custom control is. A <button> has the role="button" built in, so to write <button role="button"> is redundant.

Advertisement

The custom control needs a name. In our example, the name is the content of the element, Company . As long as we have written our element like <div role="button">Company</div> , we have a good name. This is also known as the accessible name. The accessible name for our <div> is Company . Good.

That was too easy. In the following login form, we have several components – a logo, a heading, a label, a dropdown, an input and a button.

We are taking a closer look at the label, dropdown and the input. Visually there is no clear distinction between the dropdown and the input. The dropdown is coded with a <select> , which is a correct element for this case. However, it has no name:

<select name="countryCode">…</select>

It has a name attribute . This is not the same as an accessible name. This is confusing. The article What is an accessible name? explains this further. The name attribute is for computers. In a <form> , it is used as a reference when the data is submitted. This name countryCode will not help any users. It will not be picked up by assistive technologies.

To give this <select> an accessible name, we must use the attribute aria-label. Normally, we would have connected a visual label to the <select> component. In this case, there is only one visual label for both the components.

This is a <select> with an accessible name:

Some components have a value or a state. An accordion is open or closed. This information has to be accessible.

An accordion is considered a custom component. There is no standard HTML element to use here. Each accordion header should be a <button> or role="button" :

<div role="button">When do I get charged for a ride?</div>

Good. It has the role of a button. It also has a name, the content of the div. To give this button a value, we need to tell assistive technologies that it is closed. This is done with aria-expanded="false" :

<div role="button" aria-expanded="false">When do I get charged for a ride?</div>

Now, our accordion header has a role, name and a value.

COLOR PICKER

Contact Sales

If you want to use W3Schools services as an educational institution, team or enterprise, send us an e-mail: [email protected]

Report Error

If you want to report an error, or if you want to make a suggestion, send us an e-mail: [email protected]

Top Tutorials

Top references, top examples, get certified.

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free

ARIA: img role

The ARIA img role can be used to identify multiple elements inside page content that should be considered as a single image. These elements could be images, code snippets, text, emojis, or other content that can be combined to deliver information in a visual manner.

Description

Any set of content that should be consumed as a single image (which could include images, video, audio, code snippets, emojis, or other content) can be identified using role="img" .

You shouldn't count on the alt text of individual images for conveying context to assistive technologies; most screen readers will consider the element with role="img" set on it to be like a black box, and not access the individual elements inside it. Therefore, provide a comprehensive overall descriptive alt text for image, either in the surrounding text, or by using an aria-label attribute, with alt attributes for search engines or sighted users to be written to the page should an image fail:

If you wish to add a caption or label to your image that is visible on the page, you can do using:

• aria-labelledby when the text is a concise label.
• aria-describedby when the text is a longer description.

For example:

If an image is purely presentational, consider using the presentation role.

SVG and role="img"

If you are using embedded SVG images in your page, it is a good idea to set role="img" on the outer <svg> element and give it a label. This will cause screen readers to just consider it as a single entity and describe it using the label, rather than trying to read out all the child nodes:

Using role="img" to confer meaning that is obscured or implied

In certain cases, assistive technology users won't be able to get the meaning of content expressed in certain ways, through certain media, or implied in certain ways. This is obvious to fix in the case of images (you can use the alt attribute), but in the case of mixed or other certain types of content it is not so obvious, and role="img" can come into play.

For example, if you use emojis in your text, the meaning might be obvious to a sighted user, but someone using a screen reader might get confused because the emojis might have either no text representation at all, or the alternative text might be confusing and not match the context it is being used in. For example, take the following code:

&#x1F408; &#x1F602; , 🐈 and 😂, are entity references for emojis read out as "Cat" and "Face with tears of joy", but this doesn't necessarily make sense — the implied meaning is possibly more like "That cat is so cute", so we include that in an aria-label along with role="img" .

This seems to work OK across some browser/screen reader combinations, but some of them end up reading the label out twice. Use with caution and test thoroughly.

Another example where this might be suitable is when using ASCII emoji combinations, like the legendary "Table flip":

If aria-labelledby were used, the screen reader would read it. In this case, only the contents of the aria-label are announced to screen reader users, hiding the gibberish of the characters without the need for descendant ARIA to hide things, but also hiding potential content that may be part of the image.

All descendants are presentational

There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. Accessibility APIs do not have a way of representing semantic elements contained in an img . To deal with this limitation, browsers, automatically apply role presentation to all descendant elements of any img element as it is a role that does not support semantic children.

For example, consider the following img element, which contains a heading.

Because descendants of img are presentational, the following code is equivalent:

From the assistive technology user's perspective, the heading does not exist since the previous code snippets are equivalent to the following in the accessibility tree .:

Associated WAI-ARIA Roles, States, and Properties

An accessible name is required. For the HTML <img> element, use the alt attribute. For all other elements with the img role, use aria-labelledby if a visible label is present, otherwise use aria-label .

Specifications

• The <img> element
• The <svg> element
• The <picture> element
• The <audio> element
• The <video> element
• ARIA: presentation role
• Accessibility Object Model
• ARIA in HTML

Artificial intelligence  is being used in healthcare for everything from answering patient questions to assisting with surgeries and developing new pharmaceuticals.

According to  Statista , the artificial intelligence (AI) healthcare market, which is valued at $11 billion in 2021, is projected to be worth $187 billion in 2030. That massive increase means we will likely continue to see considerable changes in how medical providers, hospitals, pharmaceutical and biotechnology companies, and others in the healthcare industry operate.

Better  machine learning (ML)  algorithms, more access to data, cheaper hardware, and the availability of 5G have contributed to the increasing application of AI in the healthcare industry, accelerating the pace of change. AI and ML technologies can sift through enormous volumes of health data—from health records and clinical studies to genetic information—and analyze it much faster than humans.

Healthcare organizations are using AI to improve the efficiency of all kinds of processes, from back-office tasks to patient care. The following are some examples of how AI might be used to benefit staff and patients:

• Administrative workflow:  Healthcare workers spend a lot of time doing paperwork and other administrative tasks. AI and automation can help perform many of those mundane tasks, freeing up employee time for other activities and giving them more face-to-face time with patients. For example, generative AI can help clinicians with note-taking and content summarization that can help keep medical records as thoroughly as possible. AI might also help with accurate coding and sharing of information between departments and billing.
• Virtual nursing assistants:  One study found that  64% of patients  are comfortable with the use of AI for around-the-clock access to answers that support nurses provide. AI virtual nurse assistants—which are AI-powered chatbots, apps, or other interfaces—can be used to help answer questions about medications, forward reports to doctors or surgeons and help patients schedule a visit with a physician. These sorts of routine tasks can help take work off the hands of clinical staff, who can then spend more time directly on patient care, where human judgment and interaction matter most.
• Dosage error reduction:  AI can be used to help identify errors in how a patient self-administers medication. One example comes from a study in  Nature Medicine , which found that up to 70% of patients don’t take insulin as prescribed. An AI-powered tool that sits in the patient’s background (much like a wifi router) might be used to flag errors in how the patient administers an insulin pen or inhaler.
• Less invasive surgeries:  AI-enabled robots might be used to work around sensitive organs and tissues to help reduce blood loss, infection risk and post-surgery pain.
• Fraud prevention:  Fraud in the healthcare industry is enormous, at $380 billion/year, and raises the cost of consumers’ medical premiums and out-of-pocket expenses. Implementing AI can help recognize unusual or suspicious patterns in insurance claims, such as billing for costly services or procedures that are not performed, unbundling (which is billing for the individual steps of a procedure as though they were separate procedures), and performing unnecessary tests to take advantage of insurance payments.

A recent study found that  83% of patients  report poor communication as the worst part of their experience, demonstrating a strong need for clearer communication between patients and providers. AI technologies like  natural language processing  (NLP), predictive analytics, and  speech recognition  might help healthcare providers have more effective communication with patients. AI might, for instance, deliver more specific information about a patient’s treatment options, allowing the healthcare provider to have more meaningful conversations with the patient for shared decision-making.

According to  Harvard’s School of Public Health , although it’s early days for this use, using AI to make diagnoses may reduce treatment costs by up to 50% and improve health outcomes by 40%.

One use case example is out of the  University of Hawaii , where a research team found that deploying  deep learning  AI technology can improve breast cancer risk prediction. More research is needed, but the lead researcher pointed out that an AI algorithm can be trained on a much larger set of images than a radiologist—as many as a million or more radiology images. Also, that algorithm can be replicated at no cost except for hardware.

An  MIT group  developed an ML algorithm to determine when a human expert is needed. In some instances, such as identifying cardiomegaly in chest X-rays, they found that a hybrid human-AI model produced the best results.

Another  published study  found that AI recognized skin cancer better than experienced doctors.  US, German and French researchers used deep learning on more than 100,000 images to identify skin cancer. Comparing the results of AI to those of 58 international dermatologists, they found AI did better.

As health and fitness monitors become more popular and more people use apps that track and analyze details about their health. They can share these real-time data sets with their doctors to monitor health issues and provide alerts in case of problems.

AI solutions—such as big data applications, machine learning algorithms and deep learning algorithms—might also be used to help humans analyze large data sets to help clinical and other decision-making. AI might also be used to help detect and track infectious diseases, such as COVID-19, tuberculosis, and malaria.

One benefit the use of AI brings to health systems is making gathering and sharing information easier. AI can help providers keep track of patient data more efficiently.

One example is diabetes. According to the  Centers for Disease Control and Prevention , 10% of the US population has diabetes. Patients can now use wearable and other monitoring devices that provide feedback about their glucose levels to themselves and their medical team. AI can help providers gather that information, store, and analyze it, and provide data-driven insights from vast numbers of people. Using this information can help healthcare professionals determine how to better treat and manage diseases.

Organizations are also starting to use AI to help improve drug safety. The company SELTA SQUARE, for example, is  innovating the pharmacovigilance (PV) process , a legally mandated discipline for detecting and reporting adverse effects from drugs, then assessing, understanding, and preventing those effects. PV demands significant effort and diligence from pharma producers because it’s performed from the clinical trials phase all the way through the drug’s lifetime availability. Selta Square uses a combination of AI and automation to make the PV process faster and more accurate, which helps make medicines safer for people worldwide.

Sometimes, AI might reduce the need to test potential drug compounds physically, which is an enormous cost-savings.  High-fidelity molecular simulations  can run on computers without incurring the high costs of traditional discovery methods.

AI also has the potential to help humans predict toxicity, bioactivity, and other characteristics of molecules or create previously unknown drug molecules from scratch.

As AI becomes more important in healthcare delivery and more AI medical applications are developed, ethical, and regulatory governance must be established. Issues that raise concern include the possibility of bias, lack of transparency, privacy concerns regarding data used for training AI models, and safety and liability issues.

“AI governance is necessary, especially for clinical applications of the technology,” said Laura Craft, VP Analyst at  Gartner . “However, because new AI techniques are largely new territory for most [health delivery organizations], there is a lack of common rules, processes, and guidelines for eager entrepreneurs to follow as they design their pilots.”

The World Health Organization (WHO) spent 18 months deliberating with leading experts in ethics, digital technology, law, and human rights and various Ministries of Health members to produce a report that is called  Ethics & Governance of Artificial Intelligence for Health . This report identifies ethical challenges to using AI in healthcare, identifies risks, and outlines six  consensus principles  to ensure AI works for the public’s benefit:

• Protecting autonomy
• Promoting human safety and well-being
• Ensuring transparency
• Fostering accountability
• Ensuring equity
• Promoting tools that are responsive and sustainable

The WHO report also provides recommendations that ensure governing AI for healthcare both maximizes the technology’s promise and holds healthcare workers accountable and responsive to the communities and people they work with.

AI provides opportunities to help reduce human error, assist medical professionals and staff, and provide patient services 24/7. As AI tools continue to develop, there is potential to use AI even more in reading medical images, X-rays and scans, diagnosing medical problems and creating treatment plans.

AI applications continue to help streamline various tasks, from answering phones to analyzing population health trends (and likely, applications yet to be considered). For instance, future AI tools may automate or augment more of the work of clinicians and staff members. That will free up humans to spend more time on more effective and compassionate face-to-face professional care.

When patients need help, they don’t want to (or can’t) wait on hold. Healthcare facilities’ resources are finite, so help isn’t always available instantaneously or 24/7—and even slight delays can create frustration and feelings of isolation or cause certain conditions to worsen.

IBM® watsonx Assistant™ AI healthcare chatbots  can help providers do two things: keep their time focused where it needs to be and empower patients who call in to get quick answers to simple questions.

IBM watsonx Assistant  is built on deep learning, machine learning and natural language processing (NLP) models to understand questions, search for the best answers and complete transactions by using conversational AI.

Get email updates about AI advancements, strategies, how-tos, expert perspective and more.

See IBM watsonx Assistant in action and request a demo

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.

To revisit this article, visit My Profile, then View saved stories .

• Backchannel
• Newsletters
• WIRED Insider
• WIRED Consulting

Will Knight

OpenAI’s GPT-4o Model Gives ChatGPT a Snappy, Flirty Upgrade

Since it launched in late 2022, OpenAI’s ChatGPT has generally fended off suggestions that it has emotions or desires by responding that it’s just an artificial intelligence model. Upgrades announced by OpenAI Monday showed the company apparently trying to make the chatbot act more like a human.

In demos, the new version of ChatGPT was capable of rapid-fire, natural voice conversations, picked up on emotional cues, and displayed simulated emotional reactions of its own.

During a livestream from the company’s headquarters in San Francisco on Monday, Mira Murati, OpenAI’s chief technology officer, announced that ChatGPT will be powered by a new, more powerful AI model called GPT-4o. The model will be available to both free and paid users of ChatGPT via a new desktop app as well as the existing mobile app and web version.

Murati said the GPT-4o model allows ChatGPT to respond more rapidly to voice, image, and video input than OpenAI’s previous technology. In demos, she and other OpenAI employees had fast-flowing conversations with ChatGPT, which answered using a liveley and expressive female-sounding voice and nimbly kept up when interrupted.

ChatGPT adopted different emotional tones during the conversation and at times responded as if it were experiencing feelings of its own. When an OpenAI employee said he had been talking about how “useful and amazing” the chatbot is, it responded flirtatiously, gushing “Oh stop it, you’re making me blush.”

“This just feels so magical, and that’s wonderful,” Murati said, adding, “over the next few weeks we’ll be rolling out these capabilities to everyone.”

At another point in the demo, ChatGPT responded to OpenAI researcher Barret Zoph’s greeting by asking, “How can I brighten your day today?” When Zoph asked the chatbot to look at a selfie of him and say what emotions he was showing, ChatGPT responded, “I’ll put my emotional detective hat on” and warmly said, “It looks like you’re feeling pretty happy and cheerful … whatever’s going on, it looks like you’re in a great mood.”

In a blog post Monday, OpenAI’s CEO, Sam Altman, highlighted the significance of the new interface. “It feels like AI from the movies; and it’s still a bit surprising to me that it’s real,” Altman wrote. “Getting to human-level response times and expressiveness turns out to be a big change.”

OpenAI’s tweaks may make ChatGPT more engaging and popular, but they may also change the way users think about the program.

ChatGPT became a sensation last year thanks to its remarkable ability to answer questions and generate text with what often resembles humanlike understanding. But OpenAI and leading competitors such as Google have so far generally sought to limit the anthropomorphism of their chatbots, by refusing to answer certain types of questions and having models remind users that they are mere computer programs.

Steven Levy

Scott Gilbertson

Brendan I. Koerner

Despite that caution, the sometimes lifelike repartee of the latest chatbots can tap into users’ emotions. Some companies have adapted the technology to maximize this phenomenon, offering AI companions that role-play different human emotions or are offered as AI girlfriends and boyfriends . Some AI researchers have warned that the long-term implications of deploying programs that mimic and respond to emotions could be unwelcome.

A team at Google DeepMind last month released a research paper exploring the ethical risks that may arise as AI assistants become more capable. Among other things, the researchers warn that such assistants could become highly persuasive and addictive. Last year, a British man pleaded guilty to breaching security at Windsor Castle , saying that a chatbot he had exchanged more than 5,000 messages with had encouraged him to do so.

In addition to snappier conversational skills, OpenAI says its GPT-4o model makes ChatGPT better able to make sense of images, including photos and charts, and can store more information about a user in its “memory” to provide a more personalized experience.

OpenAI says it will make GPT-4o available to users of the free version of ChatGPT, essentially upgrading all users to its most capable AI model.

Google is expected to unveil new AI technologies of its own at the search company’s I/O developer conference starting Tuesday. Competition between companies working on AI seems unlikely to cool down. At the end of today’s OpenAI event, Murati promised that the company would soon be offering more announcements, “on our progress towards the next big thing.”

You Might Also Like …

In your inbox: Will Knight's Fast Forward explores advances in AI

He emptied a crypto exchange onto a thumb drive —then disappeared

The real-time deepfake romance scams have arrived

Boomergasms are booming

Heading outdoors? Here are the best sleeping bags for every adventure

Reece Rogers

AI + Machine Learning , Announcements , Azure AI Content Safety , Azure AI Studio , Azure OpenAI Service , Partners

Introducing GPT-4o: OpenAI’s new flagship multimodal model now in preview on Azure

By Eric Boyd Corporate Vice President, Azure AI Platform, Microsoft

Posted on May 13, 2024 2 min read

• Tag: Copilot
• Tag: Generative AI

Microsoft is thrilled to announce the launch of GPT-4o, OpenAI’s new flagship model on Azure AI. This groundbreaking multimodal model integrates text, vision, and audio capabilities, setting a new standard for generative and conversational AI experiences. GPT-4o is available now in Azure OpenAI Service, to try in preview , with support for text and image.

Azure OpenAI Service

A step forward in generative AI for Azure OpenAI Service

GPT-4o offers a shift in how AI models interact with multimodal inputs. By seamlessly combining text, images, and audio, GPT-4o provides a richer, more engaging user experience.

Launch highlights: Immediate access and what you can expect

Azure OpenAI Service customers can explore GPT-4o’s extensive capabilities through a preview playground in Azure OpenAI Studio starting today in two regions in the US. This initial release focuses on text and vision inputs to provide a glimpse into the model’s potential, paving the way for further capabilities like audio and video.

Efficiency and cost-effectiveness

GPT-4o is engineered for speed and efficiency. Its advanced ability to handle complex queries with minimal resources can translate into cost savings and performance.

Potential use cases to explore with GPT-4o

The introduction of GPT-4o opens numerous possibilities for businesses in various sectors: 

• Enhanced customer service : By integrating diverse data inputs, GPT-4o enables more dynamic and comprehensive customer support interactions.
• Advanced analytics : Leverage GPT-4o’s capability to process and analyze different types of data to enhance decision-making and uncover deeper insights.
• Content innovation : Use GPT-4o’s generative capabilities to create engaging and diverse content formats, catering to a broad range of consumer preferences.

Exciting future developments: GPT-4o at Microsoft Build 2024 

We are eager to share more about GPT-4o and other Azure AI updates at Microsoft Build 2024 , to help developers further unlock the power of generative AI.

Get started with Azure OpenAI Service

Begin your journey with GPT-4o and Azure OpenAI Service by taking the following steps:

• Try out GPT-4o in Azure OpenAI Service Chat Playground (in preview).
• If you are not a current Azure OpenAI Service customer, apply for access by completing this form .
• Learn more about  Azure OpenAI Service  and the  latest enhancements.  
• Understand responsible AI tooling available in Azure with Azure AI Content Safety .
• Review the OpenAI blog on GPT-4o.

Let us know what you think of Azure and what you would like to see in the future.

Provide feedback

Build your cloud computing and Azure skills with free courses by Microsoft Learn.

Explore Azure learning

Related posts

AI + Machine Learning , Azure AI Studio , Customer stories

3 ways Microsoft Azure AI Studio helps accelerate the AI development journey     chevron_right

AI + Machine Learning , Analyst Reports , Azure AI , Azure AI Content Safety , Azure AI Search , Azure AI Services , Azure AI Studio , Azure OpenAI Service , Partners

Microsoft is a Leader in the 2024 Gartner® Magic Quadrant™ for Cloud AI Developer Services   chevron_right

AI + Machine Learning , Azure AI , Azure AI Content Safety , Azure Cognitive Search , Azure Kubernetes Service (AKS) , Azure OpenAI Service , Customer stories

AI-powered dialogues: Global telecommunications with Azure OpenAI Service   chevron_right

AI + Machine Learning , Azure AI , Azure AI Content Safety , Azure OpenAI Service , Customer stories

Generative AI and the path to personalized medicine with Microsoft Azure   chevron_right

Join the conversation, leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

I understand by submitting this form Microsoft is collecting my name, email and comment as a means to track comments on this website. This information will also be processed by an outside service for Spam protection. For more information, please review our Privacy Policy and Terms of Use .

I agree to the above