[angrybards]

Screen readers use the clear semantic difference between a button and a link to make sure the user knows what to expect and users are used to the different keyboard shortcuts. I saw in your specification an example where a website made effort to work around this clear separation and from what I could tell there may have been user testing, but in other places I see that usability is best for screen reader users where the semantics are clear.

This proposal would standardize an in between element, adding a third form they have to understand with different behaviors. I guess just make sure you get some experienced accessibility feedback in your submission.

https://www.thewcag.com/examples/buttons-links

[alexpetros]

I'm not entirely sure what you mean by "in-between" element, but that's not what this proposal does. This proposal simply augments the button's existing ability to navigate the current context by removing the need to wrap it in a form. This is useful because sometimes buttons are already the right semantic element to use, but you can't use them to do this without JavaScript.

Also, that link has a lot of wrong information and is not an official W3C site. It even has a LinkedIn page.[0]

[0]https://www.linkedin.com/company/thewcagcom/

[angrybards]

I wasn't under the impression it is a W3C site, for all I know it is AI generated and looks it to me. But, there are other blog posts I've coming across where this is discussed and that site did outline my point well enough which is changing norms like this can be hard for screen reader users who need to adapt to <a>, <button> and <button action> being controls performing very similar if not overlapping behaviour.

Currently these changes in norms happen because developers use links as buttons and buttons as links which can create confusion for the screen reader user / visual user who expects certain behavior based of the visual presentation of the control. Making button[action] standard in HTML codifies that behaviour though doesn't it?

I get that you are trying to effectively solve this problem, but it isn't so easy when this group of people are more reliant on norms. Maybe they would embrace a solution here if they were engaged with is all.

- https://adrianroselli.com/2016/01/links-buttons-submits-and-... - https://adrianroselli.com/2023/08/styling-links-and-buttons.... - https://karlgroves.com/links-are-not-buttons-neither-are-div...

[alexpetros]

Totally, this is part of the problem I'm trying to solve. I wrote a little about these "call to action links" that you're describing in the proposal.[0] The tl;dr is that I think it would be easier to hold the line that "links should look like links" if we supported the legitimate use cases for navigating with buttons.

I would love more feedback from the accessibility engineering community so please look up my email or comment on the proposal if you think I've missed something.

[0] https://triptychproject.org/proposals/button-actions#what-ab...