E-mail List Archives
Thread: Buttons and links: navigating a mixed list
Number of posts in this thread: 5 (In chronological order)
From: Nick Bromley
Date: Thu, Aug 24 2023 5:21AM
Subject: Buttons and links: navigating a mixed list
No previous message | Next message →
I'm auditing a kind of LMS and one page shows available resources of varying
file types. Each resource is presented as a UI control coded as an <a>
element but with role="button". Activating the control either:
* launches the resource directly if it is an embedded HTML-based
activity
* prompts to download the resource if it is an Office file, PDF, or
audio file
So for these role="button" is suitable, although ideally they would be
refactored as proper <button> elements.
But there are a few resources that are links to external websites, and while
these should ideally be modified to be proper <a> elements, this would then
mean the resource listing is a mix of different UI controls. That's OK for
most users, but iOS VoiceOver / Android TalkBack users could easily miss out
on some of the resources depending on what setting they are using to
navigate (either Buttons/Controls or Links). It's not the first time I've
though that an 'All interactive elements' option for mobile screen readers
would be beneficial.
So I was curious if anyone has encountered this issue before and/or has an
elegant solution. I've considered adding some explanatory text somewhere,
but it's tricky finding a suitably noticeable but logical location.
Or perhaps I'm overthinking this and should trust that the site users use a
bunch of different navigation approaches. Of course, user testing would help
but that's proving difficult to arrange with the client.
- - -
Nick Bromley
Director & Accessibility Consultant
Red Kite Digital Accessibility Ltd
From: Steve Green
Date: Thu, Aug 24 2023 6:10AM
Subject: Re: Buttons and links: navigating a mixed list
← Previous message | Next message →
I'm inclined to say you're over-thinking it. Both the links and buttons are in the focus order when swiping through the content. If a user chooses a more specific means of navigation, such as links or buttons, they always run the risk of missing elements. They know that, or at least they should. I don't think you've got any obligation other than to give each element the appropriate role.
Steve Green
Managing Director
Test Partners Ltd
From: Nick Bromley
Date: Thu, Aug 24 2023 9:33AM
Subject: Re: Buttons and links: navigating a mixed list
← Previous message | Next message →
Yes, I don't think there's any other conformance failure, it just feels a bit unsatisfying for the user.
From: glen walker
Date: Thu, Aug 24 2023 11:54AM
Subject: Re: Buttons and links: navigating a mixed list
← Previous message | Next message →
I've never understood why anyone would use <a role="button">. I've seen it
sometimes because the designer/developer liked the look/style of a link.
In that case, a real <button> should be used but just style it with CSS to
get the look you want.
Remember that adding aria attributes does not give you any "behavior".
Slapping a role="button" on a link will not make the link work properly
when SPACE is pressed unless you add some javascript. Without handling the
keyboard event, SPACE will just scroll the page instead of selecting the
link/button.
To be consistent, I think links should be used for all the resources. The
link might navigate to a new page or it might download a document. Those
are both acceptable behaviors for a link.
I'm not sure what "launches the resource directly if it is an embedded
HTML-based activity" means. Do you get an embedded iframe within the page?
From: Nick Bromley
Date: Thu, Aug 24 2023 1:17PM
Subject: Re: Buttons and links: navigating a mixed list
← Previous message | No next message
I very often see <a role="button"> and try and get them refactored where possible.
I've been mulling this over throughout the day, reading various other opinions and discovering a few more resource types that either download directly or open in a new tab, meaning most resources open through link-like behaviour. As a result, I've also been coming round to the idea of making everything a proper link.
The HTML-based activities launch in an iframe embedded in a full-screen overlay that pops up.