role presentation js

• 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

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.

W3C  (opens new window) Paciello  (opens new window)

Explore More on Digital Accessibility Insights

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.

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.

Notify me of follow-up comments by email.

Notify me of new posts by email.

• Español – América Latina
• Português – Brasil
• Tiếng Việt
• Accessibility

ARIA and HTML

Most developers are familiar with the standard markup language of our modern web, HyperText Markup Language (HTML) . However, you may be less familiar with Accessible Rich Internet Applications (ARIA) (formally called WAI-ARIA): what it is, how it is used, and when—and when not —to use it.

HTML and ARIA play important roles in making digital products accessible, especially when it comes to assistive technology (AT) such as screen readers. Both are used to convert content into an alternate format, such as Braille or Text-to-Speech (TTS).

Let's review a short history of ARIA, why it is important, and when and how best to use it.

Introduction to ARIA

ARIA was first developed in 2008 by the Web Accessibility Initiative (WAI) group—a subset of the overarching World Wide Web Consortium (W3C), which governs and regulates the internet.

ARIA is not a true programming language but a set of attributes you can add to HTML elements to increase their accessibility. These attributes communicate role, state, and property to assistive technologies via accessibility APIs found in modern browsers. This communication happens through the accessibility tree.

" WAI-ARIA , the Accessible Rich Internet Applications Suite, defines a way to make web content and web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with HTML, JavaScript, and related technologies." The WAI group

The accessibility tree

ARIA modifies incorrect or incomplete code to create a better experience for those using AT by changing, exposing, and augmenting parts of the accessibility tree.

The accessibility tree is created by the browser and based on the standard Document Object Model (DOM) tree. Like the DOM tree, the accessibility tree contains objects representing all the markup elements, attributes, and text nodes. The accessibility tree is also used by platform-specific accessibility APIs to provide a representation that assistive technologies can understand.

ARIA on its own doesn't change an element's functionality or visual appearance. That means only AT users will notice differences between a digital product with ARIA and one without it. That also means that developers alone are responsible for making the appropriate code and styling changes to make an element as accessible as possible.

The three main features of ARIA are roles, properties, and states/values.

Roles define what an element is or does on the page or app.

Properties express characteristics or relationships to an object.

States/values define the current conditions or data values associated with the element.

While all three elements of ARIA can be used in one line of code, it's not required. Instead, layer ARIA roles, properties, and states/values until you've accomplished your final accessibility goal. Correctly incorporating ARIA into your code base ensures that AT users will have all the information they need to use your website, app, or other digital product successfully and equitably.

Recently, Chrome DevTools has created a way to see the full accessibility tree making it easier for developers to understand how their code impacts accessibility.

When to use ARIA

In 2014, the W3C officially published the HTML5 recommendation. With it came some big changes, including the addition of landmark elements such as <main> , <header> , <footer> , <aside> , <nav> , and attributes like hidden and required . With these new HTML5 elements and attributes, coupled with increased browser support, certain parts of ARIA are now less critical.

When the browser supports an HTML tag with an implicit role with an ARIA equivalent, there is usually no need to add ARIA to the element. However, ARIA still includes many roles, states, and properties that aren't available in any version of HTML. Those attributes remain useful for now.

This brings us to the ultimate question: When should you use ARIA? Thankfully the WAI group has developed the five rules of ARIA to help you decide how to make elements accessible.

Rule 1: Don't use ARIA

Yes, you read that right. Adding ARIA to an element does not inherently make it more accessible. The WebAIM Million annual accessibility report found that home pages with ARIA present averaged 70% more detected errors than those without ARIA, primarily due to the improper implementation of the ARIA attributes.

There are exceptions to this rule. ARIA is required when an HTML element doesn't have accessibility support. This could be because the design doesn't allow for a specific HTML element or the wanted feature/behavior isn't available in HTML. However, these situations should be scarce.

When in doubt, use semantic HTML elements .

Rule 2: Don't add (unnecessary) ARIA to HTML

In most circumstances, HTML elements work well out of the box and do not need additional ARIA added to them. In fact, developers using ARIA often have to add additional code to make the elements functional in the case of interactive elements.

Do less work and have better-performing code when you use HTML elements as intended.

Rule 3: Always support keyboard navigation

All interactive (not disabled) ARIA controls must be keyboard accessible. You can add tabindex= "0" to any element that needs a focus that doesn't normally receive keyboard focus. Avoid using tab indexes with positive integers whenever possible to prevent potential keyboard focus order issues.

Rule 4: Don't hide focusable elements

Don't add role= "presentation" or aria-hidden= "true" to elements that need to have focus—including elements with a tabindex= "0" . When you add these roles/states to elements, it sends a message to the AT that these elements are not important and to skip over them. This can lead to confusion or disrupt users attempting to interact with an element.

Rule 5: Use accessible names for interactive elements

The purpose of an interactive element needs to be conveyed to a user before they know how to interact with it. Ensure that all elements have an accessible name for people using AT devices.

Accessible names can be the content surrounded by an element (in the case of an <a> ), alternative text, or a label.

For each of the following code samples, the accessible name is "Red leather boots."

There are many ways to check an element's accessible name, including inspecting the accessibility tree using Chrome DevTools or testing it with a screen reader.

ARIA in HTML

While using HTML elements on their own is best practice, ARIA elements can be added in certain situations. For example, you may pair ARIA with HTML in patterns that need a higher level of AT support because of environmental constraints or as a fall-back method for HTML elements that aren't fully supported by all browsers.

Of course, there are recommendations for implementing ARIA in HTML . Most importantly: don't override default HTML roles, reduce redundancy, and be aware of unintended side effects.

Let's look at some examples.

Complexities of ARIA

ARIA is complex, and you should always use caution when using it. While the code examples in this lesson are fairly straightforward, creating accessible custom patterns can quickly get complicated.

There are many things to pay attention to, including but not limited to: keyboard interactions, touch interfaces, AT/browser support, translation needs, environmental constraints, legacy code, and user preferences. A little bit of coding knowledge can be detrimental—or just plain annoying—if used incorrectly. Remember to keep your code simple.

Those warnings aside, digital accessibility is not an all-or-nothing situation—it's a spectrum that allows for some gray areas like this. Multiple coding solutions can be seen as "correct," depending on the situation. What is important is that you keep learning, testing, and trying to make our digital world more open to all.

Check your understanding

Test your knowledge of ARIA and HTML

Which of the following is the best practice for building an accessible button?

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2022-09-30 UTC.

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

Report Error

If you want to report an error, or if you want to make a suggestion, do not hesitate to send us an e-mail:

[email protected]

Top Tutorials

Top references, top examples, get certified.

The HTML Presentation Framework

Created by Hakim El Hattab and contributors

Hello There

reveal.js enables you to create beautiful interactive slide decks using HTML. This presentation will show you examples of what it can do.

Vertical Slides

Slides can be nested inside of each other.

Use the Space key to navigate through all slides.

Basement Level 1

Nested slides are useful for adding additional detail underneath a high level horizontal slide.

Basement Level 2

That's it, time to go back up.

Not a coder? Not a problem. There's a fully-featured visual editor for authoring these, try it out at https://slides.com .

Pretty Code

Code syntax highlighting courtesy of highlight.js .

Even Prettier Animations

Point of view.

Press ESC to enter the slide overview.

Hold down the alt key ( ctrl in Linux) and click on any element to zoom towards it using zoom.js . Click again to zoom back out.

(NOTE: Use ctrl + click in Linux.)

Auto-Animate

Automatically animate matching elements across slides with Auto-Animate .

Touch Optimized

Presentations look great on touch devices, like mobile phones and tablets. Simply swipe through your slides.

Add the r-fit-text class to auto-size text

Hit the next arrow...

... to step through ...

... a fragmented slide.

Fragment Styles

There's different types of fragments, like:

fade-right, up, down, left

fade-in-then-out

fade-in-then-semi-out

Highlight red blue green

Transition Styles

You can select from different transitions, like: None - Fade - Slide - Convex - Concave - Zoom

Slide Backgrounds

Set data-background="#dddddd" on a slide to change the background color. All CSS color formats are supported.

Image Backgrounds

Tiled backgrounds, video backgrounds, ... and gifs, background transitions.

Different background transitions are available via the backgroundTransition option. This one's called "zoom".

You can override background transitions per-slide.

Iframe Backgrounds

Since reveal.js runs on the web, you can easily embed other web content. Try interacting with the page in the background.

Marvelous List

• No order here

Fantastic Ordered List

• One is smaller than...
• Two is smaller than...

Tabular Tables

Clever quotes.

These guys come in two forms, inline: The nice thing about standards is that there are so many to choose from and block:

“For years there has been a theory that millions of monkeys typing at random on millions of typewriters would reproduce the entire works of Shakespeare. The Internet has proven this theory to be untrue.”

Intergalactic Interconnections

You can link between slides internally, like this .

Speaker View

There's a speaker view . It includes a timer, preview of the upcoming slide as well as your speaker notes.

Press the S key to try it out.

Export to PDF

Presentations can be exported to PDF , here's an example:

Global State

Set data-state="something" on a slide and "something" will be added as a class to the document element when the slide is open. This lets you apply broader style changes, like switching the page background.

State Events

Additionally custom events can be triggered on a per slide basis by binding to the data-state name.

Take a Moment

Press B or . on your keyboard to pause the presentation. This is helpful when you're on stage and want to take distracting slides off the screen.

• Right-to-left support
• Extensive JavaScript API
• Auto-progression
• Parallax backgrounds
• Custom keyboard bindings

- Try the online editor - Source code & documentation

Create Stunning Presentations on the Web

reveal.js is an open source HTML presentation framework. It's a tool that enables anyone with a web browser to create fully-featured and beautiful presentations for free.

Presentations made with reveal.js are built on open web technologies. That means anything you can do on the web, you can do in your presentation. Change styles with CSS, include an external web page using an <iframe> or add your own custom behavior using our JavaScript API .

The framework comes with a broad range of features including nested slides , Markdown support , Auto-Animate , PDF export , speaker notes , LaTeX support and syntax highlighted code .

Ready to Get Started?

It only takes a minute to get set up. Learn how to create your first presentation in the installation instructions !

Online Editor

If you want the benefits of reveal.js without having to write HTML or Markdown try https://slides.com . It's a fully-featured visual editor and platform for reveal.js, by the same creator.

Supporting reveal.js

This project was started and is maintained by @hakimel with the help of many contributions from the community . The best way to support the project is to become a paying member of Slides.com —the reveal.js presentation platform that Hakim is building.

Slides.com — the reveal.js presentation editor.

Become a reveal.js pro in the official video course.

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="role presentation js" ) 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

Top 9 JavaScript frameworks to create beautiful presentation slides

Presentation frameworks are tools or libraries that can help you create presentations using web technologies that you are familiar with, such as HTML, CSS, JavaScript, Markdown, Vue, React, and more. You’ll have full control over the appearance and layout of your slides.

They allow you to export your slides as HTML files that can be viewed in any modern browser. You don’t need to install any software or plugin to view your slides. You can also share your slides online using platforms such as Slides.com, GitHub Pages, Netlify.

Reveal ( 64.2k ⭐) — An open source HTML presentation framework that allows you to create beautiful and interactive presentations using web technologies. You can use HTML, CSS, JavaScript, Markdown, LaTeX, and more to create stunning slides with animations, transitions, code highlighting, and other features.

Impress ( 37.3k ⭐) — Another open source HTML presentation framework that is similar to reveal.js, but with a different approach, inspired by the idea behind prezi.com. It uses CSS3 3D transforms to create dynamic and spatial presentations that can zoom, rotate, and pan across the slides.

Sli dev ( 27.3k ⭐) — A web-based slides maker and presenter that is designed for developers. It allows you to create beautiful and interactive presentations using Markdown, HTML, Vue components, and other web technologies. You can also use features such as live coding, recording, drawing, LaTeX, diagrams, icons, and more to enhance your slides.

MDX Deck ( 11.1k ⭐) — A library based on MDX that allows you to create presentations using Markdown and React components. You can write your slides in a single MDX file and separate them with --- . You can also import and use any React component in your slides, as well as customize the theme and layout of your presentation.

Spectacle ( 9.5k ⭐) — A React-based library for creating sleek presentations using JSX syntax that gives you the ability to live demo your code, created and maintained by Formidable Labs. You can use it to create beautiful and interactive slides with animations, transitions, code highlighting, and other features.

Code Surfer ( 6.2k ⭐) — A library that allows you to create presentations using Markdown and React components. You can write your slides in a single MDX file and separate them with --- , add code highlighting, code zooming, code scrolling, code focusing, code morphing, and fun to MDX Deck slides.

WebSlides ( 6.1k ⭐) — A library that allows you to create beautiful HTML presentations and websites. Just choose a demo and customize it in minutes. 120+ slides ready to use. You can use HTML, CSS, JavaScript, Markdown, LaTeX, and more to create stunning slides with animations, transitions, code highlighting, and other features.

Fusuma ( 5.3k ⭐) — A tool that allows you to create slides with Markdown easily. You can use HTML, CSS, JavaScript, Markdown, Vue components, and other web technologies to create stunning slides with animations, transitions, code highlighting, and other features.

PptxGenJS ( 2.1k ⭐) — A JavaScript library that allows you to create presentations, compatible with PowerPoint, Keynote, and other applications that support the Open Office XML (OOXML) format. You can use it to generate PPTX files with just a few simple JavaScript commands in any modern desktop and mobile browser. You can also integrate PptxGenJS with Node, Angular, React, and Electron.

Common features

Presentation frameworks typically share several common features that aim to enhance the creation and delivery of visually engaging and interactive presentations. Here are some of the common features you can find:

Ease of use : They allow you to use web technologies that you are familiar with, such as HTML, CSS, JavaScript, Markdown, Vue, React, and more. You don’t need to learn a new software or tool to create your slides. You can also use your favorite code editor or IDE to write and edit your slides.

Nested slides : They allow you to create sub-sections or sub-topics within your presentation. You can use nested slides to organize your content, add more details, or create interactive menus.

Markdown support : Markdown is a lightweight markup language that allows you to format text using simple syntax. You can use Markdown to write your slides in a plain text editor and then convert them to HTML. Markdown makes it easy to create headings, lists, links, images, code blocks, and more.

Auto-Animate : A feature that automatically animates the transitions between slides or elements to create smooth and dynamic effects for your presentation, detect the changes between slides and animate them accordingly.

PDF export : You can use PDF export to print your presentation, share it online, or view it offline. PDF export can also preserve the layout, fonts, and images of your presentation.

Speaker notes : You can use speaker notes to prepare your speech, add additional information, or provide references. Speaker notes are usually hidden from the audience but visible to you in a separate window or screen.

LaTeX support : LaTeX is a document preparation system that allows you to create high-quality typesetting for mathematical and scientific expressions. You can use LaTeX to write complex formulas, equations, symbols, and diagrams in your presentation. LaTeX can also handle cross-references, citations, and bibliographies.

Syntax highlighted code : You can use syntax highlighted code to display your source code in your presentation. Syntax highlighted code can make your code more readable, understandable, and attractive.

Who is Kato Kaelin? The Milwaukee native played a high-profile role in O.J. Simpson trial

Milwaukee native Brian "Kato" Kaelin, a Milwaukee native who became one of the most distinguishable personalities enmeshed in the landmark O.J. Simpson murder trial of 1994-95, became a household name to many across the state and country.

Simpson, who was acquitted of the charges of killing his ex-wife, Nicole Brown Simpson, and Ronald Goldman, died Wednesday at age 76.

Here's what to know about Kaelin, who was a witness in one of the biggest trials in American history:

Kato Kaelin was born in Milwaukee and attended Nicolet High School

Kaelin played multiple sports at Nicolet in Glendale, just north of Milwaukee. After graduating from Nicolet, he attended the University of Wisconsin-Eau Claire for two years as a speech major. According to an Associated Press article in 1995, his nickname stems from "The Green Hornet," which featured a limousine driver named Kato. Older brother Mark had an affinity for the television program and used the nickname to describe many of the six siblings in the house, but the nickname stuck to Brian.

Kaelin, an aspiring actor, had moved to Los Angeles at the time of the killings and was staying in a guest house on Simpson's Rockingham estate; he bore witness to some of Simpson's movements the night of June 12, 1994.

Kato Kaelin gave testimony at the Simpson trial, but was declared a hostile witness

Kaelin was with Simpson before and after the time it's believed Brown Simpson and Goldman were murdered. Some of his testimony contradicted Simpson's timeline of the night's events.

Kaelin befriended OJ and Nicole Simpson and was staying in their guest home, sometimes taking care of the couple's children for a reduction in rent. When Brown Simpson moved out of the home, Kaelin stayed and helped take care of the property, though Kaelin was often painted as a freeloader.

Kaelin testified he was with Simpson from about 9:15 to 9:45 p.m. June 12 on a run to McDonald's after Simpson was excluded from a family gathering at Mezzaluna restaurant following his daughter's dance recital. Kaelin didn't see Simpson again until Simpson left in a limousine for the airport at 11 p.m. The murders were believed to take place between 10 and 11 p.m. Goldman, a waiter at Mezzaluna, was returning a pair of glasses left by someone in the family party when he was killed.

Kaelin said he also heard a thumping sound outside his guest house around 10:40 p.m. and, while on the grounds looking for the source, opened the gate for limousine driver Allan Park, who was scheduled to give Simpson a ride to the airport at 10:45 p.m. but didn't get an answer from the house on an intercom.

More: I idolized O.J. Simpson as a kid. Later, I thought he got away with murder.

Park said he saw a 6-foot, 200-pound Black person enter the home, followed by a voice sounding like Simpson's on the intercom, indicating he had overslept and would be down shortly. Both Kaelin and Park testified Simpson wanted to personally load a dark duffle bag or knapsack into the limousine, refusing help from Kaelin.

But Kaelin also contradicted his own testimony at times and was categorized by the prosecution as a "hostile witness, " an unusual maneuver that allowed district attorney Marcia Clark to ask leading questions, much like a cross examination, on her own witness.

Kaelin's offbeat personality — and perhaps his flowing blonde hair — brought him to a strange brand of celebrity during the televised trial. Though the fame didn't lead to major acting roles, he has since made a number of TV appearances, most recently on "Celebrity Big Brother" in 2019 and an installment of the "Sharknado" franchise in 2018.

Kato Kaelin has said in recent years he believes Simpson was guilty

Kaelin has said in the intervening years that he believes Simpson indeed killed Brown and Goldman , even though he doesn't have firsthand knowledge.

In a heartfelt statement he posted to Instagram after Simpson's death, Kaelin offered sympathy to Simpson's children and expressed "love and compassion" for members of the Goldman family as well as the family of Nicole, "a beacon of light that burned bright."

His Wisconsin sports fandom has continued, and it's a wild journey

Kaelin's fandom of Milwaukee sports teams can be categorized as … passionate.

His messages posted to Twitter often illustrate the high-intensity emotion of sports fandom. Take this recent subset of examples:

Kaelin regularly attends Wisconsin sporting events both inside the state and when they come to California. He even won the 50/50 raffle at American Family Field in 2017.

• 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

Researchers identify new genetic risk factors for persistent HPV infections

First genome wide association study finds variants linked to susceptibility of cervical cancer-causing virus.

Human papillomavirus (HPV) is the second most common cancer-causing virus, accounting for 690,000 cervical and other cancers each year worldwide. While the immune system usually clears HPV infections, those that persist can lead to cancer, and a new finding suggests that certain women may have a genetic susceptibility for persistent or frequent HPV infections. These genetic variants, identified in a study led by University of Maryland School of Medicine researchers, could raise a woman's risk of getting cervical cancer from a high-risk HPV infection.

Findings were recently published in The European Journal of Human Genetics .

The research team conducted a genome-wide association study of high-risk HPV infections in a cohort of over 10,000 women, whose data were collected as part of the African Collaborative Center for Microbiome and Genomics Research (ACCME) cohort study. A total of 903 of the participants had high-risk HPV infections when the study began, with 224 participants having HPV infections that resolved, and 679 having persistent HPV infections. More than 9,800 HPV-negative women from the ACCME study served as controls.

"We found certain genetic variants were associated with having high-risk HPV infections, while other variants and human leukocyte antigen (HLA) genes were associated with persistent infections, which increase the risk of developing cervical cancer," said study leader Sally N. Adebamowo, MBBS, MSc, ScD, Associate Professor of Epidemiology & Public Health at UMSOM. "This is a critical finding that suggests genetic underpinnings for cervical cancer risk. It is the first sufficiently powered genome-wide association study of cervical high-risk HPV infections. Our polygenic risk score models should be evaluated in other populations."

Specifically, she and her colleagues found that the top variant associated with prevalent high-risk HPV infection was rs116471799, on the fourth chromosome near the LDB2 gene, which encodes for proteins. They found persistent HPV was associated with variants clustered around the TPTE2, a protein encoding gene associated with gallbladder cancer. The genes SMAD2 and CDH12 were also associated with persistent high risk HPV infections, and significant polygenic risk scores. Together the findings enabled the research team to develop polygenic risk scores to determine the likelihood that a certain genetic profile would increase the risk of having prevalent or persistent HPV infections.

"Our findings can be used for risk stratification of persistent high-risk HPV infections for precision or personalized cervical cancer prevention. We hope to conduct long-term studies on the integration of PRS and genomic risk factors into the continuum of cervical cancer prevention," said study corresponding author Clement A. Adebamowo, BM, ChB, ScD, Professor of Epidemiology & Public Health at UMSOM.

A recent report from the American Cancer Society found that cervical cancer among women ages 30 to 44 rose almost 2 percent a year from 2012 to 2019. This is after a big decline in cervical cancer rates over the past half-century due to early detection from Pap smears and HPV screening tests. In addition, rates of cervical cancer, have steadily declined among younger women who were among the first to benefit from HPV vaccines, which were approved for use in 2006.

In the U.S., more than half of women diagnosed with cervical cancer have never been screened or were not screened in the last five years, according to the Centers for Disease Control and Prevention. In Nigeria, only a small percentage of women have access to the HPV vaccine, so those included in the study were largely unvaccinated.

"The results provide insight into the role of antigen processing and presentation, and HLA-DRB1 alleles in immune surveillance and persistence of high-risk HPV infections," said Mark T. Gladwin, MD, who is the John Z. and Akiko K. Bowers Distinguished Professor and Dean, UMSOM, and Vice President for Medical Affairs, University of Maryland, Baltimore. "Confirmatory studies are crucial to validate these important findings in other populations, with the goal of reducing the burden of high-risk HPV related diseases on global health."

Study co-authors included those from: the National Human Genome Research Institute in Bethesda, MD; Asokoro District Hospital in Abuja, Nigeria; Federal Medical Center in Keffi, Nigeria; Wuse General Hospital in Abuja, Nigeria; University College Hospital, University of Ibadan, Ibadan, Nigeria; Institute of Human Virology Nigeria, Abuja, Nigeria; Garki Hospital Abuja, Abuja, Nigeria; University of Abuja Teaching Hospital, Gwagwalada, Abuja, Nigeria; National Hospital Abuja, Abuja, Nigeria; Kubwa General Hospital, Abuja, Nigeria.

This work was supported by the African Collaborative Center for Microbiome and Genomics Research Grant (NIH/NHGRI 1U54HG006947), UM-Capacity Development for Research in AIDS Associated Malignancy Grant (NIH/NCI 1D43CA153792-01), and Polygenic Risk Score (PRS) Methods and Analysis for Populations of Diverse Ancestry -- Study Sites (NIH/NHGRI 1U01HG011717).

• Cervical Cancer
• Women's Health
• Breast Cancer
• Men's Health
• Endangered Plants
• HPV vaccine
• Cervical cancer
• Plantar wart
• Breast cancer
• Immune system
• Colorectal cancer

Story Source:

Materials provided by University of Maryland School of Medicine . Note: Content may be edited for style and length.

Journal Reference :

• Sally N. Adebamowo, Adebowale Adeyemo, Amos Adebayo, Peter Achara, Bunmi Alabi, Rasheed A. Bakare, Ayotunde O. Famooto, Kayode Obende, Richard Offiong, Olayinka Olaniyan, Sanni Ologun, Charles Rotimi, Saurayya S. Abdullahi, Maryam Abdulsalam, Ruxton Adebiyi, Victor Adekanmbi, Bukunmi Adelekun, Segun Adeyemo, Gerald Akabueze, Bernice Akpobome, Stella Akpomiemie, Gabriel O. Alabi, Chinyere Anichebe, Claire Anyanwu, Miriam C. Ayogu, Dorcas J. Bako, Patience Bamisaiye, Nkechi U. Blessing, Osa A. Chinye, Patrick Dakum, Eileen Dareng, Grace Dwana, Juliet I. Erhunmwonsere, Emelda O. Eze, Tolani A. Fagbohun, Temitope Filade, Toluwalope Gbolahan, Gloria C. Anaedobe, Stella Ibezim, Racheal Iwaloye, Jesse James, Dayo Kehinde, Fiyinfoluwa Makinde, Jessica Mase, Charles Mensah, Florence A. Nwoko, Kayode Obende, George Odonye, Folake Odubore, Funmi Odunyemi, Michael Odutola, Uzoamaka Oguama, Tochukwu Oguoma, Temitayo Oladimeji, Toyosi Olawande, Temitope Olukomogbon, Sefunmi Oluwole, Gladys Omenuko, Nkiruka Onwuka, Yinka Owoade, Thelma C. Ugorji, Syntyche Yohanna, Ibrahim Yusuf, Clement A. Adebamowo. Genome, HLA and polygenic risk score analyses for prevalent and persistent cervical human papillomavirus (HPV) infections . European Journal of Human Genetics , 2024; DOI: 10.1038/s41431-023-01521-7

Cite This Page :

Explore More

• Genes for Strong Muscles: Healthy Long Life
• Brightest Gamma-Ray Burst
• Stellar Winds of Three Sun-Like Stars Detected
• Fences Causing Genetic Problems for Mammals
• Ozone Removes Mating Barriers Between Fly ...
• Parkinson's: New Theory On Origins and Spread
• Clash of Stars Solves Stellar Mystery
• Secure Quantum Computing at Home
• Ocean Currents: Collapse of Antarctic Ice ...
• Pacific Cities Much Older Than Previously ...

Trending Topics

Strange & offbeat.