E-mail List Archives
Thread: Focus Order/Hierarchy for Buttons Within Cards
Number of posts in this thread: 5 (In chronological order)
From: Nicolas Leonard
Date: Wed, Jul 10 2024 1:13PM
Subject: Focus Order/Hierarchy for Buttons Within Cards
No previous message | Next message →
Hi folks!
I’m new to the forum, so please let me know if I’m doing anything wrong ?
We’re working on some web components, including cards that contain an image, headline, description, and button. The entire card is wrapped in an <a> tag, which doesn’t currently have a destination, but it will eventually have the same result as pressing the button. Whether you click the button or the anywhere in the card, you will perform the same action. In effect, the card becomes one big button. Some background: Mouse users will activate card-specific effects on hover, and we want to avoid excluding users who won’t be hovering.
<a class="card" tabindex="0">
<div class="card-image">
</div>
<div class="card-text">
<div class="card-heading">Heading</div>
<div class="card-description">Description goes here.</div>
<button tabindex="-1"><span class="icon"><img src="icon-download-white.svg"></span>Download (PDF 3.2 MB)</button>
</div>
</a>
In the above code snippet, we’re adding tab focus to the card, and removing tab focus from the button. I’m wondering which you all think is most ideal:
* Tab to cards, not to buttons inside (as in the example code snippet)
* Tab to buttons, skipping focus on cards
* Tab to focus on card, tab again to focus on button inside card, tab to focus next card, tab to focus on button inside that card, etc.
Thanks very much!!
Nick
[Vic CanAssist Logo]
Nick Leonard
he/him
Marketing & Social Media
604-999-1418
CanAssist at the University of Victoria
CARSA, PO Box 1700, STN CSC
Victoria, BC V8W 2Y2
www.canassist.ca<;http://www.canassist.ca/>;
We acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands, and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day.
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact me immediately and destroy all copies of the original message. Thank you.
From: Albert Bretado
Date: Wed, Jul 10 2024 1:58PM
Subject: Re: Focus Order/Hierarchy for Buttons Within Cards
← Previous message | Next message →
Hi Nick,
Option 3, in my opinion, would be the most accessible. Although it would require more tab navigation for keyboard users, this ensures all interactive elements are reachable.
Thank you,
Albert Bretado
Web Developer, Marketing and Communications
CPRO, California School Employees Association, Chapter 477
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Nicolas Leonard < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, July 10, 2024 12:13 PM
To: ' = EMAIL ADDRESS REMOVED = ' < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] [WebAIM] Focus Order/Hierarchy for Buttons Within Cards
[You don't often get email from = EMAIL ADDRESS REMOVED = . Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know that the content is safe.
Hi folks!
I'm new to the forum, so please let me know if I'm doing anything wrong ð
We're working on some web components, including cards that contain an image, headline, description, and button. The entire card is wrapped in an <a> tag, which doesn't currently have a destination, but it will eventually have the same result as pressing the button. Whether you click the button or the anywhere in the card, you will perform the same action. In effect, the card becomes one big button. Some background: Mouse users will activate card-specific effects on hover, and we want to avoid excluding users who won't be hovering.
<a class="card" tabindex="0">
<div class="card-image">
</div>
<div class="card-text">
<div class="card-heading">Heading</div>
<div class="card-description">Description goes here.</div>
<button tabindex="-1"><span class="icon"><img src="icon-download-white.svg"></span>Download (PDF 3.2 MB)</button>
</div>
</a>
In the above code snippet, we're adding tab focus to the card, and removing tab focus from the button. I'm wondering which you all think is most ideal:
* Tab to cards, not to buttons inside (as in the example code snippet)
* Tab to buttons, skipping focus on cards
* Tab to focus on card, tab again to focus on button inside card, tab to focus next card, tab to focus on button inside that card, etc.
Thanks very much!!
Nick
From: Jon Bodnar
Date: Wed, Jul 10 2024 2:13PM
Subject: Re: Focus Order/Hierarchy for Buttons Within Cards
← Previous message | Next message →
Hi Nick,
I'm not sure of the 'protocol' for the list, and I rarely respond to messages, but for what it's worth, here's what I'd suggest:
Remove the wrapping link. Make it either a <div> or an <li> - an <li>if your card appears in what would be semantically considered a list of items for possible download, although your <div> could be a child of the <li>. Links and buttons inside of links and buttons is a practice best avoided and often creates problems for screen readers and non-mouse users.
Remove all the setting of the tab indexes. There's likely no reason for it and messing with the tab index can become problematic for non-mouse (keyboard/switch device) users. Also, according to the spec, links aren't permitted child elements with explicit tabindex settings.
If you do those things, I see no reason to think you'd be excluding non-mouse (keyboard / switch device) users. They'll be doing the equivalent of 'tabbing' through your page / interface. Buttons and links are both interactive and will natively handle focus on either and in the order in which they appear in the html, unless someone messes with their tabindex.
You might also consider simply making your button a link with a download attribute and styling it visually to look like a button. I personally use links for page navigation (internal and external) and downloads as it's their expected behavior and I use buttons for interactive activities other than those.
I hope that helps,
-Jon
-----
Jonathan Bodnar
Web Services Lead | Library Technology Project Manager
Digital Library Services
From: Ryan E. Benson
Date: Thu, Jul 11 2024 4:54AM
Subject: Re: Focus Order/Hierarchy for Buttons Within Cards
← Previous message | Next message →
Hi Nick
Have you and read the following article by Heydon - Cards
(inclusive-components.design) <https://inclusive-components.design/cards/>?
It is rather long, but in short, instead of using an button element, you
are making a span element appear as a button and make the whole div
clickable.
--
Ryan E. Benson
On Wed, Jul 10, 2024 at 3:13 PM Nicolas Leonard < = EMAIL ADDRESS REMOVED = > wrote:
> Hi folks!
>
> I'm new to the forum, so please let me know if I'm doing anything wrong ð
>
> We're working on some web components, including cards that contain an
> image, headline, description, and button. The entire card is wrapped in an
> <a> tag, which doesn't currently have a destination, but it will eventually
> have the same result as pressing the button. Whether you click the button
> or the anywhere in the card, you will perform the same action. In effect,
> the card becomes one big button. Some background: Mouse users will activate
> card-specific effects on hover, and we want to avoid excluding users who
> won't be hovering.
>
> <a class="card" tabindex="0">
> <div class="card-image">
> </div>
> <div class="card-text">
> <div class="card-heading">Heading</div>
> <div class="card-description">Description goes here.</div>
> <button tabindex="-1"><span class="icon"><img
> src="icon-download-white.svg"></span>Download (PDF 3.2 MB)</button>
> </div>
> </a>
>
> In the above code snippet, we're adding tab focus to the card, and
> removing tab focus from the button. I'm wondering which you all think is
> most ideal:
>
>
> * Tab to cards, not to buttons inside (as in the example code snippet)
> * Tab to buttons, skipping focus on cards
> * Tab to focus on card, tab again to focus on button inside card, tab
> to focus next card, tab to focus on button inside that card, etc.
>
> Thanks very much!!
> Nick
>
>
>
>
> [Vic CanAssist Logo]
> Nick Leonard
> he/him
> Marketing & Social Media
> 604-999-1418
> CanAssist at the University of Victoria
> CARSA, PO Box 1700, STN CSC
> Victoria, BC V8W 2Y2
> www.canassist.ca<;http://www.canassist.ca/>;
>
>
>
> We acknowledge and respect the lÉkÌÊ·ÉÅÉn peoples on whose traditional
> territory the university stands, and the Songhees, Esquimalt and WSÃNEÄ
> peoples whose historical relationships with the land continue to this day.
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact me immediately and destroy all copies of the original message.
> Thank you.
>
> > > > >
From: Steve Green
Date: Thu, Jul 11 2024 5:01AM
Subject: Re: Focus Order/Hierarchy for Buttons Within Cards
← Previous message | No next message
There are a number of accessible design patterns, but wrapping an <a> element around everything is definitely not one of them even though a lot of people still do that.
In the past, it was common to put a JavaScript event handler on the container <div> element. This was not a terrible solution as long as the container did not receive focus. It meant that mouse users could click anywhere on the card, while keyboard users could tab to the button or link in the card. The event handler was invisible to assistive technologies, although some might announce it as "clickable" depending on their settings.
I was just about to recommend Heydon Pickering's design, but Ryan beat me to it. The demo page is at https://heydon.github.io/Inclusive-Components/cards-pseudo-content/, and we recommend this, or variants of it, to our clients because it does not use JavaScript at all. One change we often make is to put the <a> element around a "call to action" phrase rather than around the heading, but it depends on the card's contents.
Steve Green
Managing Director
Test Partners Ltd