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.

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

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.

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

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

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

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.