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
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Nick Bromley
Sent: Thursday, August 24, 2023 12:22 PM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Buttons and links: navigating a mixed list
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: 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.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Thursday, August 24, 2023 1:10 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Buttons and links: navigating a mixed list
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
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Nick Bromley
Sent: Thursday, August 24, 2023 12:22 PM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Buttons and links: navigating a mixed list
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: 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.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Thursday, August 24, 2023 6:54 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Buttons and links: navigating a mixed list
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?