Complex dashboards and standalone cards

[giacomo-petri]

Frequently, we encounter complex dashboards where multiple "cards" with different contexts are presented together. When interacting with the content of one card, only that card's content is affected. Sometimes, this involves reloading the entire card or transitioning from one step to another within the same card.

In HTML, this behavior resembles that of an iframe, but there isn't a corresponding aria role that conveys the same meaning.
While it's possible to group the content within a region with an appropriate label, manage focus or utilize live regions to communicate what's happening to our users, I think it would be beneficial to have a feature that explicitly informs assistive technology users that their actions are confined to the specific card, similar to setting expectations as with an iframe.

[pkra]

Related to - or at least overlapping in terminology with - #1994

[spectranaut]

From today;s meeting (https://www.w3.org/2024/04/18-aria-minutes.html#t01), @giacomo-petri will review the linked discussion and then put "agenda" on this issue to discuss more fully at a future meeting

[giacomo-petri]

After reviewing previous discussions, my concept deviates slightly from the existing proposals. I'm not advocating for a new specific role like "dashboard," "card," or "tile," as these are primarily tied to visual representation and don't necessarily need to convey a visual equivalence.

Furthermore, I don't anticipate keyboard users becoming inadvertently confined within what I'll term a "card" for simplicity, which distinguishes my proposal from the one proposed by Mario. Sighted users can easily grasp and navigate the content of a page regardless of their input device, be it a mouse or keyboard. I don't see the point of trapping keyboard users within a "card". While keyboard shortcuts would be beneficial, they're not the focus of my current proposal.

I've developed a basic demo page, but envisioning a more intricate interaction for each "card": https://codepen.io/Giacomo-Petri/full/JjVejaP. Each "card" functions as a distinct document, updating only its own content.

What I aim for is a role that sets uniform expectations in terms of functionality. As a sighted user, I anticipate that interacting with one "card" affects only its content. Yet simultaneously, if desired, I should be able to transition between cards.

What I think is necessary, based on the scenarios I've encountered, is a role that elucidates and ensures users understand that any action performed is contained within the designated area, yet allows for movement between these areas.

I see an analogy between the native <iframe> element and the role I would like to have. When encountering an iframe, in general users recognize it as a separate document.

In ARIA, I seek something akin to this, enabling users to grasp that operations within a "standalone card" are limited to that card, yet permitting navigation to adjacent elements. For instance, with VoiceOver, encountering an iframe prompts users to press ctrl+opt+shift+down arrow to enter it, and ctrl+opt+shift+up arrow to exit, a behavior that effectively communicates the intention of a "standalone card."

[spectranaut]

Discussed in the ARIA working group today: https://www.w3.org/2024/05/02-aria-minutes.html#t06

[aardrian]

We ran out of time on the call, but I am mostly trying to understand how you envision this being exposed, how it will function, and how visual metaphors do or don't map. What I gleaned from the call:

1. Links within this container only update the container, not the surrounding page (as an <iframe> does, barring target attribute use);
2. The container conveys its start/end, much like a named region would;
3. The container would have an accName (as an <iframe> or named region does);
4. Keyboard focus is not constrained to the container (unlike a modal dialog);
5. Users can jump directly between containers (similar to landmark regions);
6. SR cursor maybe constrained to the container by default.

No idea if I distilled that well, but that was my read. Understanding some of the intent will help at least me to discuss it better.

[giacomo-petri]

Hey @aardrian,

Links within this container only update the container, not the surrounding page (as an <iframe> does, barring target attribute use);

Indeed, activating any element within the container solely updates its content, akin to how an iframe operates.

The container conveys its start/end, much like a named region would;

Indeed, the container indicates its start and end, akin to how a named region would function.
However, when traversed with specific technologies like VoiceOver, an iframe unmistakably delineates its boundaries (more prominently), which, coupled with its inherent "role", accentuates the autonomy of the element. For example, to navigate, VoiceOver users must press ctrl+opt+shift+down arrow to enter and ctrl+opt+shift+up arrow to exit the iframe.

The container would have an accName (as an <iframe> or named region does);

Correct

Keyboard focus is not constrained to the container (unlike a modal dialog);

Correct

Users can jump directly between containers (similar to landmark regions);

Correct

SR cursor may be constrained to the container by default.

Not quite. They should mimic the behavior of iframes. Managing focus remains the author's responsibility. However, for users employing technologies like VoiceOver, entering and exiting the element requires conscious action, as explained above for point 2.

---

In the ARIA working group's weekly call, I brought up the idea of introducing a new role. However, it's possible that instead of a role, we might "only" need an aria attribute.
Perhaps an aria attribute could offer even greater versatility, adaptability, and usability compared to a role. Authors could leverage the existing semantic of the element while simultaneously indicating a partial refresh related to a specific area or landmark of the page.

This proposal aims to help users who are unable to visually perceive the page's layout or changes by providing them with clear expectations when traversing the container. This enables users to anticipate the behaviour (regardless of the element's visual appearance).

[MarioBatusic]

From all the discussions we've had so far and from what you've written Giacomo, it's actually just a dashboard card - whatever it may look like visually. Because in a card you usually have properties of an object, a list of objects, a graph that visualizes big data, etc. In a card you can then delete, change, or add something - regardless of the content of other cards. No matter how we ultimately name the corresponding role, it should be a special landmark role, but a new role that should be recognized by ATs as a separate area, similar to an iFrame. It should then be up to the respective screen reader to decide which help functions are offered to the user within such an environment - a dashboard card.