Replace some action links by buttons



After the fix for XWIKI-21492, a few buttons have displayed a weird behaviour: on hover their text would be underlined.

Those screenshots are a courtesy of @ilie.andriuta who brought up the question :slight_smile:

The reason why this happens is that those elements, even though they look like buttons, are anchors <a>. On XWiki, all anchors are underlined on hover.
Before the recent change, those had a custom style that made sure they wouldn’t be underlined even on hover. With the change, this custom style lost priority and is now overridden.

We could fix the change in style one way or another, but IMO this highlights a semantic issue with those buttons. The advantage of having an action link (link that looks like a button) over a button is that the user can right click it and open it in a new tab. We have some of those in the UI, and in most cases they are fine. However, we should still use buttons if the action does not need to be done in a new tab.


Replace the action links A, B and C. This will be a regression feature-wise (no more creating a wiki in a new tab, disabling an account in a new tab or changing password in a new tab). This will be an improvement in the semantics and consistency of our UI.


I think that in the cases of A, B and C it’s ok to lose this “New Tab” feature. However it’s not the case for D, opening a new profile section in a new tab is an important use case: I’m editing a preference and I want to check what I put in a preference in another section, I want to be able to open a tab with this other preference next to my editor easily.
Action links can be a bit tricky to deal with on multiple levels, and I’d rather have them used (in the XWiki standard flavor) only when a button is not enough.


What do you think of this proposal? Do you know of other action links that could be buttons like A, B and C?

Thank you in advance for your feedback!
Lucas C.

I agree that D is an important use-case, I think we should keep it possible to be opened in a new tab.

I agree. For me D is clearly not a button visually so I don’t see an issue with the proposal which would be that buttons use the <button> html tag (instead of links), which is more semantic and most likely better for screen readers too (ie better for accessibility).

Note that those links also have correct semantics, it’s just that screen readers will “see” what we try to hide on the GUI. The better accessibility is achieved by aligning what everyone “sees” :slight_smile:

I think the users that would benefit the most from this are partially sighted users: they can identify the button (large brightly colored blob). However they use a screen reader to help them navigate and read, and the screen readers tells them it’s a link. This inconsistency could be quite confusing.

Non sighted users will only “see” a link there, and most sighted users will only “see” a button here.


If no problem is highlighted by then, I’ll close this topic on the 23rd, opening a corresponding a ticket on jira and start working on those small changes soon :slight_smile:

It’s not clear to me how do you decide when opening in a new tab is needed and when it’s not.

I’m +1 for using a button for C, and maybe +0 for B, but I’m not sure about A because in this case it takes you to a different page (without being a form submit).

And yes, D should stay links.