Page MenuHomePhabricator

CodeMirror toggle buttons need to indicate the current state
Closed, ResolvedPublic

Description

On (2006) toolbar, (2010) wikieditor toolbar, probably 2017 VisualEditor source editing the toggle buttons for CodeMirror need to tell the current state.

Blind users are not able to distinguish between a black or blue icon.

Currently it is always described like title="syntax highlighting" etc.

It needs to be labeled title="activate syntax …" or title="deactivate syntax …" or something like that in various translations. This explains what will happen when toggling the state, and it allows to conclude what the current state is. A blind user is not able to see whether the edit area is coloured. The screen reader is telling them the current button label, but that is always the same.

Those editors use the key to navigate from the edit textarea to the summary input field and finally to the [Publish] button. With CodeMirror enabled, in edit textarea has another effect and does not navigate any longer through the form. Blind users find themselves in a deadlock and have no idea why, since they cannot see the coloured edit area. This just happened to an editor in German Wikipedia.

The unique system message codemirror-toggle-label needs to be split.

Event Timeline

Restricted Application added projects: VisualEditor, Community-Tech. · View Herald TranscriptJun 17 2018, 9:07 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
TheDJ added a subscriber: TheDJ.Jun 17 2018, 3:47 PM

With CodeMirror enabled, ⇥ in edit textarea has another effect and does not navigate any longer through the form

Are you sure ? It does for me, at least with WE2006 and WE2010. Not 2017, but it never did before CodeMirror either. Possibly a browser specific issue ?

Change 440749 had a related patch set uploaded (by TheDJ; owner: TheDJ):
[mediawiki/extensions/CodeMirror@master] Accessibility: Disable both directions of tabbing in CodeMirror

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

Well, the blind user did report that and I could reproduce it with Firefox now.

It just inserts text, by moving the following text element as I would expect in text editors and what I am used from many code editors and text formatters. This happens in CodeMirror mode only, while deactivated the textarea is left and summary gets reached.

If some make this experience in some browsers there is something about.

However, the blind users are not eager to get CodeMirror activated, but they want to know whether it has been toggled on/off.

As soon a robust solution for the button selectors has been distributed I will recommend to make this button really invisible by CSS for people who cannot benefit from CodeMirror.

TheDJ added a comment.Jun 17 2018, 7:41 PM

Just tried it again in FF on my mac, and for me tab moves to the editsummary. This matches what is defined in the code, which basically tells CodeMirror to ignore interpreting tabs (Same spot as where my patch will disable shift-tab)

Well, might be OS/browser issue for unknown reason, interaction with other settings on unknown number of OS/browser types.

The core issue here is that no resources are spent on activated CodeMirror, and the user needs to be informed what the toggle state is.

Mysterious behaviour of the Tab key on activated CodeMirror is another task, but has been the reason for asking the VP/T.

Change 440761 had a related patch set uploaded (by TheDJ; owner: TheDJ):
[mediawiki/extensions/CodeMirror@master] Accessibility: mark syntaxhighlight button as a switch

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

TheDJ added a comment.EditedJun 17 2018, 8:14 PM

Hmm, this proved more annoying than i figured. Notes

1: Old toolbar isn't accessible at all. It's basically invisible
2: Old toolbar action currently throws an error due to setActive not being defined

TypeError: $button.toggleClass(...).data(...) is not a function
updateToolbarButton

3: WE2010 only supports one type of button, and doesn't really support toggles (which is why it wasn't accessible)
4: Did some mucking about, but really this needs some work in WE2010 to support more than just ButtonWidget. The whole setActive hack shouldn't even be there.
5: Confirmed that WE2017 also doesn't indicate state

I've submitted the hackjob, but encourage anyone to solve it the proper way. Would also benefit the CodeEditor toggle.

TheDJ triaged this task as Normal priority.Jun 17 2018, 8:22 PM

Thank you for your work until here.

Old trappers overcome the single button problem by defining both a blue and a black one. Then implementing the action as hiding myself and showing the twin, and performing the major activity. Also an initial state of hiding the “activated” button, if by default.

Change 440749 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] Accessibility: Disable both directions of tabbing in CodeMirror

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

Change 440761 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] Accessibility: mark syntaxhighlight button as a switch

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

matmarex added a subscriber: matmarex.

I am not sure if this is fully resolved with those patches? Can you summarize the current state?

TheDJ added a comment.Jun 19 2018, 8:30 AM

@matmarex the state is, it works, it's accessible, but it's just... a kludge on top of wiki editor ;)

Vvjjkkii renamed this task from CodeMirror toggle buttons need to indicate the current state to 9raaaaaaaa.Jul 1 2018, 1:03 AM
Vvjjkkii raised the priority of this task from Normal to High.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed subscribers: gerritbot, Aklapper.
CommunityTechBot renamed this task from 9raaaaaaaa to CodeMirror toggle buttons need to indicate the current state.Jul 2 2018, 12:02 PM
CommunityTechBot lowered the priority of this task from High to Normal.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added subscribers: gerritbot, Aklapper.
matmarex closed this task as Resolved.Jul 2 2018, 7:26 PM

@matmarex the state is, it works, it's accessible, but it's just... a kludge on top of wiki editor ;)

Well then, if it works…

(Feel free to file a separate bug with Technical-Debt if you think that would be useful)

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptJul 2 2018, 7:26 PM
PerfektesChaos reopened this task as Open.Jul 3 2018, 12:00 PM

The issue is not yet solved. The requirement in task description asked for a distinguished tooltip which tells a blind user the current state of the toggle.

The implementation so far tried to change behaviour of BackTab but that did not change the behviour of in some browsers which do not leave the textarea when CodeMirror is active.

TheDJ added a comment.Jul 4 2018, 7:58 AM

asked for a distinguished tooltip which tells a blind user the current state of the toggle.

We don't use tooltips for that, we use aria state, the screenreader should be able to communicate this information just fine.

The implementation so far tried to change behaviour of BackTab

That was because when you pointed out the tab behaviour, I happened to notice the reverse behaviour was not defined.

not change the behviour of ⇥ in some browsers which do not leave the textarea when CodeMirror is active.

I haven't been able to reproduce this in any of my browsers. Also should probably be a separate ticket btw.

WRT “aria state, the screenreader should be able”:

  • You are referring to role="switch" aria-checked="true" in current implementation.
  • This did not work.
  • In ARIA@w3C this role is marked as “new”, and in the document header it is explained that those were introduced in ARIA 1.1 W3C Recommendation 14 December 2017. I am afraid that not every installation of assisting technology did already implement that, and even more that not every blind user has installed the very last version of such software, if there is no automatic update mechanism.

Even more the tooltip approach is very popular, also if not completely blind, and a literal explanation of this button and the next behaviour would help every innocent user. If the textarea is empty, nobody can learn the effect of toggling between a blue and black pen again and again, and a big mystery when later editing in textarea after changing into blue six clicks ago, connecting between the click on some pen which had apparently no effect at all and the strange coloured things suddenly arriving.

Imagine also people with bad eyes, colour distinction capability but no screenreader or limited fantasy to guess the meaning of a blue writing pen sometimes black.

Since it is not a traditional ticbox where users place or remove a ticmark but something unexpected, a second writing pen in the middle together with the other writing pen at the right hand side the behaviour is not really intuitive.

The behaviour might be reproduced by a Firefox, perhaps not the very recent version, under MS Windows. Our blind user made this experience, and I succeeded too.

TheDJ closed this task as Resolved.Nov 13 2018, 1:15 PM
TheDJ claimed this task.

This was dealt with in the 2nd iteration of T198781: Add toggle/state buttons to WikiEditor.

TheDJ moved this task from Backlog to Closed on the WikiEditor board.Nov 27 2018, 1:47 PM