WordPress
Button Block: Add HTML Element selection in Advanced settings (accessibility)
What problem does this address?
Currently, the Button block only outputs links. Users frequently misinterpret its name. They use the "button" block to trigger modals and other elements that should be triggered by a true HTML button, not a link. This adds accessibility problems to websites, particularly for screen reader users.
Additionally, there are instances where users add groups of links with the button block that should be contained in an HTML list or that function like navigation and should be contained in an HTML nav tag.
These three things are issues that I frequently encounter while accessibility auditing websites built with the block editor. The current solution is to replace core blocks with custom blocks or to write Javascript to remediate the issues. We need to make it easier for users to avoid or fix accessibility issues in a no-code way.
What is your proposed solution?
This block would be greatly enhanced with the addition of several dropdowns in the advanced section that allow developers and more advanced content creators to adjust the markup of the link itself and surrounding markup.
Something similar to the HTML element dropdown on the Group block
This is what we would need:
- HTML element selector for button:
<a>default<button>
- Group HTML element selector:
<div>default<ul>
- Parent container HTML element selector
<div>default<nav>
If a nav tag is set for the parent container, we need to give users the ability to add an aria-label so there would need to be a text field that conditionally appears.
Note: The Buttons block already supports using the button element; I thought there was no UI. See #54206.
Yes this feels more like an education and documentation issue.
- Explain better how to change the element
- More examples of using the interactivity API correctly to create these UI's.
Note: The Buttons block already supports using the button element; Yes this feels more like an education and documentation issue.
Yes, I didn't even know this was possible. 😅
Is there an explicit reason why there is no UI for this?
Yes, to prevent users from setting it to the button element by mistake or doing it wrong.
This is also why we need the block reference to list all the available block supports and block attributes in a searchable way. For example "show all blocks with the tagname" which would have shown that one can change the tag for the block. (Instead of relying on third-party sites to do that.)
Yes, to prevent users from setting it to the button element by mistake or doing it wrong.
I have a hard time with this response. If we want to make it easier for people to build accessible websites without having to write code, there should be a UI for it and in-editor documentation that explains the difference between a button and a link to educate users on what to choose.
If it's only available via the interactivity API, the vast majority of people will not know how to do it. They'll continue using the button block to create click-triggered modals (which a non-dev can do with a plugin like Popup Maker).
Without user testing, there is no way to know which would be the higher risk. The risk that a user changes the element thinking it will behave like a button without any other changes is not a minor issue either.
If they set it to a button and then didn't connect it to something else (either with a plugin or custom code), it would not do anything, right? Theoretically, they would notice that clicking it does nothing when testing their website.
Based on my auditing, a misused link is more likely than a misused button. And the misused link happens all the time.
I'd also be happy to remove the word button from the block title and name it to something else, but I figure that's already been discussed and is a nonstarter.
I am not sure how to move forward with this.
- The code change in the block is relatively small, unless it ends up needing a deprecation.
- A help text that explains when to use the option is difficult to get right.
- I worry that if we add it we might not be able to remove it again and need to support it forever even if we see users misusing it or confused by it.
I worry that if we add it we might not be able to remove it again and need to support it forever even if we see users misusing it or confused by it.
The challenge here is that people are already misusing the current "button" block because they don't understand that it cannot be used to create an HTML button and there is a way to "fake" a button by linking to just a hash.
Adding the ability to set a <button> tag is far less likely to be misused than the current block is already being misused. It is less likely to be misused because a link that has been changed to a button tag by a user who doesn't understand HTML would literally not function. The user will try to click on it with their mouse, and it will do nothing. They will then switch it back to a link, and it will work.
The problem with the current block is that the misuse <a href="#"> appears to work when nonsavvy users click it with their mouse, so they think nothing is wrong with it. Even worse is people who don't put anything in the href and write JS to target it. They still think it works if they're not keyboard testing (which they probably are not).
How about this for helper text?
"A link (<a>) takes users to a new page or section of a page. A <button> performs an action on the page, such as opening a modal or expanding a collapsed section. More about buttons vs links. (link)"
Here are possible articles that could be linked to for the more link:
- W3Schools Accessibility Buttons and Links - shorter
- CSS Tricks Links and Buttons Guide - More detailed (might be too much)
I'm inclined to agree with @amberhinds - this block is already heavily misused. I have personally encountered button blocks with no href attribute in numerous audits, and so there is no question that the block is actively misused as it is.
If we do not want to make it possible to use a button element, then I think we should toggle this to a non-semantic element if it does not have a link added.
However, I don't think that being able to convert this into a button element creates a worse situation than we already have. Right now, we have "links" that don't operate as links; after, we could also have buttons that don't operate as buttons.
I do think that if we add the button option without the ability to create interactivity within the interface we are creating a confusing situation for the user, since they can't create a button that has functionality. However, having a code-based way to enable this would make this more extendable by those who need it.
Overall, my concerns are more about the fact that this can create an a element without href and that there's no option to have an organizational structure for groups of buttons.
I'll chime in here and say as someone who both develops sites and helpw our clients maintain them 99% of our clients do not know that groups have an option to be header, aside etc. etc.
It's fine that it's doable through code, but essentially hard for us to deploy especially on sites where the content has been created over several years of use on a site where we could make their buttons accessible, just by switching the mark-up on given blocks, but also teaching users how it's done, so they can do it retroactively.
Having this option would help us as developers immensely and not affect most of the user base in any way or form.
Personally, I'm not a fan of exposing a section for toggling HTML elements. At this point, I don't see the value in being able to select the button element in the UI that can't be made to work without writing code.
Another approach to avoid exposing buttons that do not have links could be to use the following. Both of which are already used by the Social Link Icon block:
- If no link is set, apply opacity to the block in the editor.
- If no link is set, don't render the button on the frontend.
Additionally, there are instances where users add groups of links with the button block that should be contained in an HTML list or that function like navigation and should be contained in an HTML nav tag.
I agree, but past attempts to resolve this for other blocks such as the next and previous post links have been met with great resistance. 😞
Note: I found two similar requests (#36052 and #57404). I closed those in favor of the current active discussion here.
- I worry that if we add it we might not be able to remove it again and need to support it forever even if we see users misusing it or confused by it.
I have changed my mind about this part because it only adds an interface. If user feedback and support requests would show that it is too confusing, removing the interface would not break the functionality behind it.
If anyone is interested in an example of how people are misusing this block and why the ability to set it to buttons is necessary, check out this video from WordCamp Europe at minute 23. This is the perfect example of someone using a plugin (Popup Maker) to trigger a modal with a button block, but the "button" is not accessible via the keyboard because it's an <a> without an href set.
My original request was for three setting options:
- HTML element selector for button:
<a>default<button> - Group HTML element selector:
<div>default<ul> - Parent container HTML element selector
<div>default<nav>
HTML element selector for button:
<a>default<button>
I think this was solved by #70139.
Group HTML element selector:
<div>default<ul>
This is a lot to take into account, including child elements, so it might be good to submit a new issue. The subject of this issue is the Button block.
Parent container HTML element selector
<div>default<nav>
If the “parent container” means only the Group block, the same issue already exists: https://github.com/WordPress/gutenberg/issues/67407
Both two and three are about the button block, not the group block. The first request was settings on the individual buttons themselves. The other two are settings for the wrapper on the button block that surrounds the individual buttons. Does that make sense?
Amber Hinds
Founder & CEO Pronouns: she/her
Phone: 512-942-5858 https://equalizedigital.com [image: Equalize Digital - websites for everyone logo]
Equalize Digital believes in digital equality. Our mission is to make the web more accessible for our team members, for our clients, for everyone. If there is something in this email or an attachment that does not work for you or your assistive technology, please let me know. I’ll do my best to assist you and resolve issues. Read our full accessibility statement https://equalizedigital.com/about/accessibility-statement/
On Wed, Jun 11, 2025, 8:48 PM Aki Hamano @.***> wrote:
t-hamano left a comment (WordPress/gutenberg#63534) https://github.com/WordPress/gutenberg/issues/63534#issuecomment-2964730356
HTML element selector for button: default
I think this was solved by #70139 https://github.com/WordPress/gutenberg/pull/70139.
Group HTML element selector:
default
This is a lot to take into account, including child elements, so it might be good to submit a new issue. The subject of this issue is the Button block.
Parent container HTML element selector
default
Thank you, I understand now.
The second and third points are about the Buttons block, which is the parent of the Button block.
@amberhinds thank you for posting this issue! I am creating an accessible site and encountered a similar issue.
As you note, the buttons block outputs as a bunch of divs which is totally useless for someone trying to navigate via keyboard TAB. It seems to ignore the buttons even when they're inside a NAV element...
See discussion about surfacing controls so someone could style proper NAV items to look like pill buttons etc: https://github.com/WordPress/gutenberg/issues/39205
and my comment with a video showing the issue: https://github.com/WordPress/gutenberg/issues/39205#issuecomment-3375102979
