A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] New aria-virtualcontent attribute


Full explainer of the feature, examples and reasoning can be found here.

Virtualized content allows an author to efficiently represent a large body of information at once. In this practice, only a fraction of the information is actually present in the markup - typically the portion that is currently visible, plus a small amount preceding or following in order to allow for scrolling. As the user scrolls the web page, JavaScript code will load more content and insert it into the markup at the appropriate location. This process is referred to as realizing the content.

Virtualized content presents challenges for users of assistive technologies (ATs). Generally, an AT’s view of the document is limited to what is physically present in the markup. Without some indication that further content exists, the AT cannot accurately describe and navigate the web page. For example, some ATs allow the user to skim the headings in a document by jumping from one to the next. After reading the last realized heading, the AT has no way of knowing that another heading might exist in virtualized content, nor does it have a way of discovering that there is even virtualized content to begin with. The AT, and the user, thus incorrectly conclude that the last heading in the document has been reached.


  • Enable ATs to recognize and account for virtualized content when navigating a web page.
  • Protect the privacy of AT users by avoiding mechanisms that would allow for fingerprinting.

Proposed API

A new attribute, aria-virtualcontent , indicates whether an element contains virtualized content. The default value is none .

A virtual content container is any element that has a non-default value for aria-virtualcontent .

A virtual content edge is an edge of a virtual content container where the webpage can realize content.

The aria-virtualcontent attribute can have one of several keyword values, or multiple values separated by spaces, establishing which edges of the container are virtual content edges: block-end , block-start , inline-end , inline-start . (Future expansion of the attribute value may provide hint(s) about the nature of the virtualized content. ATs could use this information when implementing features such as “navigate to next heading” or “next table” etc.)

Marking an element as a virtual content container establishes a contract between the web page and ATs. Specifically:

  • If the virtual content container is also a scroll container, the web page MUST begin steps to realize content no later than when the virtual content container is scrolled to a limit where a virtual content edge exists.
  • If the virtual content container is not a scroll container, the web page MUST begin steps to realize content no later than when a virtual content edge enters the scrollport of its nearest ancestor scroll container.

On Tuesday, Rossen agreed to move this to a WICG incubation effort not specifically associated with the proposed attribute. Solutions could end up as a declarative markup approach, or a new Web API.

There is general agreement that a solution to the problem is needed. There is not agreement on how to solve it…


Thanks @cookiecrook - the proposal and conversation is being transferred over to WICG repo now.

We certainly need a solution (or set of solutions) for this issue and I am hoping to have an agreeable, declarative API soon :slight_smile:

Let’s get this done!


Sounds great, happy to see the support. Your new home for collaboration will be the wicg/aria-virtualcontent repository. Enjoy!