WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Role="presentation"

for

Number of posts in this thread: 6 (In chronological order)

From: Kakarla Meharoon
Date: Tue, May 08 2018 5:14AM
Subject: Role="presentation"
No previous message | Next message →

Hi,

For the duplicate link which is redundant, if we add role=" presentation"
and tabindex=-1 screen reader will ignore the link?

From: Steve Faulkner
Date: Tue, May 08 2018 5:18AM
Subject: Re: Role="presentation"
← Previous message | Next message →

you will need aria-hidden=true as role=presentation will only hide the link
semantics but not the link text



--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 8 May 2018 at 12:14, Kakarla Meharoon < = EMAIL ADDRESS REMOVED = > wrote:

> Hi,
>
> For the duplicate link which is redundant, if we add role=" presentation"
> and tabindex=-1 screen reader will ignore the link?
> > > > >

From: Birkir R. Gunnarsson
Date: Tue, May 08 2018 5:51AM
Subject: Re: Role="presentation"
← Previous message | Next message →

steve is right.
In the following example, a screen reader will read the word "foo"
with no context.
<a href="#" role="presentation" tabindex="-1">Foo</a>
It's the same as
<span>foo</span>

If you instead use tabindex="-1" and aria-hidden="true" you totally
hide the thingy.



On 5/8/18, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> you will need aria-hidden=true as role=presentation will only hide the link
> semantics but not the link text
>
>
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
> On 8 May 2018 at 12:14, Kakarla Meharoon < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi,
>>
>> For the duplicate link which is redundant, if we add role=" presentation"
>> and tabindex=-1 screen reader will ignore the link?
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: lynn.holdsworth
Date: Tue, May 08 2018 8:39AM
Subject: Re: Role="presentation"
← Previous message | Next message →

If there is any way not to have duplicate links that would be even better. Having duplicates that can't receive focus could cause confusion for some keyboard users who can see something that looks like a link, but as they tab through the application the focus moves right on by without stopping.

From: Mallory
Date: Tue, May 08 2018 11:11AM
Subject: Re: Role="presentation"
← Previous message | Next message →

One could argue it's not a whole lot better when things look like links, and the keyboarder *can* tab to them, but is fooled into thinking they all go to different places (links to the same place should have ~ the same text, no?). Depending on the context, you feel kinda cheated either way.

I try to have one "canonical" link and anything nearby that needs to, say, be reachable with mouse clicks or something, gets a JS listener that clicks the link. For example an image that's meant to be clickable right under a clearly-a-link text above. I've seen people stretch the anchors' padding to cover larger areas to get the same effect, though on pages like Meetup.com when you're zoomed in it kinda backfires into "the entire visible page is clickable, and you're still not certain where it goes to exactly, because there's a whole book of text inside."

cheers,
_mallory

On Tue, May 8, 2018, at 4:39 PM, = EMAIL ADDRESS REMOVED = wrote:
> If there is any way not to have duplicate links that would be even
> better. Having duplicates that can't receive focus could cause confusion
> for some keyboard users who can see something that looks like a link,
> but as they tab through the application the focus moves right on by
> without stopping.
>
>

From: lynn.holdsworth
Date: Thu, May 10 2018 7:34AM
Subject: Re: Role="presentation"
← Previous message | No next message

Yes Mallory, your approach is the one I'd use too: add a click event to anything that visually appears to be part of a block link. It does get a little bit annoying when the screenreader announces "clickable" when it comes across these pseudo-links, and perhaps increasing the padding on the original anchor is a better way to go, but it is potentially a design nightmare.