E-mail List Archives
Thread: Linking article previews
Number of posts in this thread: 12 (In chronological order)
From: Brian Lovely
Date: Fri, Jul 19 2019 11:50AM
Subject: Linking article previews
No previous message | Next message →
There are some article previews that have the article type, title, first
sentence, and publish date in a div. They are listening for mouse events on
the div, but there is no actionable element at all. Currently clicking on
the div opens the article page in another tab. I told them to make the
article title into a link, but now if someone clicks on the link, two tabs
are opened.
I don't want to wrap the entire div in a link and have the link text be all
that hoo hah.
Any suggestions on how to avoid this?
*Brian Lovely*
Capital One Digital Accessibility
804.389.1064
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: glen walker
Date: Sat, Jul 20 2019 9:38AM
Subject: Re: Linking article previews
← Previous message | Next message →
How about remove the click handler on the <div> and let the article title
link just do it's job. You can associate the extra metadata (article type,
date, first sentence) with the link using aria-describedby.
Old code:
<div click="yourstuff()">
<p>article type</p>
<a href="article.html">title</p>
<p>first sentence</p>
<p>date</p>
</div>
New code
<div>
<p id="one">article type</p>
<a href="article.html" aria-describedby="one three two">title</p>
<p id="two">first sentence</p>
<p id="three">date</p>
</div>
On Fri, Jul 19, 2019 at 11:50 AM Brian Lovely via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:
> There are some article previews that have the article type, title, first
> sentence, and publish date in a div. They are listening for mouse events on
> the div, but there is no actionable element at all. Currently clicking on
> the div opens the article page in another tab. I told them to make the
> article title into a link, but now if someone clicks on the link, two tabs
> are opened.
>
> I don't want to wrap the entire div in a link and have the link text be all
> that hoo hah.
>
> Any suggestions on how to avoid this?
>
>
> *Brian Lovely*
> Capital One Digital Accessibility
> 804.389.1064
> >
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
> > > > >
From: Mark Magennis
Date: Mon, Jul 22 2019 3:26AM
Subject: Re: [EXTERNAL] Linking article previews
← Previous message | Next message →
Glen, a problem with this approach is that the whole on-screen area of the article is no longer clickable. You have to click on the title.
Brian, an approach that may work for you is to make the container a <div role="link" tabindex="0" aria-label="article_title"> (using the actual title of course).
Mark
Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist
From: Brian Lovely
Date: Mon, Jul 22 2019 7:33AM
Subject: Re: [External Sender][EXTERNAL]Linking article previews
← Previous message | Next message →
Mark, that might work. I assume that the contents of the div would still be
discoverable with the virtual cursor.
On Mon, Jul 22, 2019 at 5:27 AM Mark Magennis < = EMAIL ADDRESS REMOVED = >
wrote:
> Glen, a problem with this approach is that the whole on-screen area of the
> article is no longer clickable. You have to click on the title.
>
> Brian, an approach that may work for you is to make the container a <div
> role="link" tabindex="0" aria-label="article_title"> (using the actual
> title of course).
>
> Mark
>
> Mark Magennis
> Skillsoft | mobile: +353 87 60 60 162
> Accessibility Specialist
>
>
>
From: Mark Magennis
Date: Mon, Jul 22 2019 9:11AM
Subject: Re: [External Sender][EXTERNAL]Linking article previews
← Previous message | Next message →
No reason why not. The title would be read twice though. Once as the link text and once as itself. You could add aria-hidden to the title to prevent that. You could even use aria-labelledby instead of aria-label because it's a bit more elegant and I think it will still work even when it's pointing at a hidden element.
You would have to test this across all your supported browser/screen reader combinations though because it's possible that you might find a combination that doesn't like something in it, e.g. an aria-label on a div even if it has a link role.
Mark
Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist
From: glen walker
Date: Mon, Jul 22 2019 9:13AM
Subject: Re: [EXTERNAL]Linking article previews
← Previous message | Next message →
That was Brian's original request, that he didn't want the entire <div> to
be the link. That was actually my first idea but I changed it after I
re-read his question.
On Mon, Jul 22, 2019 at 3:27 AM Mark Magennis < = EMAIL ADDRESS REMOVED = >
wrote:
> Glen, a problem with this approach is that the whole on-screen area of the
> article is no longer clickable. You have to click on the title.
>
>
>
From: Brian Lovely
Date: Mon, Jul 22 2019 9:15AM
Subject: Re: [External Sender][EXTERNAL]Linking article previews
← Previous message | Next message →
" you might find a combination that doesn't like something in it" --ain't
that the truth
On Mon, Jul 22, 2019 at 11:11 AM Mark Magennis < = EMAIL ADDRESS REMOVED = >
wrote:
> No reason why not. The title would be read twice though. Once as the link
> text and once as itself. You could add aria-hidden to the title to prevent
> that. You could even use aria-labelledby instead of aria-label because it's
> a bit more elegant and I think it will still work even when it's pointing
> at a hidden element.
>
> You would have to test this across all your supported browser/screen
> reader combinations though because it's possible that you might find a
> combination that doesn't like something in it, e.g. an aria-label on a div
> even if it has a link role.
>
> Mark
>
> Mark Magennis
> Skillsoft | mobile: +353 87 60 60 162
> Accessibility Specialist
>
>
>
From: Brian Lovely
Date: Mon, Jul 22 2019 9:17AM
Subject: Re: [External Sender][EXTERNAL]Linking article previews
← Previous message | Next message →
Well, my primary problem was I didn't want the entire div as the call to
action for a link. Mark's solution actually circumvents that.
On Mon, Jul 22, 2019 at 11:15 AM Brian Lovely < = EMAIL ADDRESS REMOVED = >
wrote:
> " you might find a combination that doesn't like something in it" --ain't
> that the truth
>
> On Mon, Jul 22, 2019 at 11:11 AM Mark Magennis <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> No reason why not. The title would be read twice though. Once as the link
>> text and once as itself. You could add aria-hidden to the title to prevent
>> that. You could even use aria-labelledby instead of aria-label because it's
>> a bit more elegant and I think it will still work even when it's pointing
>> at a hidden element.
>>
>> You would have to test this across all your supported browser/screen
>> reader combinations though because it's possible that you might find a
>> combination that doesn't like something in it, e.g. an aria-label on a div
>> even if it has a link role.
>>
>> Mark
>>
>> Mark Magennis
>> Skillsoft | mobile: +353 87 60 60 162
>> Accessibility Specialist
>>
>>
>>
From: Mark Magennis
Date: Mon, Jul 22 2019 9:58AM
Subject: Re: [EXTERNAL]Linking article previews
← Previous message | Next message →
Well, Brian didn't want the entire text of the article to be read out as the link name, but I imagined that his UX crew probably still want the entire area of the article to be mouse clickable.
I actually have almost the same issue here except the approach I've suggested won't work for us. We have cards that represent learning assets (courses, videos, audiobooks, etc.) and which contain a lot of content (name, type, details, image, etc.) just like Brian. We also want the card to be a link that opens the asset, we want mouse users to be able to click anywhere on it, but we don't want all that content to be read out as the link title. But our cards also contain a Like button and an Actions menu and we are finding that when the Actions menu button receives focus in IE11, JAWS and NVDA both read out the entire contents of the card before reading the button's name. The 'cause' appears to be a tabindex="-1" on an ancestor div but that's there for a good reason so we're having to think creatively about how to get rid of it without getting rid of it. Sometimes I wish we could just get rid of Internet Explorer. But we can't.
Mark
Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist
From: Jonathan Avila
Date: Mon, Jul 22 2019 10:21AM
Subject: Re: [EXTERNAL]Linking article previews
← Previous message | Next message →
I've seen a related issue with cards. If the whole card is actionable and you want to meet WCAG 2.1 SC 2.5.4 Label in Name then the accessible name for the card must contain everything shown in the card as text. This means that you can't have a summarized accessible name for the card. This seems problematic in some situations.
Jonathan
Jonathan Avila, CPWA
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office
Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
From: Mark Magennis
Date: Mon, Jul 22 2019 10:36AM
Subject: Re: [EXTERNAL]Linking article previews
← Previous message | Next message →
I think that's debatable Jonathan. SC 2.5.3 talks about "the words which visually label a component" and goes on to say "it is first necessary to determine which text on the screen should be considered a label for any given control". I don't see anything that explicitly states that this must include all of the text on or within the bounds of the control and to me it intuitively feels like it shouldn't. Is there any more guidance on this from WAI or a general consensus that has arisen from discussion?
Mark
Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist
From: Mallory
Date: Tue, Jul 23 2019 1:27AM
Subject: Re: [EXTERNAL]Linking article previews
← Previous message | No next message
If you think about it, if you have big cards with lots of text and all that text is actionable link-text...
that would absolutely suck for speech recognition.
The chances that any word you speak could match something inside a clickable is high. Someone can convince me otherwise with a good argument but right now I would consider that an anti-pattern.
For cards I always keep the link text itself short (and it's what you see get focus with keyboard) and use JS to make most of the card clickable. Specifically I want the click listener on the div/whatever to trigger a click on the link, rather than doing its own navigation.
One issue I've run into with that is cards with stuff like event information-- when I'm on a slow (say... event/conference) network and I want to copy some date or venue address from the card without clicking it, that's hard, because to highlight with the mouse, I'm clicking it.
cheers,
Mallory
On Mon, Jul 22, 2019, at 6:37 PM, Mark Magennis wrote:
> I think that's debatable Jonathan. SC 2.5.3 talks about "the words
> which visually label a component" and goes on to say "it is first
> necessary to determine which text on the screen should be considered a
> label for any given control". I don't see anything that explicitly
> states that this must include all of the text on or within the bounds
> of the control and to me it intuitively feels like it shouldn't. Is
> there any more guidance on this from WAI or a general consensus that
> has arisen from discussion?
>
> Mark
>
> Mark Magennis
> Skillsoft | mobile: +353 87 60 60 162
> Accessibility Specialist
>
>
>