Button Block: Add HTML Element selection in Advanced settings (accessibility)

[amberhinds]

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:

1. HTML element selector for button:
   • <a> default
   • <button>
2. Group HTML element selector:
   • <div> default
   • <ul>
3. 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.

[Mamaduka]

Note: The Buttons block already supports using the button element; I thought there was no UI. See #54206.

[carolinan]

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.

[ndiego]

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?

[carolinan]

Yes, to prevent users from setting it to the button element by mistake or doing it wrong.

[carolinan]

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.)

[amberhinds]

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).

[carolinan]

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.

[amberhinds]

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.

[amberhinds]

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.

[carolinan]

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.

[amberhinds]

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)