Main content




  • String

Used in Roles:

  • All elements of the base markup (Global)
  • No role required


  • token
    • off (default): Updates to the region will not be presented to the user unless the assistive technology is currently focused on that region.
    • polite: (Background change) Assistive technologies should announce updates at the next graceful opportunity, such as at the end of speaking the current sentence or when the user pauses typing.
    • assertive: This information has the highest priority and assistive technologies should notify the user immediately. Because an interruption may disorient users or cause them to not complete their current task, authors should not use the assertive value unless the interruption is imperative.

Sets or retrieves how assistive technology announces updates to live regions.

Web 2.0, unlike the traditional static web pages, modern websites have dynamic, auto-updating content. Websites which shows the scores of live matches, stocks that update very often, online news websites showing the headlines fall in this category.

Only a small portion of the website is updated frequently. The entire page is not refreshed. The region that is updated according to the change is called as the live region.

aria-live is used when such live regions are available on the web page. Assistive technologies such as screen readers recognize the updated content with the aria-live property of the live region.

The changes of the live region is intimated to the user depending on the politeness levels. The politeness of the live region decides how the updated information should be intimated to the user. 


This is the default behavior. No changes in the live region is intimated to the user when aria-live is set to "off". aria-live="off" is used when the changes are expected very frequently and such information is not necessary to intimate to the user. However, the changes are announced to the user if the current focus of the screen reader is on the updating content.

Eg: GPS coordinates of a moving vehicle.


This politeness level is used when the user is not doing anything or when the user is waiting for the update to happen. If the user is busy with other tasks on the page, the screen reader will not interrupt to provide the updated content of the live region.

Eg: Changes of the headlines in the news website.


Assertive is used when the user should be intimated about the updated information when the live region is changed. The update is provided to the user, interrupting the current task. Use aria-live="assertive" when you think the user needs to know the information the very second it appears. To say in other words, high priority updates will be marked as aria-live="assertive".

Eg: Validations of the form fields on the fly.


aria-live="rude" is used for most critical updates. It forces the user to read the updated region as immediately as the update happens.

How do Screen readers catch aria-live

  • aria-live="off" is supported by all major screen readers. Working perfectly with NVDA on Firefox, JAWS on Firefox and Internet Explorer, Voiceover on IOS.
  • aria-live="polite" is supported by all major screen readers. Working perfectly with NVDA on Firefox, JAWS on Firefox and Internet Explorer, Voiceover on IOS.
  • aria-live="assertive" is working as expected only with voiceover on IOS. NVDA and JAWS is not interrupting with the updated content if the user is in any other task.
  • aria-live="rude" is working as expected with JAWS on Firefox and Internet Explorer but not with NVDA and voiceover.

Note: Voiceover on IOS reads the previous message along with the currently updated message.

Politeness levels are essentially an ordering mechanism for updates and serve as a strong suggestion to user agents or assistive technologies. The value may be overridden by user agents, assistive technologies, or the user. For example, if assistive technologies can determine that a change occurred in response to a key press or a mouse click, the assistive technologies may present that change immediately even if the value of the aria-live attribute states otherwise.

Since different users have different needs, it is up to the user to tweak his or her assistive technologies' response to a live region with a certain politeness level from the commonly defined baseline. Assistive technologies may choose to implement increasing and decreasing levels of granularity so that the user can exercise control over queues and interruptions.

When the property is not set on an object that needs to send updates, the politeness level is the value of the nearest ancestor that sets the aria-live attribute.

The aria-live attribute is the primary determination for the order of presentation of changes to live regions. Implementations will also consider the default level of politeness in a role when the aria-live attribute is not set in the ancestor chain (e.g., log changes are polite by default).

Items which are assertive will be presented immediately, followed by polite items. User agents or assistive technologies may choose to clear queued changes when an assertive change occurs. (e.g., changes in an assertive region may remove all currently queued changes)


<element aria-live="p" ... >
object.setAttribute("aria-live",value);var value = object.getAttribute("aria-live");

Microsoft Active Accessibility Properties:

  • N/A

UI Automation Properties: 

  • N/A

UI Automation AriaProperties Property:

  • live
More in this category: « aria-level aria-multiline »