Page MenuHomePhabricator

Make edit conflict view tab indexes linear
Closed, ResolvedPublic5 Estimated Story Points

Description

Tabbing through the edit conflict view demonstrates that the elements are not ordered well. It seems that they are added to two queues, so that tabbing through the entire page once will give you one set of elements, and then tabbing will wrap back to the beginning and will focus a second group of elements. It would be better if the tabbing worked predictably, so each tabbable element receives focus in the order which it appears in the page.

It's possible that we did this on purpose, so please check the design history and general accessibility guidelines. However, the outcome is still disconcerting, because a user would need to tab through the document twice in order to accomplish the basic use case of resolving a conflict and submitting.

A related problem is that, once you begin editing textbox content, the save and discard buttons have tab indexes *less than* the textbox, so you need to shift-tab out of the text box to save.

Event Timeline

awight created this task.Feb 13 2020, 8:53 AM
Restricted Application added a project: Design. · View Herald TranscriptFeb 13 2020, 8:53 AM
awight updated the task description. (Show Details)Feb 13 2020, 9:04 AM

Change 572617 had a related patch set uploaded (by WMDE-Fisch; owner: WMDE-Fisch):
[mediawiki/extensions/TwoColConflict@master] Move textarea up in the DOM

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

Change 572617 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Move textarea up in the DOM

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

@awight, can you please explain in more detail what the "two queues" are you are mentioning in this tasks description? I tried, but don't understand.

One issue I see is that the summary line uses tabindex="1". That's really bad and should be removed. Unfortunately this 'tabindex' => 1 is hard-coded in EditPage. I don't see an easy way to remove it. It might be that we have to live with it.

@awight, can you please explain in more detail what the "two queues" are you are mentioning in this tasks description? I tried, but don't understand.

You can see what I mean by tabbing through the document, note that you will have to cycle through the document twice to get back to the control you started with. Here's the order I get:

  • Top nav bar controls
  • View tabs, action tabs, search bar
  • Logo
  • Left nav bar links
  • Footer links
  • Browser toolbar
  • Entire page
  • Edit summary
  • Minor edit and watch this page checkboxes
  • Publish and preview buttons
  • Hidden "Jump to navigation" and "Jump to search" links
  • links in text, e.g. "violates any copyrights"
  • Guided tour "info" button
  • User and user talk links for each edit
  • Pencil buttons, column select radio buttons
  • "edit summary" link text (not textarea)
  • "what's this" link text
  • "terms of use", licensing links
  • Cancel button / link
  • Editing help button
  • Links in "please note" section at bottom of page

So, going back to the original problem description, you can see that tabbing through the interface is inefficient and it's unclear whether some of the elements are even reachable, since they'll be skipped over during one or the other cycles over the document. For example, I am on the "this is a minor edit" checkbox, but I want to read the "what's this" help link for that control. You cannot tab between the two without going through the entire page, although they are right next to each other on the page.

I'll add the MediaWiki-General project since most of this can be traced to EditPage.

As far as I can tell everything you explained is caused by the same hard-coded tabindex'es in EditPage. They kind of make sense when there is a single <textarea>, because this is the first element that gets the focus then. This does make some sense, I feel. However, the Two-Column-Edit-Conflict-Merge interface does not show a single <textarea>. To fix this, we either have to add the same tabindex="1" to all our elements (and no, we are certainly not going to do this, because it creates way to many other problems), or teach EditPage to not output these tabindex'es in case of a conflict.

thiemowmde set the point value for this task to 5.Feb 18 2020, 1:05 PM
awight updated the task description. (Show Details)Feb 18 2020, 1:09 PM
awight updated the task description. (Show Details)

Change 573302 had a related patch set uploaded (by WMDE-Fisch; owner: WMDE-Fisch):
[mediawiki/extensions/TwoColConflict@master] Add tabindex to group UI with editOptions area

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

Change 573302 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Add tabindex to group UI with editOptions area

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

thiemowmde closed this task as Resolved.Mar 3 2020, 1:00 PM
thiemowmde moved this task from Demo to Done on the WMDE-QWERTY-Sprint-2020-02-19 board.