Complex dashboards and standalone cards

giacomo-petri commented 7 months ago

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 commented 7 months ago

Related to - or at least overlapping in terminology with - https://github.com/w3c/aria/issues/1994

spectranaut commented 7 months ago

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 commented 7 months ago

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 element and the role I would like to have. When encountering an iframe, in general users recognize it as a separate document.</p> <p>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."</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/spectranaut"><img src="https://avatars.githubusercontent.com/u/583831?v=4" />spectranaut</a> commented <strong> 7 months ago</strong> </div> <div class="markdown-body"> <p>Discussed in the ARIA working group today: <a href="https://www.w3.org/2024/05/02-aria-minutes.html#t06">https://www.w3.org/2024/05/02-aria-minutes.html#t06</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/aardrian"><img src="https://avatars.githubusercontent.com/u/1376607?v=4" />aardrian</a> commented <strong> 7 months ago</strong> </div> <div class="markdown-body"> <p>We ran out of time on the call, but I am mostly trying to understand <em>how</em> you envision this being exposed, how it will function, and how visual metaphors do or don't map. What I gleaned from the call:</p> <ol> <li>Links within this container only update the container, not the surrounding page (as an <code><iframe></code> does, barring <code>target</code> attribute use);</li> <li>The container conveys its start/end, much like a named region would;</li> <li>The container would have an accName (as an <code><iframe></code> or named region does);</li> <li>Keyboard focus is not constrained to the container (unlike a modal dialog);</li> <li>Users can jump directly between containers (similar to landmark regions);</li> <li>SR cursor <em>maybe</em> constrained to the container by default.</li> </ol> <p>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.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/giacomo-petri"><img src="https://avatars.githubusercontent.com/u/106394951?v=4" />giacomo-petri</a> commented <strong> 7 months ago</strong> </div> <div class="markdown-body"> <p>Hey @aardrian,</p> <blockquote> <p>Links within this container only update the container, not the surrounding page (as an <iframe> does, barring target attribute use);</p> </blockquote> <p>Indeed, activating any element within the container solely updates its content, akin to how an iframe operates.</p> <blockquote> <p>The container conveys its start/end, much like a named region would;</p> </blockquote> <p>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.</p> <blockquote> <p>The container would have an accName (as an <iframe> or named region does);</p> </blockquote> <p>Correct</p> <blockquote> <p>Keyboard focus is not constrained to the container (unlike a modal dialog);</p> </blockquote> <p>Correct</p> <blockquote> <p>Users can jump directly between containers (similar to landmark regions);</p> </blockquote> <p>Correct</p> <blockquote> <p>SR cursor may be constrained to the container by default.</p> </blockquote> <p>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.</p> <hr /> <p>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.</p> <p>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).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/MarioBatusic"><img src="https://avatars.githubusercontent.com/u/11882676?v=4" />MarioBatusic</a> commented <strong> 7 months ago</strong> </div> <div class="markdown-body"> <p>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.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/spectranaut"><img src="https://avatars.githubusercontent.com/u/583831?v=4" />spectranaut</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>@giacomo-petri is not sure there is enough to discuss for this to be a F2F candidate</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/aleventhal"><img src="https://avatars.githubusercontent.com/u/1376358?v=4" />aleventhal</a> commented <strong> 1 month ago</strong> </div> <div class="markdown-body"> <p>This is similar to what I've been proposing (although I have not pushed hard for it). Something like aria-boundary. However, the feedback I got at TPAC (from Matt King and James Teh IIRC) is that authors would misuse this and mess it up. Meanwhile, users have complained that they get lost in web pages. </p> <p>One idea is that screen readers could have a key to move backwards through the stack of where they've visited (Z and Shift+Z or something like that). If we had that then perhaps something like role=group would be enough, because the screen reader could also announce when you leave the group.</p> <p>What do people think about the feedback that authors will misuse this and make things worse, or of the idea of fixing the "users get lost out of working area" problem on the screen reader side?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jnurthen"><img src="https://avatars.githubusercontent.com/u/1724479?v=4" />jnurthen</a> commented <strong> 1 month ago</strong> </div> <div class="markdown-body"> <p>Decision - we will meet at 2pm PST on Nov 21</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/MarioBatusic"><img src="https://avatars.githubusercontent.com/u/11882676?v=4" />MarioBatusic</a> commented <strong> 1 month ago</strong> </div> <div class="markdown-body"> <p>The deep-dive meeting is too late for me this time. So here are my thoughts in advance:</p> <p>As we already decided on the occasion of my dashboard issue <a href="https://github.com/w3c/aria/issues/1994">https://github.com/w3c/aria/issues/1994</a>, the <em>listview</em> role will also be used for the semantics of the dashboard. Dashboard cards or areas like those that Giacomo describes here can also be implemented in a <em>listitem</em> of a <em>listview</em>. And if the content of a dashboard card behaves in the same way or similarly as in Giacomo's example, then an ARIA property on the <em>listitem</em> is sufficient to signal this. Most of the cards on the home and in the dashboards of the Fabasoft Cloud, for example, behave in exactly the same way. We plan to make the cards accessible with the keyboard in the same way that VoiceOver accesses iFrames. In addition to the <em>listview</em> role, we are of course still missing a suitable attribute that signals the type of card for screen readers, so that users know that they can enter the card, interact with it like in a modal dialog, and then leave it again.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/cookiecrook"><img src="https://avatars.githubusercontent.com/u/75867?v=4" />cookiecrook</a> commented <strong> 3 weeks ago</strong> </div> <div class="markdown-body"> <p>@giacomo-petri wrote:</p> <blockquote> <p>However, for users employing technologies like VoiceOver, entering and exiting the element requires conscious action, as explained above for point 2.</p> </blockquote> <p>“point 2” was: </p> <blockquote> <p>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 [VO+shift+down] to enter and [VO+shift+up] to exit the iframe.</p> </blockquote> <p>I’m interested to understand why a web author should be able to change a user behavioral preference like this. Currently a user can choose to use VO+shift+right to hop from a card to the next sibling card, or auto-step in using VO+right. </p> <p>The main reason VO doesn’t do this in iframes is because they are mainly used for unwanted ads these days.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/cookiecrook"><img src="https://avatars.githubusercontent.com/u/75867?v=4" />cookiecrook</a> commented <strong> 3 weeks ago</strong> </div> <div class="markdown-body"> <p>@aleventhal </p> <blockquote> <p>the feedback I got at TPAC (from Matt King and James Teh IIRC) is that authors would misuse this and mess it up. </p> </blockquote> <p>Yep.</p> <p>Isn’t this “card” idea another form of landmark? Could it be a new role that inherits from landmark or one of the existing concrete descendants of landmark?</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

w3c / aria

Complex dashboards and standalone cards #2162