Hello there. There's no perfect solution for this: If we placed the text below the button, we would risk hiding the conditions from screen reader users (and making them easier to ignore, due to reading order, for everyone else). I think we should follow the usual approach (see source edit pages in enwiki) and keep the conditions text above the 'Create Lexeme' button, reflecting the recommended/logical reading order.

Now, I've noticed that source edit pages on Wikipedia exclude terms and conditions links from the tab flow (i.e. so one moves directly to the 'Publish changes' button when tabbing from the last checkbox – 'Watch this page'). This is a solution that would solve the issue risen by this ticket. Nevertheless, I'm not sure whether this is totally friendly for people with reduced mobility, so we should be aware of this potential compromise.

In order to easily remove the copyright message links from the tab flow, while keeping them accessible via screen reader (using control key), we could apply tabindex=-1 to them:

I will point out that the terms and conditions section does not actually render as intended in every locale. For pnb it shows raw wiki markup and the links do not resolve.

In T322686#8390013, @mrephabricator wrote:

I will point out that the terms and conditions section does not actually render as intended in every locale. For pnb it shows raw wiki markup and the links do not resolve.

(This unrelated issue is now T322946.)

Task breakdown notes:

• We see two possible ways forward with this:
  1. Add tabindex=-1 to the copyright/terms of use links (this seems to be the preferred way a11y-wise )
  2. Add positive tabindexes to the input fields and the button

The plan of action in this case would be to try out the option and then decide.

Now we have two PRs up that implement the different options:

• https://github.com/wmde/new-lexeme-special-page/pull/328 (move inputs and create lexeme button to the beginning of the tab-order)
• https://github.com/wmde/new-lexeme-special-page/pull/329 (make Terms of Use and License unreachable by tab)

In T322686#8399322, @Michael wrote:

Add tabindex=-1 to the copyright/terms of use links (this seems to be the preferred way a11y-wise )

I think, I would challenge that notion in that generality. Would be nice to hear more about the reasoning behind that statement.

As stated in the guidelines linked by Noa, from an accessibility perspective "DOM order is preferred wherever possible", and thus tabindex > 0 should be avoided to not interfere with that default flow. Subtracting interactive elements from the flow (using tabindex=-1) is definitely not ideal either, but has a smaller impact/override effect on the overall navigation order.

Subtracting interactive elements from the flow (using tabindex=-1) is definitely not ideal either, but has a smaller impact/override effect on the overall navigation flow.

Why?

I might agree with this if those elements are actually still reliably reachable in a different way. I think we so far have established this to be the case for the VoiceOver screen reader, and I also just now verified it for the Orca screen reader on Linux. However, NVDA and JAWS, the most common screen readers, still need to be tested.
If they also work with the tabindex=-1 solution, then I'd be unhappily ok with picking that. (We'd only be making it completely inaccessible to people who are forced to use the keyboard, but are not using screen readers, because they are still sighted)

But otherwise, the solution still accessible to everyone is to adjust the tab order, which is also what the foundation uses (For example when you click "Edit" on the very article that Noa linked).

I see your point and agree with your concerns. I think we should proceed with the approach suggested by #328. Nevertheless, the outcome of modifying the default tab order as a result of the changes applied via that pull request involves skipping the page's structure and navigation order quite a bit:

To proceed with this direction, we could slightly change the suggested order like so (i.e. start the tab flow on the first link):

Let me know what you think, @Michael. Like we did with the other approach, it would be great to test that the page is still fully accessible (I verified this with VoiceOver, so things are looking good so far).

Again, no solution seems to be perfect, and I feel that responding to this request is actually making us apply antipatterns and modifying a perfectly valid default tab flow.

Change 857705 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikibaseLexeme@master] Ensure that infopanel comes directly after main app in tab-order

https://gerrit.wikimedia.org/r/857705

Again, no solution seems to be perfect, and I feel that responding to this request is actually making us apply antipatterns and modifying a perfectly valid default tab flow.

I feel the same way, to be honest… I think leaving the tab order as it is might be better than either of the two approaches? (You can actually create the lexeme without tabbing out of the lexical category field at all, by pressing Enter there.)

This is the tab order with #328 (fixTabOrder branch) + the above Gerrit change:

And this is the tab order with #329 (keyboardSkipLicense branch):
{F35786874}

(Edited to fix the second screenshot, sorry.)

That's not the intended tab-flow #328 + Ensure that infopanel comes directly after main app in tab-order (Ia8f374ae). I will have to look into that again o.O

You can actually create the lexeme without tabbing out of the lexical category field at all, by pressing Enter there.

Oh wow. Ok, that actually removes the extra tabbing inconvenience for heavy keyboard users entirely. Nevertheless, this sounds really error prone, and like something that might impact data quality...What motivated this decision? And in case there are very strong arguments to support this: are we tracking how many invalid Lexemes (e.g. require deletion) are being submitted this way? We should probably keep an eye on this.

What motivated this decision?

I think this is the context in which this was decided: https://phabricator.wikimedia.org/T305359#7955779
It is consistent with other parts of Wikidata, but i remembered we scrambled over this quite a bit.

You can actually create the lexeme without tabbing out of the lexical category field at all, by pressing Enter there.

Probably @Nikki (like myself) wasn't aware of this behavior, which removes the need to actually tab and select the button in order to submit the form. I think the tab order modifications we were considering to solve this ticket are, after all, unnecessary (for now) in a context where the form can be submitted implicitly, from any input (once the form is filled). With Nikki's and @Lydia_Pintscher's permission: I'd say we can resolve this task?

This is probably behind this other piece of feedback, documented in T322684: keyboard navigation issues on Special:NewLexeme:

Pressing enter after entering a language name or lexical category tries to submit the form instead of selecting the top entry.

In that case, one needs to highlight the match from the menu and then press enter to make a selection/fill the input. Pressing enter on the input without having made a selection will, as I now understand, try to submit the form.

Now, coming back to the UX perspective on this: my concern is that applying this standard to certain contexts (like, probably, the NewLexeme form) can be problematic. Implicit behavior is not discoverable and might be, as mentioned, a source of unwanted results. There's only so much validation can do to prevent unintentional submissions. Now, based on the context that Michael and Noa kindly provided (https://phabricator.wikimedia.org/T305359#7955779), this behavior is backed by current patterns (throughout WD and the web), and I also understand the clear accessibility value of this practice (it allows screen reader users to move faster). I wonder, though, if it would be a good idea to keep an eye on more complex forms like the one we have in our hands: it'd be great to track unwanted submissions (e.g. request for deletion of lexemes created on enter) or at least keep our ears peeled for feedback related to this behavior.

In T322686#8400106, @Michael wrote:

That's not the intended tab-flow #328 + Ensure that infopanel comes directly after main app in tab-order (Ia8f374ae). I will have to look into that again o.O

Sorry, I might’ve done something wrong when taking the screenshots. Feel free to ping me if you want to look at it together…

In T322686#8401616, @Sarai-WMDE wrote:

You can actually create the lexeme without tabbing out of the lexical category field at all, by pressing Enter there.

Probably @Nikki (like myself) wasn't aware of this behavior, which removes the need to actually tab and select the button in order to submit the form. I think the tab order modifications we were considering to solve this ticket are, after all, unnecessary (for now) in a context where the form can be submitted implicitly, from any input (once the form is filled). With Nikki's and @Lydia_Pintscher's permission: I'd say we can resolve this task?

Hi, @Nikki 👋🏻 We believe this task can be resolved, but would appreciate your input. Thanks a bunch!

Change 857705 abandoned by Michael Große:

[mediawiki/extensions/WikibaseLexeme@master] Ensure that infopanel comes directly after main app in tab-order

Reason:

We probably don't want to do this after all (this discussion in task)

https://gerrit.wikimedia.org/r/857705

Hi all,

Based on the discussion here we are going to close the ticket. If you *strongly* disagree please feel free to reopen the ticket.