WAI-ARIA: Role=Feed
A scrollable list of articles where scrolling may cause articles to be added to or removed from either end of the list.
Description
New in ARIA 1.1
A scrollable list of articles where scrolling may cause articles to be added to or removed from either end of the list
A feed enables users of assistive technologies that have a document browse mode, such as screen readers, to use the browse mode reading cursor to both read and scroll through a stream of rich content that may continue scrolling infinitely by loading more content as the user reads. In a feed, assistive technologies provide a web application with signals of the user’s reading cursor movement by moving user agent focus, enabling the application to both add new content and visually position content as the user browses the page. The feed also lets authors inform assistive technologies when additions and removals are occurring so assistive technologies can more reliably update their reading view without disrupting reading or degrading performance.
For example, a feed could be used to present a stream of news stories where each article contains a story with text, links, images, and comments as well as widgets for sharing and commenting. As a screen reader user reads and interacts with each story and moves the screen reader reading cursor from story to story, each story scrolls into view and, as needed, new stories are loaded.
A feed is a container element whose children have role article. When articles are added or removed from either or both ends of a feed, authors SHOULD set aria-busy to true on the feed element before the changes are made and set it to false after the changes are complete. Authors SHOULD avoid inserting or removing articles in the middle of a feed. These requirements help assistive technologies gracefully respond to changes in the feed content that occur simultaneously with user commands to move the reading cursor within the feed.
Authors SHOULD make each article in a feed focusable and ensure that the application scrolls an article into view when user agent focus is set on the article or one of its descendant elements. For example, in HTML, each article element should have a tabindex value of either -1 or 0.
When an assistive technology reading cursor moves from one article to another, assistive technologies SHOULD set user agent focus on the article that contains the reading cursor. If the reading cursor lands on a focusable element inside the article, the assistive technology MAY set focus on that element in lieu of setting focus on the containing article.
Because the ability to scroll to another article with an assistive technology reading cursor depends on the presence of another article in the page, authors SHOULD attempt to load additional articles before user agent focus reaches an article at either end of the set of articles that has been loaded. Alternatively, authors MAY include an article at either or both ends of the loaded set of articles that includes an element, such as a button, that lets the user request more articles to be loaded.
In addition to providing a brief label, authors MAY apply aria-describedby to article elements in a feed to suggest to screen readers which elements to speak after the label when users navigate by article. Screen readers MAY provide users with a way to quickly scan feed content by speaking both the label and accessible description when navigating by article, enabling the user to ignore repetitive or less important elements, such as embedded interaction widgets, that the author has left out of the description.
Authors SHOULD provide keyboard commands for moving focus among articles in a feed so users who do not utilize an assistive technology that provides article navigation features can use the keyboard to navigate the feed.
If the number of articles available in a feed supply is static, authors MAY specify aria-setsize on article elements in that feed. However, if the total number is extremely large, indefinite, or changes often, authors MAY set aria-setsize to -1 to communicate the unknown size of the set.
Role=Feed Example
<div role="feed">
<article tabindex="-1">Story 1</article>
<article tabindex="-1">Story 2</article>
<article tabindex="-1">Story 3</article>
<article tabindex="-1">Story 4</article>
</div>Characteristics
Superclass Role
Required Owned Elements
- article
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-expanded (state)
- aria-flowto
- aria-grabbed (state)
- aria-haspopup
- aria-hidden (state)
- aria-invalid (state)
- aria-keyshortcuts
- aria-label
- aria-labelledby
- aria-live
- aria-owns
- aria-relevant
- aria-roledescription
Name from
- author
Accessible Name Required
- False
Semantic HTML
No HTML element equivalent.
The role “feed” was added in ARIA 1.1 to provide a mechanism for handling infinite scrolling regions within dynamic feed environments.
The role=”feed” container acts much like a named region or landmark, though it must only include first-level child roles with role=”article”. The Article role may of course include any number of other roles and active elements.
Programmatic focus handling must be used to move focus between each role=”article” element within the role=”feed” container, and new role=”article” containers must be dynamically added to the beginning or end of the role=”feed” container when rendered.
The use of aria-describedby may be added on each focusable role=”article” container to automatically announce the desired content within that article when it receives focus.
A focusable button should also be available at the end of the role=”feed” container that will dynamically load additional role=”article” elements when activated. This is needed for touchscreen devices and screen readers that use off-screen browse modes.
Reference
- WAI-ARIA 1.2 Specification
Refer to the notes from the WAI-ARIA 1.2 specification for more information on role=feed.
