WordPress.org

Make WordPress Core

Opened 7 years ago

Last modified 11 days ago

#12423 assigned feature request

Include default code editor

Reported by: scribu Owned by: georgestephanis
Milestone: 4.9 Priority: normal
Severity: normal Version: 3.0
Component: Editor Keywords: close
Focuses: accessibility Cc:

Description

We've dropped CodePress since it wasn't quite up to par in regards to browser compatibility.

How about using Bespin for editing plugin and theme files?

Attachments (1)

12423.codemirror.unminified.diff (751.2 KB) - added by georgestephanis 4 months ago.
First patch at including CodeMirror.

Download all attachments as: .zip

Change History (130)

#1 @scribu
7 years ago

There's already a plugin that does this (on a separate admin page):

Better File Editor

#2 follow-up: @c00l2sv
7 years ago

Bespin has poor support for non HTML5 browsers [1].

What about CodeMirror [2]?
Pretty active development and cross-browser support, bsd-like license [3], clean look[4].

[1] https://wiki.mozilla.org/Labs/Bespin/UserGuide#Requisites
[2] http://marijn.haverbeke.nl/codemirror/
[3] http://marijn.haverbeke.nl/codemirror/LICENSE
[4] http://marijn.haverbeke.nl/codemirror/contrib/php/index.html

#3 @nacin
7 years ago

I've also been looking at EditArea. http://sourceforge.net/projects/editarea/

#4 @jane
7 years ago

I was at a panel with one of the guys behind Bespin last week and he said flat out that Bespin was created knowing that they didn't have to worry about IE based on their audience. It was a Canvas vs Flash panel at sxsw, and though it looked cool, it looked very niche in availability based on our general audience browser stats. I don't think we can use Bespin unless we are going to try and be trailblazers for Canvas/HTML5 and basically pull an early-2000s web standards trick and just say 'your browser sucks, upgrade,' which is sometimes tempting, but would be a bummer for users who don't get to install software on their machines and are stuck with pre-9 IE (schools, libraries, government agencies, etc). Injecting a Chrome frame into IE is their workaround I think.

#6 in reply to: ↑ 5 @nacin
7 years ago

  • Milestone changed from 3.1 to Future Release

Replying to c00l2sv:

Also found this: http://shjs.sourceforge.net/

General thoughts here. By all means, we should identify and test as many projects as possible. That said, I don't think we want to repeat mistakes made with CodePress in regards to project activity. http://shjs.sourceforge.net/ has only one maintainer (as does EditArea and countless others) though it also hasn't had a release since 2008.

It would be naive to think that just because a project supports IE6 now, it'll always support every presumably more standards-compliant browser in the future (not to mention future standards). Aside from that, inclusion in WordPress would reveal existing bugs thanks to a larger userbase.

Finding an active (and willing) project should be as important an objective as finding one that works cross-browser.

#7 @c00l2sv
7 years ago

What are the chances to fork an existing project and maintain it exclusively for WordPress (patching and bug fixing if problems arise)?

#8 @mitchoyoshitaka
6 years ago

  • Summary changed from Include Bespin as default code editor to Include Ace (or similar) as default code editor

Bespin, which became SkyWriter, now has merged with and is superceded by Ace. Ace doesn't require canvas for its rendering engine. It is tri-licensed (MPL/GPL/LGPL).

#9 @mitchoyoshitaka
6 years ago

  • Cc mitchoyoshitaka added

#10 @aurimas
6 years ago

  • Cc aurimas added

#11 @mitchoyoshitaka
6 years ago

FWIW, note that Mozilla themselves have decided not to use Ace wholesale for integration into the browser for Firefox's DevTools initiative (think native Firebug).

More info on that decision here:
https://wiki.mozilla.org/DevTools/Features/CodeEditor#Evaluating_the_Options

The bug for their work on integrating their winner, the Orion code editor, into fx is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=660784

#12 in reply to: ↑ 2 @WraithKenny
6 years ago

Replying to c00l2sv:

What about CodeMirror [2]?
Pretty active development and cross-browser support, bsd-like license [3], clean look[4].

I've been using CodeMirror in Scripts-n-Styles and like it alot. The best feature is mixed-mode support so that script and style tags are appropriately highlighted in html which in turn is highlighted in a php file which is properly highlighted.

#13 @WraithKenny
5 years ago

CodeMirror is a solid and unobtrusive editor (degrades gracefully, ie, doesn't impact without javascript) which is simple to include into the plugin/theme editor pages. For example, I've quickly integrated it into Scripts-n-Styles to see what would be involved (and because I thought it'd be useful):

https://github.com/unFocus/Scripts-n-Styles/blob/master/js/code-editor.js
https://github.com/unFocus/Scripts-n-Styles/blob/master/includes/class.SnS_Admin_Code_Editor.php
https://github.com/unFocus/Scripts-n-Styles/blob/master/css/code-editor.css

The CodeMirror part of it works great (though there are bugs in the wp side of the editor). There are also quite a few other plugins that configure CodeMirror in more advanced ways, to include Search-n-Replace, Auto-complete, and more. (This also means it is somewhat tested in the wordpress environment.)

CodeMirror is open and actively developed https://github.com/marijnh/CodeMirror2/graphs/impact

Supports Firefox 2+, Chrome (any version), Safari 3+, Internet Explorer 6+, Opera 9+ http://codemirror.net/

Anyone still interested in this? I think I remember something about splitting the editors completely out of core and into a "Core Plugin" like the importer plugin. If so, any interest in that? (I'd contribute if it had blessing.)

#15 @WraithKenny
5 years ago

An update: Adobe decided to go with CodeMirror over ACE: https://github.com/adobe/brackets/wiki/Notes-on-CodeMirror essentially because of its MIT license. Their engineers are working with CodeMirror's developer, so the project has more support behind it.

On the related ticket above (a request for highlighting in the post editor) CodeMirror has a markdown mode included.

Also, In the mean-time, I'm sure ACE has evolved from the last time I checked, and they moved to a BSD license.

#16 @bpetty
5 years ago

I can't find it now, but I know there was some recent discussion regarding possibly removing the code editors entirely from core because they are just so dangerous for most users, and now that WP 3.4+ has the theme customizer, the theme editor really isn't needed/recommended at all.

Anyway, I think this is part of the reason that when I proposed doing exactly this kind of thing with the editors, I was forced to convert my patch into a plugin. Here's the relevant IRC discussion, and here's the final plugin (which made use of ACE).

Given the above though, I think that we really should start closing up these tickets just like all other "plugin material" requests, they honestly aren't going to ever be merged in when it comes down to a finished patch in the end, based on my experience. It's definitely less than 20% of users that end up needing the editors or using them, and they encourage the horrible practice of "cowboy coding". Everyone that told me to move it to a plugin really was right, the entire editors themselves should be a plugin.

#17 @scribu
5 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I'm not sure why the code editors have stuck around for so long; wordpress.com probably uses entirely different code for allowing CSS editing by now.

Last edited 5 years ago by scribu (previous) (diff)

#18 @DrewAPicture
21 months ago

#23601 was marked as a duplicate.

#19 @westonruter
5 months ago

  • Keywords needs-patch added
  • Milestone set to 4.8
  • Resolution wontfix deleted
  • Status changed from closed to reopened

CodeMirror was originally proposed to be employed by the Custom CSS feature (#35395), but it was removed from what was committed due to the 4.7 timeline and the size of the library. In its place, a regular textarea was added with support for tabbing. Nevertheless, it is used by Jetpack for its enhanced Custom CSS feature. Having syntax highlighting and syntax error checking would be very helpful for users.

In addition to being used in the Custom CSS feature, having a proper code editor available would be greatly helpful for the file editor and also the HTML post content editor (as was raised during the Q&A at SOTW).

So, is CodeMirror the library that core should ship with and employ?

#20 @iseulde
5 months ago

Thanks @westonruter for reopening this. Cc @joen @azaozz.

Some other conversations: https://wordpress.slack.com/archives/core-editor/p1484239765000646 (scroll a bit down too).

We have talked about this lot for the text editor too and I'm leaning towards a yes to add a code editor there as well. In the case of the text editor, I would still keep the look more or less similar to what we have at the moment: a light (maybe even just greyed text) theme, no line numbers etc. In other words, no scary code editor feeling.

The benefits would be:

  • Syntax Validation. This is very useful for users who just want to change something small and are not that familiar with HTML.
  • Autocomplete tags. This might be especially useful if we want to drop auto-p.
  • Separate HTML tags and text with colour. Initially I though just greying out the HTML tags a bit would be a good default. We could format the HTML better too to make it more readable.
  • Switching mode without losing context. This has been a hard issue to solve with a text area, but if we use a code editor it's easy to scroll to the right part in either mode when switching.

I wouldn't add a code editor without making it a pure HTML editor. I'm not entirely sure what all the reasons were for adding auto-p all these years a go, but my guess is that:

  • It was annoying to add all the paragraphs by hand.
  • There was no visual editor, and it make it a bit more visually pleasant.
  • It would be noisy to have all the paragraph tags.
  • It would looks more like code and scary.

With just a text area these issues were hard to solve. But a code editor comes with many possibilities:

  • Autocompleting paragraph tags when pressing enter, which would be similar to the visual editor.
  • We can grey out the paragraph tags, or, more extremely even, make them invisible.
  • We can leave a margin between the top level tags so it resembles the visual side more closely.

So a code editor could also mean no more auto-p!

#21 @afercia
5 months ago

  • Focuses accessibility added

Adding the accessibility focus, especially for the "HTML post content editor" part.

#22 @celloexpressions
5 months ago

I'm not sure that we should lump custom CSS and the editor into the same discussion here other than selecting a library to use (that could potentially be used for both). They're fundamentally different experiences that will require very different things to implement. I'd suggest using this ticket to select and add a code editing library, then use separate tickets to implement it in the various places.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 months ago

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


5 months ago

#25 @westonruter
5 months ago

For code editor for Custom CSS, see #38707.

#26 @FolioVision
5 months ago

Hi Iseulde.

Adding a proper code editor would be a huge improvement to the core editor. I have some ideas about also splitting Visual into Preview and Writer but that's a bigger jump. You wrote:

So a code editor could also mean no more auto-p!

Yes to that. When we wrote Foliopress WYSIWYG (the low ratings came in a period where we were had decided to end of line Foliopress WYSIWYG and migrate to the core Editor. In the end we were unable to do so as too many complex posts were broken on save in TinyMCE. Most of our users stopped using Foliopress WYSIWYG during that period. It does work well enough that there were about 10,000 active installs at its peak) we contended with exactly those issues with WP auto-p. We ended up disabling auto-p completely. Yet we had to count on people turning our editor on and off. So we wrote some code (which is in the current editor) to deal with posts that are counting on WP auto-p in a resilient way.

We'd be happy to help with a migration forward which eliminates WP auto-p going forward yet does not break existing posts on open or require active intervention from end users.

Syntax colouring. For the new code editor to be truly useful, syntax colouring is essential. This mania for low contrast design is just a fashion trend. It will swing back. Form should follow function. I think a subtle colour scheme would be far more useful for WordPress publishers than a trendy low contrast look. I should add that for those users in their forties and beyond, low contrast is almost unreadable/unusable. For accessibility reasons alone we should include coloured syntax.

If you look at the full Ace Demo, there's a lot of skins available. I'd suggest both Eclipse and KatzenMilch could be subtle enough colour schemes to fit in well with WordPress.

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


4 months ago

#28 @westonruter
4 months ago

  • Owner set to georgestephanis
  • Status changed from reopened to assigned

Assigning out for initial core patch of CodeMirror integration based on prior art from Jetpack.

#29 @FolioVision
4 months ago

Hi Weston,

Thanks for the update. A couple of questions:

  • Why did we choose CodeMirror over Ace?
  • Is there any reaction to my suggestions about syntax highlighting (@iseulde Eclipse or Katzemilch as good options for WordPress)?

Thanks, Alec

#30 @jadpm
4 months ago

One fantastic side effect of including Codemirror as a core library is that all plugins developers would get to use the benefits of sharing an asset handle and a known version. Right now, using Codemirror in your project is faily common but dangerous as you end up with duplicated scripts of sometimes quite different versions.

This ticket was mentioned in Slack in #core by westonruter. View the logs.


4 months ago

#33 @westonruter
4 months ago

  • Keywords needs-patch removed
  • Owner changed from georgestephanis to afercia

Suspending developing in light of CodeMIrror not being accessible. Assigning to wait for feedback from accessibility team on GPL-compatible code editors that pass the accessibility test.

#34 @afercia
4 months ago

Just to confirm what was discussed on Slack yesterday (see link to the Slack logs above), here's a couple screenshots. Worth noting these kind of editors should be tested on Windows with NVDA or JAWS or other Windows screen readers, since VoiceOver uses a different interaction model.

As @westonruter pointed out, CodeMirror does not use contentEditable internally. Also, it "decouples" the underlying textarea from the presentation of the content. Basically the textarea is almost always empty.

Using a screen reader, when navigating content in "browse mode" (e.g. using the arrow keys): the textarea is hidden just visually so screen readers announce it and it's empty. After the textarea, the presentation of the editor content is announced as it was normal text in the page:

https://cldup.com/PwxwgTpEkD.png

When entering "forms mode" to operate inside the textarea, there's no content at all. As said, the textarea is initially empty and screen readers just announce "blank":

https://cldup.com/byJgt9dNxW.png

It is possible to enter content in the textarea, and the visual presentation gets updated with the new content but when trying to read out what you just entered, the textarea is empty again. This is because, in non-technical terms, CodeMirror clears out the textarea as soon as the arrows keys or Enter get pressed, since it needs to move the cursor in the visual presentation of the content.

Quick video where I've made the CodeMirror textarea visible to illustrate what happens under the hood: https://cloudup.com/iQRX47naOxY

#35 @FolioVision
4 months ago

Thanks for these notes Andrea.

Off the top, I always liked the ACE Code Editor. That said, it does seem to me that we could work around CodeMirror issue with screen readers. Either we could choose to mirror the content out to contentEditable or there could be an alternative source code editor provided when a screen reader editor for screen editors it seems to me would have widely different requirements for ideal behaviour than a visual screen editor.

Perhaps we could really improve the accessibility performance via automated substitution. There could be a hidden manual switch picked up by all screen readers just in case the automatic one doesn't trigger. Moreover, screen reader editing would be an ideal preference to pair with "Disable Visual Editor" in WordPress user profile.

#36 follow-up: @lukecavanagh
4 months ago

In relation to ACE and screen readers I did see this issue.

https://github.com/ajaxorg/ace/issues/2164

#37 @WraithKenny
4 months ago

Why not have a link/btn, much like "skip to main" that says, "disable highlighting for accessibility?"

This way, the enhancement wouldn't negatively impact users in any way.

P.S. or as @FolioVision said, "Disable Visual Editor"user option sounds good.

Last edited 4 months ago by WraithKenny (previous) (diff)

#38 @FolioVision
4 months ago

Thanks for that link Luke. That puts CodeMirror and ACE Code Editor on an equal footing in terms of accessibility. It sounds like visual code editors are exactly the opposite of what a screen reader/editor needs. Plain text would be much better than any of them.

Even more fabulous if WordPress could do better than plain text and insert the best screen reader/editor for those who use that technology while offering the best visual code editor for those who prefer that editor.

Alec

#39 follow-up: @westonruter
4 months ago

@afercia is there an established pattern to sniff out for whether or not a screen reader is being used and in that case just opt to not initialize CodeMirror/ACE/etc at all? If the textarea is best for accessibility, if we can just only progressively enhance the textarea with the code editing control when the user actually would benefit from it, that would seem like a good workaround.

#40 in reply to: ↑ 36 @afercia
4 months ago

Replying to lukecavanagh:

In relation to ACE and screen readers I did see this issue.

https://github.com/ajaxorg/ace/issues/2164

Thanks, interesting reading (especially the comments from Mr. Garaventa) that may help people understand why the technical choice implemented by CodeMirror and ACE is basically a hack.

In Ace we have textarea focused, which is used for capturing input and it's value is being reset after each keystroke. Visible text is not a part of the focused element, and selection is just a div.

Altering the native behavior of a control (in this case a textarea gets cleared out so there's no content to announce) actually means destroying the native level of accessibility that assistive technologies can understand. If there's really the need to alter in such a way the native behavior of a control, then it should be a developer's responsibility to rebuild that level of accessibility he/she just destroyed.

#41 in reply to: ↑ 39 @afercia
4 months ago

Replying to westonruter:

@afercia is there an established pattern to sniff out for whether or not a screen reader is being used

There is and it's: please don't do that :) Detecting screen readers is no different than sniffing browsers: difficult and unreliable. Additionally, there are some important ethical and privacy concerns to consider. Some interesting reading:

Thoughts on screen reader detection
Léonie Watson
http://tink.uk/thoughts-on-screen-reader-detection/

On Detecting Assistive Technology
Joe Dolson
https://www.joedolson.com/2014/03/detecting-assistive-technology/

Why screen reader detection on the web is a bad thing
Marco Zehe
https://www.marcozehe.de/2014/02/27/why-screen-reader-detection-on-the-web-is-a-bad-thing/

On Screen Reader Detection
Adrian Roselli
http://adrianroselli.com/2014/03/on-screen-reader-detection.html

Detecting Screen Readers – No
Web Axe
http://www.webaxe.org/detecting-screen-readers-no/

Aside: I've spent some time testing the accessible, alternative version of CodeMirror: http://bgrins.github.io/codemirror-accessible/
While it works decently with Firefox+NVDA, it is not ideal when using Safari 10 and VoiceOver and it completely freezes Internet Explorer 11 when using JAWS 17, at least for me.

I tend to think that only editors based on contenteditable can offer a decent level of accessibility. Maybe, even something like (cough) draft.js could work better, if only decorators for syntax-highlighting existed (couldn't find any, so far).

#42 @iseulde
4 months ago

Re: accessibility:

CodeMirror has a contenteditable input mode: http://codemirror.net/doc/manual.html#option_inputStyle. This might work better with screen readers.

Selects the way CodeMirror handles input and focus. The core library defines the "textarea" and "contenteditable" input models. On mobile browsers, the default is "contenteditable". On desktop browsers, the default is "textarea". Support for IME and screen readers is better in the "contenteditable" model. The intention is to make it the default on modern desktop browsers in the future.

#43 @afercia
4 months ago

Testing the "contenteditable model", will post first results as soon as possible. Seems to me all that's needed to get the different model is using the Chrome emulator with a "mobile" device. Alternatively, there's a quick Codepen kindly setup by @iseulde: http://codepen.io/iseulde/full/apxRzj/

#44 @FolioVision
4 months ago

Hi Andrea,

Thank you for the links to some existing viewpoints in favour of no special treatment. It may have been more efficient to summarise the arguments and support those arguments with links. For the sake of brevity, I'll take one of the more recent posts and respond to each of the writer's arguments in turn.

78.4% of respondents were very comfortable or somewhat comfortable with letting a web site know they are using a screen reader.

In my opinion, it should have been the other way around.

So those opposed to special treatment for screen reader users are more anxious about the issue than the people on behalf of whom they are advocating. I salute Marco's frankness.

It would take away the one place where we as blind people can be relatively undetected without our white cane or guide dog screaming at everybody around us that we’re blind or visually impaired, and therefore giving others a chance to treat us like true equals.

That a screen reader user interacted with a website comment section or even an admin interface via screen reader is not then printed beside their name on the author's bio or in the comments section. So for everyone except the screen reader's browser, that person is an equal. While it would be diabolical to print submitted via screen reader beside every comment of screen reader users, that is not what we are talking about. We are talking about giving screen reader users an enhanced interface for their interaction with web publishing. It's perfectly possible for screen reader users to give a different user agent and get a standard interface at any point.

Second, this is just a modern form of the text-only alternative web sites of the 1990s when screen readers were still learning to stumble around graphical user interfaces, let alone the web, and those text-only alternatives were a necessary evil to get anything done in most cases. In the early 2000s, as screen readers became better and browsers more modern, those faded away.

Actually those text version only content rich version of websites are back again. This time they are called AMP. We as web developers and publishers have failed so badly by overbuilding, over monetising and over tracking our and our client websites that even Google has given up on content parsing/separation and is insisting on a separate version with the content.

The current worst of the bad examples is the “accessible alternative” of the Audible.com web site. For one, its feature set is limited, and second, it constantly throws you back to the standard web presence, when doing searches, for example, and other totally screwed user experience snafoos. Or is there anyone out there who is actually wanting to tell me they enjoy this and find it even remotely useful? And to add insult to injury, the stuff that is currently a bit tricky on the standard web site can easily be fixed by some WAI-ARIA markup and some consistent keyboard navigation JavaScript.

In our case, we are not talking about building out the public facing side of the website with enhanced interface and tools. We are talking about the admin and content creation side. It's pretty clear that the ideal content creation tool for a sighted person will look and work differently than the ideal content creation tool for a visually impaired person. Each are using different ways to perceive and manipulate that content.

To say otherwise is to suggest that when using a screwdriver one use a hammer or the inverse. Or that everyone playing a racket sport should use a tennis rackets, regardless if you're hitting a tennis ball, a badminton birdie or a squash ball.

And the old arguments still apply: Alternative versions of web sites tend to get out of date, no longer being maintained, and creating and maintaining them is more expensive than properly applying markup and learning the web accessibility skill properly once.

Again, we are talking about the admin side and talking about adding a full-fledged and globally rolled out and maintained enhanced content editing interface for screen readers. I see far less chance of those users getting short shrift in a custom interface, globally available across WordPress than if we compromise the visual content editing tool on their behalf. That seems the worst of both worlds:

  1. a second rate code editor for sighted people
  2. no enhanced code editor for the visually impaired

Everyone should get the best tool for their work. Heck, over on the new editor thread we are dealing with issues of writing vs layout. There probably need to be separate editing interfaces for each of those activities or both modes will have to accept a seriously compromised experience. This is not about inconsideration to people with disabilities but about making their lives better and their work easier.

Third, there are security implications. Ever since I started working for Mozilla in 2007, there have been repetitive inquiries about exposing whether a screen reader is running with the browser, and if so, also granting access to the accessibility APIs to content JavaScript to manipulate what screen readers read to the user. Either of these would give web sites knowledge or exposure of operating system bits that, in every other case, would be considered unacceptable. You wouldn’t want to give web site JavaScript access to your file system, which type of keyboard you’re using, what brand your processor is, or if your machine still has a floppy drive or not, would you? Accessibility APIs hook into all kinds of channels to expose all the needed information to assistive technologies. Granting a web site access to these APIs would open a level of access to a computer that is just unacceptable, and unnecessary, for a web site to have.

This is a more delicate question. We must find a way to provide a secure experience for the code editor for both screen readers and non-screen readers. The security argument is equally relevant with a single code editor or multiple code editors (sighted and screen reader).

Aural style sheets never gained acceptance because the expected gain was just not there, and the desire to have equal access to the same content as everybody else was much stronger. More recent requests all are just the same thing in different disguise.

Again we are not talking about the front end of a website where a screen reader user would have reason to fear his or her needs being neglected. We are talking about a controlled admin interface where the screen reader user will be an equally privileged visitor with a uniform interface across websites.

Responsive design while it envisions a single code base for a website indeed includes device specific hacks within that single interface (bigger buttons for touch devices for example). Enhancing a responsive interface to create a better flow for screen reader users makes a certain amount of sense but again that is a front end issue and not what we are talking about here which is back end publishing tools.

[I hope] W3C will provide enough incentive for web authors not to abuse the querying mechanisms described, and that this will only be used by very well-informed sites where the developers provide actual value. The privacy examples in that document look at least promising. Let’s hope it all holds up until this becomes a standard one day. I, for one, will strongly discourage web developers who ask me from using this unless I am personally convinced they know what they’re doing. And yes, like with Location sharing, I will personally be very restrictive about allowing sites access to that particular information if I’m asked.

Again, we are talking about a content creation tool in the admin area of a website. As WordPress core developers, we could do much to discourage tracking of which users are using what (not adding any hooks for tracking for example, requiring modifying core to track which as we all know is a huge maintenance burden and something most casually evil publishers will be either technically incapable or too lazy to implement).

For the screen reader users who are truly wary of tracking we could still leave the plain text option available which works equally well or poorly for non-screen reader users and screen reader users.

I respect and agree with a principle of equality for all people regardless of sensory perception or any disability. Yet I cannot not buy into the argument of creating a worst of two worlds solutions for both screen reader users and non-screen reader users to make sure that neither side has a tool best suited for his/her use. On the contrary I see an opportunity for WordPress to forge a bold path forward with improved tools for screen reader users baked into the core editing product.

As there isn't a single best way (due to browser capabilities, specifically the best way of handling contentEditable) to build a code editor for screen reader users and non-screen reader users, we should also be talking here about what the best code editor for screen reader users is and not just about what the best code editor for non-screen reader users is. And after we do, we should figure how to integrate each code editor equally and seamlessly.

That is what we as a community can do to better the editing experience and publishing opportunities for screen reader users.

Anything else means starting from scratch, building from the ground up, losing a year or two of development and still in the end having to divide the capabilities even if it's nominally under a single code umbrella instead of two. Where possible stand on the shoulders of giants. In this case, two are at our disposition for non-screen reader users: CodeMirror and Ace Code Editor.

Who can tell us which are the giants of code editing in the screen reader world?

#45 @westonruter
4 months ago

Some seemingly great results on using the accessible version of CodeMirror: https://wordpress.slack.com/archives/core-editor/p1487436288004630

@georgestephanis
4 months ago

First patch at including CodeMirror.

#46 @georgestephanis
4 months ago

First attempt at including CodeMirror in a patch is attached.

Be warned, it's over 700k, as it's just the unminified sources (that will shrink significantly when they get compressed prior to release). I just cloned the GitHub repo, switched to the most recent release tag, npm install to build it, and then added/removed files from svn as seemed prudent at the time. Happy to add/remove others.

The current patch does two things:

1) Add and register the relevant scripts and styles
2) Implements them for the Theme Editor screen -- CSS and PHP files.

That should let us play around a bit and see how it works in practice for a11y and the like.

There are a lot of files that I left out of the patch -- some addons, and some languages. There were a few addons and languages we likely won't directly need, but I included because they were pretty small and would likely be useful for some plugin authors -- like the Markdown and SQL modes, for example.

Last edited 4 months ago by georgestephanis (previous) (diff)

#48 follow-up: @westonruter
4 months ago

@georgestephanis great! I opened a PR to collaborate on: https://github.com/xwp/wordpress-develop/pull/217

The remaining functional pieces would seem to be:

  • Incorporate with plugin file editor.
  • Utilize in Custom CSS customizer control.
  • Employ in HTML tab for the WP editor.

However, I realized that I hadn't actually done a search to see what plugins already exist that integrate CodeMirror, or another editor library, into WordPress. Doing a quick survey of plugins, there are several:

Good news is that CodeMirror came up over and over again in my quick search. But to move forward with incorporating CodeMirror and implementing it—for the theme and plugin file editor, content HTML editor, and the Custom CSS customizer control—I think we are first beholden to list out all of the plugins that already implement these fully and to loop in their authors to the conversation so that we don't reinvent the wheel, so we can incorporate the best of each of their plugins, and also so that we can be good neighbors since we'd effectively be deprecating their plugins.

All of this to say, it seems the next steps for this would be less technical and more communicative.

#49 follow-up: @afercia
4 months ago

As mentioned in the last dev meeting on Slack this should be extensively tested with assistive technologies. We'll discuss during next accessibility team meeting and probably ask the a11y testers group to test the current patch or the Codepen. In the meanwhile, I've done some first testing with screen readers and, although it's a bit early to make any judgment, first impressions are not so great. Seems navigating through content in the editor is extremely hard and I'd say it's a regression compared to the native textarea.

By the way, will limit to some first considerations about keyboard accessibility and semantics for now.

With keyboard only:
1
Usual known issue: since the tab key is used to enter tab characters, there's no way to tab-away from the editor. Keyboard users are "trapped" inside the editor. In the current Plugin and Theme editors, and in the Customizeer CSS textarea, WordPress allows to use the Escape key to tab-away. A similar solution should be implemented here too, not sure if this would require to hack CodeMirror.

2
Once the cursor is within the editor, some operating system-specific keyboard shortcuts are broken. Just a couple examples: on Windows, using Firefox, the shortcut Alt+D to move to the browser address bar doesn't work. On a Mac, Cmd+[ or Cmd+] to navigate to the previous/next pages don't work. I guess there are also other ones that are broken.

Semantics:
1
The editor is just a div. It should at least use role="textbox" aria-multiline="true" and an aria-label attribute with a proper value.

2
The autocomplete functionality:
https://cldup.com/3NLnDarDoL.png
it can be used with a keyboard but it's completely not accessible for screen readers. The drop-down list is just an unordered list without any ARIA treatment and nothing gets announced by screen readers.

#50 @georgestephanis
4 months ago

The conflicting keybindings aren't really a big issue -- they're trivial to rebind in implementation.

Marijn (CodeMirror developer) also remarked over email that

The contentEditable mode isn't rock-solid yet (especially on Android, which does some really weird things with input compositions), but it'll see more work in the next months, which should help with that.

@afercia -- I'm blocking off some time later this week to get on the CM github repo and try to submit a couple PRs to address some of your accessibility concerns.

Last edited 4 months ago by georgestephanis (previous) (diff)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 months ago

#52 in reply to: ↑ 49 ; follow-up: @FolioVision
4 months ago

Replying to afercia:

Andrea, what would be the gold standard in terms of a dedicated screen reader code editor? Is there one out there which does all of this and more really well?

@foliovision not that I'm aware of. We can do some research though. I think most of the issues are because contenteditable is still buggy and inconsistent across browsers. Add screen readers on top of that and you have an additional layer of buggy behaviours and inconsistencies. Even editors that have a complete different approach, for example draft.js, use contenteditable.

Last edited 4 months ago by afercia (previous) (diff)

#54 @FolioVision
4 months ago

Thanks for the links Luke. I particularly find useful Piotrek Koszuliński's essay ContentEditable — The Good, the Bad and the Ugly. Wow those Medium URLs are hideous and unreliable: let's never do that to URLs with WordPress. Here's a simpler working link which brings up both articles and any new ones about ContentEditable.

I found this section particularly relevant:

ContentEditable is like JavaScript, only Douglas Crockford hasn’t written a book about it yet. But (like JavaScript) it also has its good parts (yeah, I know — the good/bad ratio is debatable). It’s amazing that adding one attribute to an HTML element enables typing, selection, keyboard navigation, spell checking, drag and drop, pasting, undo manager. That all of this is integrated with the OS, that such editor can be used with a screen reader or on a touchscreen device and that it’s well internationalised. Let’s focus on these good parts and forget the bad ones.
Over the past years, while working on CKEditor I noticed that we were gradually replacing native features with our own implementations....It means that today CKEditor does not let the browser do anything to the content except handling typing, some deleting and that’s basically it. At the same time, it still uses the native selection system, keyboard navigation and other APIs such as those related to clipboard or focus management.


What this suggests to me is that any good JS code editor will be sufficiently complex that just pasting in some screen reader functionality will result in a not particularly sharp pencil. We would really be better off building a dedicated code editor for screen readers into our new code editor.

I would be very grateful if someone better versed in editing with a screen editor would share the gold standard for code editing with a screen reader so we could compare that ideal situation with where we are with the CodeMirror adaptation.

#55 @jorbin
4 months ago

Authoring Tool Accessibility Guidelines specify eight guidelines. Following each of these would likely be the "gold standard"

#56 @FolioVision
4 months ago

Thanks for the link, Aaron.

Aaron and Andrea, I'm a bit surprised to hear again about the guidelines when I'm asking about a gold standard implementation. What is the best existing implementation of accessibility for screen readers in a code editor? If we are to aspire to a better accessibility for screen readers, starting with the most successful screen reader code editor to date as a model would make the most sense.

If there are no good of implementations of code editors for screen readers, then we should say so and decide what is realistic to do within this round.

PS. On the other hand, if the best implementation is in CKeditor for example and we are determined to prioritise accessibility, perhaps it would make sense to move to the modular and fast iterating CKeditor from TinyMCE. CKeditor would give us perfect code support within the WordPress editor (hurray, no more mangled markup: even our venerable Foliopress WYSIWYG based on FCKeditor doesn't mangle markup) with even Markdown close at hand.

This ticket was mentioned in Slack in #core-editor by joen. View the logs.


4 months ago

#58 @iseulde
4 months ago

  • Summary changed from Include Ace (or similar) as default code editor to Include default code editor

This ticket was mentioned in Slack in #core by westonruter. View the logs.


4 months ago

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


4 months ago

#61 in reply to: ↑ 48 @WraithKenny
4 months ago

Replying to westonruter:

I use CodeMirror for just about everything in this plugin: https://wordpress.org/plugins-wp/scripts-n-styles/ and I'm willing to consult and contribute.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 months ago

#63 follow-up: @rianrietveld
4 months ago

We discussed this in the accessibility meeting and have the following options and concerns

  • there should be a no-js fallback anyways
  • not all users might like the syntax highlighting
  • it might potentially introduce accessibility barriers
  • the colours need to be checked for contrast and maybe adjustable
  • could slow load & rendering times
  • make it off by default or introduce a control to "switch" to the plain text editor

We gave this to the wpa11y test team to test.
We installed the patch with the codemirror on the test server and let them edit a template with this code editor.
I will report the results later, but what struck me the most was how worried blind content editors are, having the plain text editor changed and a new editor forced up unto them that adds extra clutter they didn't asked for.

And on a personal note:
It looks nice, if you are a coder and used to sublime text etc, but is there real value for the common user? It adds just ballast. Should WordPress provide this out of the box? Or is this plugin material. I think the latter.

#64 @FolioVision
4 months ago

Thanks for the notes Rian. It supports what I've written three or four times on this thread.

The needs of screen reader users (blind users for example) are completely different than non-screen reader users (sighted users).

Could we please, please focus on the needs of both groups instead of kneecapping both of them. Yes, they are equal but they are not identical. Treating them identical insults the needs of both.

We should offer a great solution to both groups, not a half solution to each.


Coloured syntax. Rian you wrote:

It looks nice, if you are a coder and used to sublime text etc, but is there real value for the common user?

You bet. The unreliable existing visual editor (which breaks any complex formatting you put into it) and equally unreliable drab text editor included out of the box are disheartening. Who the heck wants to work with broken/inadequate tools?

Clear coloured presentation of source code makes it much easier to edit a complex post or even for a beginner to determine what HTML tags are and how they work. A visual editor which doesn't reformat the text and throw out formatting on every save would be a boon as well for those trying to create complex posts (see the goals of the Editor team to see the level of complexity @iseulde is targetting as sample posts.

Trip to Switzerland
Snow Fall

which incidentally are directly lifted from Leigh Taylor's inspiration board for the new Medium editor, from back in February 2013.

Why in 2017 are we shipping second rate software? I'm facing coders quitting work as they are tired of working on WordPress as it's out of date technology which refuses to move into the modern era and runs like late 2009 software.

What will it take to wake core up to modern technology and better presentation? On the design side, core seems to want to stick to the indecipherable shades of grey design fad which has been poisoning readability on the internet for the last five years yet is already three years behind the times (current design is strong and simple colours with clear contrast).

Let's try and get ahead of the wave or at least on it, ladies and gentlemen.

#65 @rianrietveld
4 months ago

@FolioVision about your question

What is the best existing implementation of accessibility for screen readers in a code editor?

At the moment there is no code editor that works well with screen readers.
2 Weeks ago I listened to a talk by Florian Beijers (@zersiax on Twitter): Accessibility in software development tools. Florian is a blind software developer and he tested a lot of code editors and none performed sufficient for screen readers. So a plain text editor works best for screen reader users at the moment. Maybe in a few years this will improve, but not at the moment.

Last edited 4 months ago by rianrietveld (previous) (diff)

#66 @FolioVision
4 months ago

Hi Rian,

You wrote:

At the moment there is no code editor that works well with screen readers. 2 Weeks ago I listened to a talk by Florian Beijers (@zersiax on Twitter): Accessibility in software development tools. Florian is a blind software developer and he tested a lot of code editors and none performed sufficient for screen readers.

Could you get a wish list from Florian Beijers perhaps and we could build him one. There's enough talent in core Trac that there's nothing stopping us from building a good prototype screen reader editor. I'll admit that if we have to make it work properly within an existing code editor (no reason we should), the task is about ten times more complicated. But if we just focus on the screen reader experience we should be able get to working prototype within weeks.

I find it exciting that WordPress core might be able to make a substantial contribution to the screen reader editing experience and provide a prototype which other CMS could take and add to their own code edit module. We can change the world for the better.

#67 in reply to: ↑ 63 @WraithKenny
4 months ago

Has anyone in wpa11y used any editor or service on this list https://codemirror.net/doc/realworld.html and found it better than normal? If so we could look into whatever they've done. There's some big projects on that list, including Adobe Brackets (and Dreamweaver), Bitbucket, Prose.io (github content editor), Codepen.io, JSFiddle, jsbin.com, Firefox Developer Tools, WebKit Web inspector.

CodeMirror has dozens of themes, and it's just CSS so we can make some custom ones for Contrast and legibility if needed, or for branding.

It also has configurable keybindings with preconfigured options for Vim, Emacs, and Sublime Text bindings, if anyone from wpa11y has used those, and feels those keybindings are more accessible.

I think from this thread that the consensus is that the new editor should be opt-out. To achieve that, a button should be inserted before the editors (with js because it's a js enhancement), that would opt a user out, if the user hasn't selected a preference yet (neither yes nor no). Opting out should remove all CodeMirror instances and cleanup itself (including the buttons), and also post an ajax request to user preferences to remember the choice. (The preference will be available on edit user.) This would be the least obtrusive way I think. We don't need a no-js plan, as with js disabled, CodeMirror is disabled.

#68 @WraithKenny
4 months ago

JSBin has a ticket that relates to dealing with the issue. https://github.com/jsbin/jsbin/issues/936

#69 follow-ups: @FolioVision
4 months ago

Opting out should remove all CodeMirror instances and cleanup itself (including the buttons), and also post an ajax request to user preferences to remember the choice. (The preference will be available on edit user.) This would be the least obtrusive way I think. We don't need a no-js plan, as with js disabled, CodeMirror is disabled.

Nice thinking @WraithKenny for a quick patch. This is a better user experience and fairly seamless for everyone out there. We could also automatically disable CodeMirror for anyone coming in with a screen reader useragent (as it's no use to them). We should still think about building that better code editor experience with helpers for screen reader users. I'm not a screen reader user so I don't know what additional functionality screen reader users would like.

Hopefully @rianrietveld will come back to us from a wishlist (from Florian Beijers for instance). I'll ping him on Twitter now.

#70 @zersiax
4 months ago

You called? ;)
Ok ...so I had a quick read through this thread and I am seeing things I both agree and disagree with.
Basically the talk I gave was about a number of code editors both on and offline, I covered Atom, Vs Code, CodeMirror and a couple of others. The only editor I am very slightly surprised by in a good way is Orion: https://orionhub.org/

That's slightly overkill for WordPress though. Most of the things I could say about that have already been stated, namely:

  • ContentEditable is currently the only dynamic way I'm aware of to even make anything resembling a dynamic editor that's accessible to some degree, however as people have pointed out it's buggy and browser support varies quite a bit depending on what platform you're coming from.

A multiline edit field, the other side of the spectrum, is fine for screenreaders but does not give sighted users any form of syntax highlighting or autocompletion. When I see people implement Codemirror I tend to suggest to add a multiline edit field that either submits the code to the endpoint it needs to go to itself, or copies the written code to the codemirror instance on blur. This multiline edit field would only need to be visible for screenreaders, there's a myriad of ways to accomplish that.
Now I'm not saying that is an ideal solution, its a patch at best, but it helps those websites by giving them something to work towards. What you guys are doing is radically different in the fact you either want to make an editor from scratch or modify an existing one. My wishlist for an editor with accessibility functions really doesn't deviate all that strongly from any of yours, I reckon, namely:

  • Autocompletion that actually works/reads
  • Quick way of navigating through the code, be it by tag, by function, etc
  • If there are visual live announcements of errors or mistakes on a line, I would like to know about them
  • Syntax highlighting is obviously something screenreaders can't really do anything with and there is no standard way of fixing that, so that one is not on my list.
  • If there are controls in/around the editor, I want these controls to either be keyboard accessible or have a keystroke attached to them that is discernible in an easy way.

Now this list is a sketch of an ideal situation. I haven't found any code editor, off or online, that does all of this, and I'm genuinely not sure if the web is the platform to build the first such editor on. But if you wanted a wishlist , here it is :)

#71 @FolioVision
4 months ago

Thanks for your wishlist @zersiax!

We can agree that the editor exposed to screen reader users - if we are going to beyond plain text - should have the following features to be an improvement over plain text:

  • Autocompletion
  • Quick navigation through the code (guessing this should be a next and previous <n-tag>
  • Syntax errors available (a keystroke to hear about them)

There wouldn't be controls in/around the editor out of the box as this is a custom editor but if such controls exist in the final CodeMirror implementation of course they should turn up in the screen reader editor. Thank you for the reminder.

The next step now would be to find existing good implementations of those three features, either online or in an offline editor.

You wrote:

I haven't found any code editor, off or online, that does all of this, and I'm genuinely not sure if the web is the platform to build the first such editor on.

Would it be possible for you to give us a list of the code editors which do at least one of those features (and which ones) well so we could see the existing best prior art? Or if you cannot, perhaps you know some other experts who could give us such examples.

Thank you very much for providing much needed front line expertise on the screen reader code editing experience.

#72 in reply to: ↑ 69 @afercia
4 months ago

Replying to FolioVision:

We could also automatically disable CodeMirror for anyone coming in with a screen reader useragent (as it's no use to them).

I wouldn't recommend that. First of all, for privacy and ethical reasons, I wouldn't support screen readers detection. Recently, there was some discussion about this issue on Slack and some important references are mentioned on this same ticket, see comment:41 so I'll keep it short and won't repeat the same argumentations. Apart from that, from a technical perspective I'm not sure there are ways to detect screen readers, so this discussion seems to be purely academic.

Also, thinking that screen readers are used only by blind people it's a common assumption, and it's wrong. There are a lot of people with low vision who use screen readers as an aid and for them CodeMirror could be of same use.

Lastly, I'd like to remind that the accessibility team recommendation, as @rianrietveld summarised in comment:63, is to make the new code editor preferably off by default. As a second, not ideal, option: on by default with an easy to discover "switch" to the plain textarea.

@zersiax thanks very much for your feedback. What about joining the a11y team and help us coding some a11y improvements? :)

#73 in reply to: ↑ 69 @joedolson
4 months ago

Replying to FolioVision:

We could also automatically disable CodeMirror for anyone coming in with a screen reader useragent (as it's no use to them).

You've mentioned the idea of a 'screen reader user agent' a couple of times now, and I want to make sure it's clear that there is no such thing as a screen reader user agent - a screen reader sits between the operating system and the user agent, and the user agent string received from the client is indistinguishable from any other user agent. Detecting a screen reader is not something that's currently possible, regardless of any other ethical considerations.

#74 @zersiax
4 months ago

ok :) So, a few things to respond to.

Editors that do some of the things I mentioned wel:

  • The autocomplete in Visual Studio Code, I think, is the best implementation you're going to see in any web platform. Full disclosure: I had a hand in that one ;) I also really like the autocomplete in Visual Studio itself, its one of the more useful ones out there imho.
  • As for syntax error reporting, you misunderstood me there. I don't want a hotkey to tell me about syntax errors, thats akin to compiling and praying for the best, which arguably is the way all other editors make me do it so far. So I don't really have a lot of examples on how to do this for you. What I am looking for is a mechanism that tells me about a syntax error as it happens, just like the visual indicator would show you the syntax error when it is found. The way I imagine this is hearing something like "<img sc="blah.jpg"> , has error" . I am thinking a hotkey to query what error was found would be useful, though. The only editors I know of that do this to some degree are Emacs with the emacspeak addon and Sodbeans, but Sodbeans is buggy in all sorts of other ways.

As for joining the a11y team, I would but I'm absolutely swamped right now :) Perhaps in a few weeks when the laser robots stop hounding me :)

#75 @FolioVision
4 months ago

@afercia I've made very substantial arguments in the posts above about how not offering a custom tailored alternative code editor for screen readers is simply not fair to the people who use screen readers - as well as crippling the main WordPress code editor for those who don't use a screen reader. The notion that it's some kind of violation of screen readers' rights to give them a superior editing experience is absurd.

The notion that a code editor for non-screen readers would work well for screen readers is belied by the state of code editing software. There is no good combo software. It's not an accident. If we want to provide a better code editor experience, two code editors are required (1).

Your proposed approach is forcing us to the lowest common denominator. Hurray, another plain text editor for WordPress! Hurray the plain text editor for WordPress turned on by default! Not only that but current state of the art in WordPress is that neither the visual editor nor the plain text editor are reliable due to wpautop. The worst of all possible worlds. Let's clean up WordPress's act in terms of:

  1. handling text (as a start, wpautop should disappear so that switching between visual and text does not break formatting)
  2. providing powerful tools to our users.

My company has spent a lot of treasure and time creating and maintaining an open source alternative WordPress editor which does not break pages when one switches between visual and code (Foliopress WYSIWYG). With the new WordPress editor and code editor, I'd like to:

  1. provide all WordPress users with a great editing experience.
  2. no longer have to maintain an extra complex tool ourselves.

Moreover, I totally disagree about turning off the new code editor by default and pushing people back to plain text. Why build great tools and then feed people plain porridge by default?


@joedolson You make a very good point:

I want to make sure it's clear that there is no such thing as a screen reader user agent - a screen reader sits between the operating system and the user agent, and the user agent string received from the client is indistinguishable from any other user agent. Detecting a screen reader is not something that's currently possible

Thanks for the reminder. Afercia suggested:

As a second, not ideal, option: [new code editor] on by default with an easy to discover "switch" to the plain textarea.

Could we not make the reading path for the screen reader go right past a sign post which says:

For a better screen reader code editing experience, press C now.

This announcement doesn't even need to be more visible than a i sign to non-screen reader users.

Pressing C every time they use a code editor would be tedious for screen reader users who use a code editor frequently. While screen reader users could anticipate the announcement when opening up the code editor with a pre-emptive press so it wouldn't necessarily be all that bad, there should still be an editor preference for a low-fi, screen reader enhanced editor within a user's profile.

Let's strive to make screen reader users' lives better with a code editor which gives them controls and shortcuts which will make their work easier.

In terms of maintaining a level playing field, it would be a fair condition to add to the new code editor development to make that CodeMirror or other syntax highlighting editor can not be introduced until the new screen reader code editor has been built and introduced. By the same token, the targets for this brand new code editor should remain achievable. The goal is not to stall the introduction of an improved code editor for non-screen reader users but to accelerate the release of a better code editor for screen reader users.


  1. Faking a single editor by hiding visual functionality from screen reader users and hiding screen reader functionality from sighted users would still be two code editors but just raise the coding and maintenance burden five or ten-fold. It would also mean that we would always be incompatible with upgrades to CodeMirror or ACE or whichever code editor we choose. Improving the interaction between the two edit modes (screen reader mode, visual) would be an ongoing opportunity. Over time and with more interaction, someone is likely to have some brilliant ideas. To get to that point though, both code editors have to be completed and released.

#76 @zersiax
4 months ago

You make some good points. Overall, I am a proponent of trying to make mainstream tools work for screenreaders, there's a huge amount of reasons I could list for that. I'm not sure if I agree with the fact that it's not an accident a combo editor was never created; that seems more like a supply & demand problem to me.
I know loads of code editors that either don't build in access features because they don't have the bandwidth, or the knowledge, or the money, or the time , or the incentive, or the myriad of other excuses I see over and over and over again when I ask.
In this day and age, where most phones have a screenreader built in, most pc's do as well and more and more "mainstream" tech is introduced that actually is usable by the blind, what are called 'blind ghetto' products are becoming less and less popular. Creating a specialized editor for the blind seems to make sense, but do keep in mind that this introduces quite a bit of overhead for maintaining the two editors in sync. E.G., the specialized editors will likely require a lot of accessibility markup that not everyone is familiar with, so if the folks who built it decide to leave for the nearest space dock, we do have a problem.
I wouldn't say it's impossible to create an editor that caters to both groups; if you look at my wishlist above, you'll find that a lot of the things I put down aren't specific to accessibility. They are just features you guys have had forever that I would like to see made accessible, or at least unobtrusive enough to stay the heck out of my way if I can't use them anyway ;)
There is a case for creating a low-fi text editor for the folks who don't want extra complexity in their lives', the lowest common denominator as you mentioned, but I think that would impede progress quite a bit. I would like to add to that however that we should only replace that "dumb" editor if we have a better alternative, better in this case being better for everyone. If you want to go for progressive enhancement, perhaps in the next few minor version upgrades the installer should allow for an editor to be selected until we are certain we can deliver a good editing experience for everyone.

#77 @FolioVision
4 months ago

Thanks for your thoughtful comments @zersiax. I took a day to think carefully about what you said before answering.

I wouldn't consider upgrading the plain text editor to be an amazing screen reader editor, a ghetto product. In terms maintenance, I would hope the chances of this editor failing would be lower than for the visual code editor as the additional code burden would be so much smaller than for the visual code editor as it would not be dependent on an external project and would not carry nearly as much overhead. Simpler if often better.

The product model I would suggest then would be visual editor/visual code editor as one stream with screen reader editor/plain text editor/no javascript editor in the other stream. When javascript is enabled and visual editor is turned off, the advanced functionality for screen reader editors would leap into action. If javascript is disabled this version would simply become a plain text editor with no need to reload the page. There would be no visual editor at all in this case.

features you guys have had forever that I would like to see made accessible, or at least unobtrusive enough to stay the heck out of my way if I can't use them anyway ;)

Within the new edit module being built from scratch with custom blocks, accessibility should be built in from the beginning as it's a clean field build and screen reader writers should have access to the same blocks (albeit with a different interface) as sighted users. I'm not sure we should call the main WYSIWYG editor a visual editor as it should be an editor for everyone. Perhaps "Preview Editor"? Again that word "view" but a view does not have to happen only through the eyes. A view is a way of perceiving things.

After the screen reader editor experience had been made much better and the new visual code editor tamed (in a year and a half or so), it would be a lot easier to integrate the finished functionality into the visual code editor. Or if not, at no point would screen reader editors have had a worse experience. You will always have the best dedicated additional functionality which can be built with autocomplete and live syntax error notifications.

Your idea of allowing a choice of editor when you create an account or install a site makes good sense to me.

#78 @comfortking
3 months ago

It really, really irritates me that we're ALL stuck with a piss-poor editor in a feeble attempt to cater to the tiny, tiny, tiny, tiny minority of people that use screen readers. What is it - .000001%?

How about majority rules. If you need a screen reader it's YOUR responsibility to figure it out - not the other way around.

This is why nothing meaningful gets done by core.

#79 @zersiax
3 months ago

@comfortking At the risk of feeding the trolls, I will bite this once. Looking at your statements I can conclude a few things about you, feel free to correct me if I'm wrong.

  • You think only covering the happy path is a good idea. Internationalization is useless because everybody speaks English, security is a myth because only 1 in x of all WordPress instances actually get hacked. And yes, I know you are a translation contributor. Sweet irony, innit?
  • Designs for people who don't use high resolution screens are not necessary, everyone should just get better screens.
  • Loading time of pages really doesn't matter in the grand scheme of things either, everybody is using a 100 mbits fiber connection after all
  • Complaining at the world is the way to get things done/fixed, judging by your submissions listed on your profile page.

These are all generalizations in the same vein as the completely ridiculous one you just spouted. I will thank you to not insult me and many others who use a screen reader again by turning us into non-entities.
Guess what, there are quite a few screen reader users who use WordPress, either by choice or as a requirement for a job they're doing. There are also quite a few screen reader users who are developers, programmers, software engineers and computer scientists, who also work with WordPress for a variety of purposes. These people, if your comment is to be believed, have no right to use the platform the way it was meant to be used. Thank you for making that decision for us, but nobody made you king.

I would've taken this up with you privately but there appears to be no public contact details available to reach you at. I've said all I thought needed to be said, now let's get back to the actual topic at hand. Pointless bashing and personal attacks never got anyone anywhere and this has a high potential to turn into a useless flame war on the ethics around making products accessible. To be very honest with you, I can think of about a dozen better uses of my sunday afternoon

#80 @rianrietveld
3 months ago

Hi all,
The issue here is not if this needs to be accessible or not.
WordPress agreed last year that everything that goes into core has to comply with WCAG 2 AA.

WordPress runs plus 25% of the web, lets make careful divisions, this impacts a lot of people.
We need to find a solution that works for all users, it's a bit of a puzzle, but that's part of the job.

#81 @FolioVision
3 months ago

Let's not allow the extreme troll arguments to upset the apple cart. Our goal here should be to create the best possible code editor experience for screen readers users and for non-screen reader editors.

I've done some more experimenting with screen readers. From my hands on experiments, the best possible experience for screen reader users is a tool which caters primarily to screen reader editors.

If we continue to cripple the main code editor in WordPress, zersiax and rian, in effect we are validating the arguments of someone like comfortking, and saying WordPress is a tool only for people who use a screen readers (as we are unwilling to give state of the art tools to those who don't use screen readers).

Let's get to work on building additional tools around the plain text editor to add useful functionality for screen reader users.

#82 @afercia
3 months ago

I'd strongly recommend everyone taking part in this discussion to spend a few minutes of their time and watch the following videos (or, better, actually test with assistive technologies) to get an idea on how non-standard solutions fail with software that expect correct HTML, proper semantics, and predictable interaction models.

Admittedly, these are just partial tests with just one screen reader and a speech recognition tool. However, they both result in a strongly increased difficulty when using the editor or even in the complete inability to enter text.

Tests run on the Theme editor with the patch from this ticket applied and on this codepen: http://codepen.io/afercia/full/pRBxwd/ where the only difference is that it uses an ARIA role: "textbox", an "aria-multiline": "true", and an aria-label attributes.

Dragon NaturallySpeaking
Tests recorded by Graham Armfield at WordCamp London 2017

Theme editor with CodeMirror, compared to the Post editor simple textarea: the most basic operations fail, while they perfectly work on the standard textarea.
https://youtu.be/AfWyqMCXI9I

Codepen: basically the same results, also highlighting how the focus indicator (caret) and the actual insertion point are often disjointed
https://youtu.be/b03tGluQiCo

Testing Safari 10 + VoiceOver on the Codepen
Apart from sometimes losing the insertion point, it's pretty evident that, when navigating by word or by character, VoiceOver gets stuck when it encounters a line number:
https://www.youtube.com/watch?v=QSW2CZkOaSI

When removing the line numbers, things work a bit better:
https://www.youtube.com/watch?v=Rz6X1JMBlBk

Will try to follow up with some more generic considerations soon.

Last edited 3 months ago by afercia (previous) (diff)

#83 @rianrietveld
3 months ago

During the contributors day at WordCamp London we discussed and tested the mirror code editor and discussed the use of any other code editor or syntax highlighter with @afercia @grahamarmfield @samikeijonen @rianrietveld and Adrian Rosellihttp://adrianroselli.com/bio.

For the test results, see previous comment by @afrecia

Result of the discussion

  • We are changing a key interface on the platform, users have expectations about how things work and are now confronted with a complete different design. This not only affects users with assistive technology, but all users of the Text interface.
  • The new interface is useful but should not be implemented by default, we have to inform users of the new interface with an opt-in to use it. So the new interface should not be switched on by default but selected in the settings, for example now with distraction-free mode.
  • It would be useful to measure how many users use which interface (WYSIWYG / Text / Code editor). Is there data from WordPress.com how many user use the text editor?
  • An accessible code editor wil take a long time to develop, it will be a huge undertaking. If a code editor will be added to core, users must have an accessible option (like the current Text editor) by default.

So overall
A code editor is useful, no doubt about it, but it should be implemented as an opt-in and not as default until there is an accessible version available.

Last edited 3 months ago by rianrietveld (previous) (diff)

#84 @jorbin
3 months ago

  • Keywords close added

With it seeming more and more like an accessible code editor isn't going to be a possibility, and the WordPress standards require that all new code conform to WCAG 2.0, I think we should close this as maybelater and consider it plugin territory until such time as an editor that all users can use is available.

#85 follow-up: @lukecavanagh
3 months ago

@jorbin

Would there be a code editor that all users could still use?

#86 in reply to: ↑ 85 @jorbin
3 months ago

Replying to lukecavanagh:

@jorbin

Would there be a code editor that all users could still use?

The current textarea one.

#87 @lukecavanagh
3 months ago

@jorbin

So if the current text one, is that going to be improved at all, since the text editor is still used a fair bit. I know the visual editor has https://github.com/WordPress/gutenberg

#88 @jorbin
3 months ago

This has nothing to do with the visual editor changes (such as those being explored by gutenberg). By closing this and marking it maybelater, it allows energy to be focused there.

#89 @lukecavanagh
3 months ago

@jorbin 

I was just asking if there would be any focus on the text editor in core?

#90 @melchoyce
3 months ago

This is a big blow to improving the CSS editor in #38707. I'd recommend against closing this ticket just yet.

#91 @afercia
3 months ago

I'd second @jorbin's proposal to close this ticket as maybelater. Apart from the technical issues we've proven with real testing, I'd also like to add some general considerations.

Just my 2 cents of course, but I think this kind of decisions should be based on actual data. I haven't seen any data to support the introduction of a code editor with syntax highlighting. The only rationale mentioned was that the introduction of this feature was "raised during the Q&A at SOTW". Aside: please expand abbreviations since not all the people reading this ticket may know what "SOTW" (State Of The Word, during WordCamp US 2016 I guess) means.

I'd argue the audience at the State Of The Word is really representative of the WordPress user base, since it's typically made of people with good technical knowledge or, at least, by advanced WordPress users.

At the risk of sounding a bit pedantic, I'd also like to remind some of the points of the WordPress philosophy, as it seems, as developers, we sometimes tend to forget them.

https://wordpress.org/about/philosophy

Design for the Majority
Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for as they are ultimately the ones who are going to spend the most time using it for what it was built for.

Clean, Lean, and Mean
The core of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast and will always stay that way. We are constantly asked "when will X feature be built" or "why isn’t X plugin integrated into the core". The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.

Apart from accessibility-related considerations, I personally feel the feature proposed on this ticket doesn't fit with these principles and therefore I'd consider it plugin territory.

#92 @FolioVision
3 months ago

Aaron (@jorbin), the current editor is horribly out of date scrap code which is totally uninspiring and hardly usable. No wonder no one uses it. As you noted, the amount of energy going into the Medium-copycat visual editor is enormous (fancy names like Gutenberg don't make it any more original). The work done there is no excuse for not integrating a high quality code editor like CodeMirror which is a relatively easy task.

WordPress users have been waiting seven years for a better code editor. The people participating in this conversation didn't invest their time and focus now just to have a core committer try to sweep the mess under the carpet again.


@rianrietveld You wrote:

We are changing a key interface on the platform, users have expectations about how things work and are now confronted with a complete different design. This not only affects users with assistive technology, but all users of the Text interface.

You can't be serious? Do you think there are any sighted users of the WordPress code editor who could not figure out how to use highlighted syntax? That's the main gain with a better code editor. And small visual and functional tweaks here and there. Syntax highlighting is an immediate improvement in usability.

Yes, a code editor with visually highlighted syntax does nothing for users with assistive technology. Hence the current plain text editor should get enhancements as discussed in depth above with @zersiax.

So it's really come down to there are some people with limited vision (or no vision), therefore the rest of us will get no visual cues when editing. It's something like insisting that as athletes with legs have an advantage over athletes without legs, we are now going to cut everybody's legs off. I deliberately avoided making such a comparison earlier as we should all be able to work together without undercutting one another's work or software experience. We should work together to add a code editor with visual highlights AND at the same time enhance the plain text code editor for those who use screen readers.

Surely the unrelenting focus of the accessible group is not to bring everything down to lowest common denominator?

It's funny you bring up distraction free mode.

The new interface is useful but should not be implemented by default, we have to inform users of the new interface with an opt-in to use it. So the new interface should not be switched on by default but selected in the settings, for example now with distraction-free mode.

Distraction free mode needs to be enabled every time you want to use it and is more a distraction than a help. Everyone hates it. Where the switch needs to be is in user preferences next to the Visual Code Editor checkbox where there should be a clear option to choose either:

  1. text based code editor enhanced for assistive devices.
  2. visual code editor with syntax highlighting.

I know ahead of time which version 99% of users would find more useful. So do you. Numbers aren't everything: it doesn't mean that the enhancements to the text based code editor are any less important. Still numbers and utility are something.


With @afercia's intervention I see there is a concerted effort from core to leave WordPress users with a really crap code editor. Do our core principles include:

  • staying almost decades behind state of the art interfaces
  • not taking advantage of the hard work of other open source project (Mozilla's Ace, CodeMirror)
  • a not made here mentality (if we don't code it from scratch, we're not interested)

I cannot believe programmers are writing with a straight face that syntax highlighted code editor view is not a significant improvement (it would be perhaps the most significant improvement in WordPress in the last three iterations, after retina image support in 4.4).

Let's try and get this show back on the road in a positive way. The time has more than come for syntax highlighting in code view in WordPress. The time has more than come to retire wpautop and for code integrity when switching between visual and code mode in WordPress. It would be great to join the post-2010 CMS and editing world. It's 2017 already, mesdames et messieurs.

#93 @WraithKenny
3 months ago

Well. I'll check back in with WordPress in another 7 years, if it still exists.

#94 @afercia
3 months ago

@FolioVision @WraithKenny the discussion on this ticket is full of personal opinions (always welcomed) without any actual data to support them. I'd strongly encourage to prove with data the real need for a syntax highlighting feature which, by the way, it's not the only feature CodeMirror has. I'm open to change my mind when someone can prove CodeMirror would be appreciated and actually used by 80% or more of end users.
As I see it, these kind of comments don't add any positive value to the discussion and just repeat thoughts already expressed on previous comments.

Also, comments that sound like personal attacks ("You can't be serious?"), or terms like "crap", or sarcasm, are not welcome here.

#95 follow-ups: @melchoyce
3 months ago

My concern is primarily around improving the CSS Editor in the Customizer. It is, quite honestly, a painful experience currently. Going between writing some CSS on WordPress.com and writing some on my self-hosted sites is not fun. The mockup here: https://core.trac.wordpress.org/attachment/ticket/38707/customizer-css-i2.png is very clearly an improvement on the existing CSS editor in core. It makes CSS easier to read, write, and maintain.

Anecdotally, Jetpack's CSS editor is something I constantly recommend at local tech community project nights, where the vast majority of people I help tend to be beginners making WordPress websites. They're generally either currently learning, or already comfortable with, CSS. I'd like to be able to recommend using core's CSS editor, but I can't, because it's a significantly worse experience. I'd like to be able to use it for myself, instead of immediately reaching for Jetpack.

Having a way to edit CSS in core is waaaay better than nothing, but it needs to be improved.

#96 follow-up: @FolioVision
3 months ago

Thank you for your input, Andrea. Measured argument was attempted earlier (please see my earlier comments). When a sensible (but unwelcome) consensus was reached via open discussion, there were closed door meetings held. From here it looks like those at those meetings then decided as a group to close this ticket.

Tag team discouragement from core committers is no more welcome among the community than sarcasm from junior members. The disastrous current code editor is overripe for replacement (seven years overripe). Suggesting that a decent code editor along with reliable shifting between visual edit view and code edit view is not a highly desired feature doesn't sound very likely to me.

Now of course if the goal is to kick the can down the road so that any new code editor has to come in Calypso or in order to enjoy a modern editor a user must to install Jetpack, you and Aaron and Rian have put in a very good day's work today. Personally I believe in a powerful and modern core WordPress which can stand on its independent legs, not in maintaining crippleware for Automattic to turn into SAAS. Good editing tools for me are definitely not "plugin material". This is core capability.

From what I understand our goals align on that point. But a strong independent WordPress means an up to date and capable WordPress. We are supposed to be on the same side. The underlying point is that the current editing tools in WordPress do not belong in a modern CMS nor should assistive device users have to struggle along with a tool focused on non-assistive device users (the current text editor which provides an all-round poor experience for everyone).

Here's my positive proposal: I'd like to see us integrate CodeMirror (not my first choice, I preferred ACE originally) and simultaneously improve the plain text editor to add the top three features for assistive device users.

#97 in reply to: ↑ 95 ; follow-up: @jorbin
3 months ago

Replying to melchoyce:

My concern is primarily around improving the CSS Editor in the Customizer. It is, quite honestly, a painful experience currently. Going between writing some CSS on WordPress.com and writing some on my self-hosted sites is not fun. The mockup here: https://core.trac.wordpress.org/attachment/ticket/38707/customizer-css-i2.png is very clearly an improvement on the existing CSS editor in core. It makes CSS easier to read, write, and maintain.

Anecdotally, Jetpack's CSS editor is something I constantly recommend at local tech community project nights, where the vast majority of people I help tend to be beginners making WordPress websites. They're generally either currently learning, or already comfortable with, CSS. I'd like to be able to recommend using core's CSS editor, but I can't, because it's a significantly worse experience. I'd like to be able to use it for myself, instead of immediately reaching for Jetpack.

Having a way to edit CSS in core is waaaay better than nothing, but it needs to be improved.

Having just used the CSS editor on a site, I agree that it's far from an optimal experience. I also agree that when I chat with end users and site builders, it's something they find beneficial (but not super easy to use without some more advanced knowledge).

Just looking at the text field piece of that mockup (and ignoring the interaction enhancements), it seems there are two components that set it apart from what is there now: Line numbers and syntax highlighting. Is that correct? if so, those two things could be looked at separately and we might be able to find accessible ways to implement both.

#98 @FolioVision
3 months ago

Aaron, if we are going to add syntax highlighting for the CSS editor, why on earth would we not implement it for the main code editor? You have me very confused at this point.

Working with code anywhere in WordPress is a "far from optimal experience". Let's fix it everywhere.

#99 in reply to: ↑ 96 @jorbin
3 months ago

Replying to FolioVision:

Here's my positive proposal: I'd like to see us integrate CodeMirror (not my first choice, I preferred ACE originally) and simultaneously improve the plain text editor to add the top three features for assistive device users.

If your goal is to use a specific library, I would encourage you to spend your time ensuring that it passes the WCAG 2.0 AA standards. At that time, it seems like something we can consider. Until then, you are proposing that WordPress should violate the standards it set for itself a little over a year ago (and that zero people objected to when proposed). If you would like to propose that the standards be different, the original post has comments open.

#100 in reply to: ↑ 97 @melchoyce
3 months ago

Replying to jorbin:

Just looking at the text field piece of that mockup (and ignoring the interaction enhancements), it seems there are two components that set it apart from what is there now: Line numbers and syntax highlighting. Is that correct?

Correct, along with auto-tabbing. In an ideal world, we'd also add auto-closing brackets, and maybe some basic syntax/error checking.

if so, those two things could be looked at separately and we might be able to find accessible ways to implement both.

That's good enough for me.

#101 follow-up: @FolioVision
3 months ago

Aaron, we've been through all of this above. Here's the gist of the situation with code editors:

Visual highlighting is not of much use for screen reader users. Hence visual code editors authors don't bother much with WCAG 2.0. They know screen reader editor users are better served by plain text code editors or plain text code editors with some additional functionality.

Logically, WordPress should do the same. Put in the visual code editor for those of us who can use it AND at the same time improve the plain text code editor so it better meets the needs of screen reader editors. Particularly when it's very easy to allow people to choose which tool suits them better.

I know you are a clever man so it seems to me pointing to the accessibility guidelines is a deliberate attempt to obscure the issue. I don't disagree with the core of the guidelines. In this case, we can have our cake and eat it too. Both sides will be better served by offering specific and better tools to each side.

I've even agreed that over time we should do additional work on upgrading accessibility within CodeMirror. Perhaps eventually we will be able to make it do both functions at the same time (enhanced visual code editing, enhanced screen reader editing). From what I've seen (I've followed this conversation very closely and done some experimenting on my own) setting this as a priori is a very steep hill to climb and basically dooms us to poor quality editing tools for almost forever.

Not separating the code editing tools in this case would be a lose-lose situation.

#102 in reply to: ↑ 101 @jorbin
3 months ago

Replying to FolioVision:
It's not about screen readers or any other assistive technology, it's about people. If you watch the test videos, you'll see that people are blocked from completing tasks by the changes you are advocating for.

If you disagree so strongly with the importance of creating a product that is usable by everyone regardless of disability, you may wish to find other open source projects to contribute to. There are plenty of other open source projects that are less focused on being usable by all.

#103 @FolioVision
3 months ago

If you disagree so strongly with the importance of creating a product that is usable by everyone regardless of disability, you may wish to find other open source projects to contribute to. There are plenty of other open source projects that are less focused on being usable by all.

Disagree with a core committer and be told to leave the project. How strange that people are getting frustrated working with and/or contributing to WordPress. No worries, Aaron, I've been working with WordPress since 2005 and building advanced plugins for WordPress since 2006. A sharp word from you won't make me give up.

In any case, I do not disagree with creating a product which can be used by everyone regardless of disability. You deliberately twisting my words. Let us not forget the goal is not to blindly implement guidelines but to make the product better for everyone.

It surprises me that a Visual Code Editor button in my User Profile along with syntax highlighting would confuse anyone. I'll watch the test videos attentively and be back with some more practical feedback on how to surmount these issues.

#104 @rianrietveld
3 months ago

My 2 pennies, I won't reply after this anymore:

  • a code editor will be very useful and personally I would use it a lot
  • it will take a lot of time and effort to create an accessible one
  • if you really want this, develop a plugin, we can test it without forcing it up onto people, we also can monitor how often the plugin is installed
  • if the plugin turns out to be very populair we can spend time to make it accessible before integrate it into core.

#105 in reply to: ↑ 95 ; follow-ups: @afercia
3 months ago

Replying to FolioVision:

I'll watch the test videos

You haven't yet? :)

Replying to melchoyce:

My concern is primarily around improving the CSS Editor in the Customizer. It is, quite honestly, a painful experience currently.

Dear Mel, I understand your point and I think we're all here to try to introduce improvements for everyone. To be clear, if we have any data to prove that 80% of the users would appreciate and use syntax highlighting, I'm personally not opposed to that. I'm opposed to the proposed implementation though.

In my opinion, the poor editing experience in the Customizer is primarily because the Customizer is not the right place for editing :) Crafting CSS in a 300px wide area is far from ideal, in fact in the mockups there's a proposal to add the ability to expand the editor in a popup (which introduces additional a11y issues, not to mention a popup looks so '90s). It seems to me that's just trying to "add stuff" to put a remedy on a design decision that maybe was not so ideal to begin with.

That said, what is being discussed on this ticket is slightly different though, and it's about introducing a code editor in 3 different places: the Post editor screen, the Theme/Plugin editors, and the Customizer. They're 3 very different places. Introducing accessibility barriers in the Post editor would result in the complete inability to enter content so I'd say that is definitely a blocker. The inability to edit CSS would have some less serious impact, but that doesn't mean accessibility should be a second-class citizen in the Customizer. Maybe worth considering a separate ticket for the Customizer CSS highlighting.

The mockup here: https://core.trac.wordpress.org/attachment/ticket/38707/customizer-css-i2.png is very clearly an improvement on the existing CSS editor in core. It makes CSS easier to read, write, and maintain.

While line numbers, colors, and "auto-tabbing" can help code readability and the editing experience, what CodeMirror does under the hood is far more than that and has a devastating impact on assistive technologies. So it would be an improvement for some users, not for everyone. We should really make an effort to stop thinking just visually and try to understand how a new feature can have an impact not just on people but also on software used by people.

Anecdotally, Jetpack's CSS editor is something I constantly recommend at local tech community project nights

To clarify, Jetpack uses CodeMirror with its default "textarea" model (that means it does not use contenteditable) so it's completely not accessible, way worse than the implementation we've tested which does use contenteditable instead.
No one here is sponsoring Jetpack (sorry @FolioVision maybe you should be better informed before commenting), for sure I'm not.

How to move on? I'd suggest to open a new ticket for the Customizer CSS editor improvements. That would require some serious research and testing to be able to find accessible ways to implement line numbers, colors, and a few interaction aids like auto-indentation and so on.
Traditionally, the Customizer has been a place for experimentation and there are some great developers involved in the Customizer team so it's probably the best place to research new, accessible, solutions.

Last edited 3 months ago by afercia (previous) (diff)

#106 @lukecavanagh
3 months ago

Is it worth opening a new core ticket for improvements to textarea, or is there an existing one to use to work from?

https://make.wordpress.org/core/components/editor/

This ticket was mentioned in Slack in #core-editor by joen. View the logs.


3 months ago

#108 in reply to: ↑ 105 ; follow-up: @melchoyce
3 months ago

Replying to afercia:

In my opinion, the poor editing experience in the Customizer is primarily because the Customizer is not the right place for editing :) Crafting CSS in a 300px wide area is far from ideal, in fact in the mockups there's a proposal to add the ability to expand the editor in a popup (which introduces additional a11y issues, not to mention a popup looks so '90s). It seems to me that's just trying to "add stuff" to put a remedy on a design decision that maybe was not so ideal to begin with.

It's not ideal, but I think it's the place where it makes the most sense. Believe me, I've been using it on .com for forever and I definitely feel the pain of only having 300px, but for small stuff? It's /okay/.

I think once we start implementing the proposed enhancements, we'll likely add them piecemeal instead of all at once. The popup might not happen. By the time we get to it, we might even have a different Customizer design. :) Before we experiment with adding more space, I'd rather see syntax highlighting/formatting improvements and revisions, for example.

Introducing accessibility barriers in the Post editor would result in the complete inability to enter content so I'd say that is definitely a blocker.

I agree! That's a huge issue.

The inability to edit CSS would have some less serious impact, but that doesn't mean accessibility should be a second-class citizen in the Customizer. Maybe worth considering a separate ticket for the Customizer CSS highlighting.

You mean pull syntax highlighting out of #38707 and into its own ticket?

While line numbers, colors, and "auto-tabbing" can help code readability and the editing experience, what CodeMirror does under the hood is far more than that and has a devastating impact on assistive technologies. So it would be an improvement for some users, not for everyone.

For the record, I have no attachment to CodeMirror or any other option folks have explored. It just seemed like the one with the most traction, and the folks working on it seem to be aware of the accessibility issues and are working towards fixing them. I definitely don't want us to launch something inaccessible.

We should really make an effort to stop thinking just visually and try to understand how a new feature can have an impact not just on people but also on software used by people.

Worth noting that these updates aren't purely visual, they're interactive. I don't really care that the textarea looks bad — I care that it's hard to use.

How to move on? I'd suggest to open a new ticket for the Customizer CSS editor improvements. That would require some serious research and testing to be able to find accessible ways to implement line numbers, colors, and a few interaction aids like auto-indentation and so on.

Already open at #38707 :)

Traditionally, the Customizer has been a place for experimentation and there are some great developers involved in the Customizer team so it's probably the best place to research new, accessible, solutions.

If something this is the consensus — build something new, rather than adapt something existing — I'm totally fine with that.

#109 in reply to: ↑ 105 ; follow-up: @jnylen0
3 months ago

Replying to afercia:

To be clear, if we have any data to prove that 80% of the users would appreciate and use syntax highlighting, I'm personally not opposed to that.

This part of the argument against a better code editor does not make sense to me. If this is our policy on new features, first of all I think it's not a good one, and second I'd like to see it officially discussed and documented, including other features we've recently introduced or are planning to introduce.

Ideally a better code editor is an improvement which benefits those users who would use it, without impacting others.

I'm opposed to the proposed implementation though.

And for good reasons - it's unfortunate that we're not aware of an accessible code editing library. IMO we need to focus on practical arguments like this rather than setting up conditions which are almost impossible to fulfill.

#110 in reply to: ↑ 108 @afercia
3 months ago

Replying to melchoyce:

You mean pull syntax highlighting out of #38707 and into its own ticket?

Yep, as the current proposed implementation is not accessible.

#111 in reply to: ↑ 109 ; follow-up: @afercia
3 months ago

Replying to jnylen0:

This part of the argument against a better code editor does not make sense to me. If this is our policy on new features, first of all I think it's not a good one, and second I'd like to see it officially discussed and documented

It is: https://wordpress.org/about/philosophy/#clean and since a few years. Sometimes called "the 80/20 rule".

#112 @FolioVision
3 months ago

Andrea wrote:

Traditionally, the Customizer has been a place for experimentation and there are some great developers involved in the Customizer team so it's probably the best place to research new, accessible, solutions.

Separating the code editor in Customizer from the code editor for posts and the code editor for PHP/CSS files would be creating a huge amount of redundancy. Surely there should be a single visual code editor throughout WordPress and a single optimised code editor for screen reader users not different implementations throughout the project.

We settled on jQuery as WordPress's single javascript library. While not having MooTools or other javascript libraries available makes a few things harder, settling on a single main library simplified troubleshooting and made it easier to document best practices.

we need to focus on practical arguments like this rather than setting up conditions which are almost impossible to fulfill.

(emphasis mine). This ten times over.

There's absolutely no reason we can't make code editing better for everyone by improving the plain text editor to provide fantastic screen reader tools while adding a visual code editor for those who can use it. Everyone wins.

It would surprise me if actual screen reader users are as jealous and eager to deprive non-screen reader users from features which do not benefit screen reader users as members of the WordPress accessibility group are. I'm not a surfer but I don't want to keep surfers from enjoying soft top boards. Nor do I begrudge marathon runners advanced running shoes, even though for health reasons I can't run (I cycle instead). Going the other direction, I'm the last person to want to deprive wheelchair users from having the most advanced innovations in wheelchair design.

Heck, due to long hours working on the computer, I've had issues with vision myself (severe headaches looking at the screen, blurry vision). Who knows when I'll have to use a screen reader myself as a primary interface (I had to give up reading any news and just listen to audiobooks for two weeks recently). Hence I even consider myself in the target audience for both code editors. On both sides of the code editor question (visual and screen reader), I'd want the best possible tool for each use case, not a single code editor which doesn't really suit either side. To make another analogy, I don't wear the same shoes for hiking as I do for cycling.

Anyway there are practical issues to solve. Let's solve them.

Rian wrote:

If you really want this, develop a plugin, we can test it without forcing it up onto people, we also can monitor how often the plugin is installed. If the plugin turns out to be very populair we can spend time to make it accessible before integrate it into core.

We already wrote a feature plugin (Thoughtful Comments) which provides front end comment editing and speeds up loading comments by a factor of ten. As Automattic had Intense Debate at the time and people were satisfied with Disqus (didn't realise core's role is to promote third party products whether Jetpack, WordPress.com or Disqus: for me self-hosted software is about freedom and independence) and I'm not politically connected (happily stranded out here in Middle Europe and I won't travel to the States) there was little interest in adding these improvements to WordPress which are free for the taking (those improvements were not free for the making: there are hundreds of hours invested).

This is a long way of saying that doing a lot of development for free, hoping that someone might smile at me sometime is not in the cards Rian. We have maintained five feature/pro plugin level plugins for five years or so (some more, some less). Only one of those we charge money for. I'm slowly convinced that offering free plugins to the community at this point is a waste of time as there is little respect in our community left (whether from core developers or from the end users or from Automattic) for free plugin developers. WP Rocket probably had it right from the beginning: all paid, all marketing, all the time.

This state of affairs makes me sad.

Not sad enough not to want to contribute financially and in terms of design and code to a brilliant implementation of an improved code editor within core, along with much needed enhancements for screen reader users for the plain text editor.

Last edited 3 months ago by FolioVision (previous) (diff)

#113 @JDTrower
3 months ago

I noticed a couple of references to CodePen and ran across a blog post where they addressed a couple of accessibility improvements with CodeMirror.

Has someone used a screen reader to test codeanywhere.com which uses an editor based on CodeMirror to see how well using a screen reader works with that service? I'd be interested to know if they have done anything to improve or handle screen readers.

That being said, I find myself going into the text editor quite often as I am working on client sites and working in the code to make adjustments or simply to write in code view rather than in the visual editor. If I am doing a lot of code writing, I tend to copy the code out of WordPress and paste it into Notepad++ so I can have the benefits of syntax highlighting then when I am done will paste it back into WordPress and publish/update. I personally tend to not use auto-completion when using IDE's (I feel they slow me down).

I'm personally -1 on closing this as maybelater. While it may take significant work to add in a code editor that is also accessible, I believe that the benefits of improving a neglected area of WordPress is important rather than continuing to use the same editor that was used for years with very little improvement. I also find myself agreeing with those that believe the solution may lay in having a dual-editor system one editor for visual and a different editor for screenreaders. To me this is no different then having to build in support for non-JS users. We progressively enhance WordPress with JavaScript yet provide fallbacks for those that don't use/can't run JavaScript. So if we do that for JavaScript/non-JavaScript why can't the solution for this be the same? Modern web development is all about progressive enhancement use the newer features (HTML5/CSS3 etc) for those who are using browsers that support it, but provide fallbacks for those browsers that don't. I think if we apply the concept of progressive enhancement to WordPress in terms of editors, we would find that we can do things that end up improving things for everyone or for a large number of people. I agree that we can't ignore the accessibility issues and treat those with disabilities as second-class users. But let's not become guilty of doing the reverse by making those without disabilities treated as second-class users either.

#114 in reply to: ↑ 111 ; follow-up: @jnylen0
3 months ago

Replying to afercia:

Replying to jnylen0:

This part of the argument against a better code editor does not make sense to me. If this is our policy on new features, first of all I think it's not a good one, and second I'd like to see it officially discussed and documented

It is: https://wordpress.org/about/philosophy/#clean and since a few years. Sometimes called "the 80/20 rule".

My other questions from comment:109 still stand, then:

What was the discussion that led to this guideline? I agree with the rest of that paragraph, but why is "80% of users should use this" specifically considered a good idea? It seems contrary to the way software development actually works in practice.

Has it been followed for other features? It would be an interesting exercise to look through major features merged in the past ~2 years and try to determine (1) whether such data was collected beforehand and (2) whether 80% of people actually use the feature. I suspect the answer is often no to both of those questions. In which case, according to the language of that guideline, we've "blown it" repeatedly, which suggests to me that there is a problem with the guideline.

#115 in reply to: ↑ 114 @afercia
3 months ago

Replying to jnylen0:

My other questions from comment:109 still stand, then:
What was the discussion that led to this guideline?

You should ask the 6 project leads :) or some of the most experienced contributors. Those principles are there way before I started contributing so I wasn't there when they were decided.

Has it been followed for other features?

Since I'm contributing to the project, I've often seen new feature proposals being not accepted based on that principle and then considered "plugin territory".

It would be an interesting exercise to look through major features merged in the past ~2 years and try to determine (1) whether such data was collected beforehand

Rarely, and that's one of my points: at least some of the most important decisions should be based on data

and (2) whether 80% of people actually use the feature

This should apply to all new features and require some form of data collecting. I think there's an ongoing discussion on this topic. Re: the Editor, I think the ongoing survey http://wordpressdotorg.polldaddy.com/s/editor-survey will reserve some surprises about which are the editor features users really care about :)

#116 @lukecavanagh
3 months ago

@afercia

If trying to apply to the 80% of WordPress end-users who would use a code editor in textarea in WP core, then if that decision is based on data.

The best recent quote I have read that related to that was

"While qualitative plays an important part in how we behave the quantitative is a vital factor in what we decide. You need to be prepared to have data to back-up your assertions, even if they are instinctual."

So hopefully the editor survey has enough reach and responses to be of use for showing if a code editor in core would be used.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 months ago

#119 @afercia
7 weeks ago

  • Milestone changed from 4.8 to Future Release

Punting as we're running out of time for the 4.8 release.

#120 @afercia
4 weeks ago

#39491 was marked as a duplicate.

#121 @afercia
3 weeks ago

  • Owner changed from afercia to georgestephanis

I guess this ticket was assigned to me for the need of some accessibility feedback. Since feedback has been given, it's my pleasure to give ownership back to @georgestephanis :)

#122 @georgestephanis
3 weeks ago

Okiedok. I'll read up all the discussion shortly, write up a summary, and get back to work on a way forward -- unless anyone else wants it first.

Thanks!

This ticket was mentioned in Slack in #core-customize by georgestephanis. View the logs.


3 weeks ago

#124 @georgestephanis
3 weeks ago

So, there's some accessibility issues that need to be evaluated, but it feels like -- all things considered, CodeMirror is likely the best option.

There have been several folks pointing out above that for folks with a screenreader, CodeMirror can be an actual regression and make things harder to use -- so for the moment, so we can make progress let's build in some sort of opt-in / opt-out system (I don't really care which is the default, so long as everyone can self-select the experience that is better for them).

If a better, more accessible code editor comes along in the future, we can always swap to using that instead of what we use currently.

For simplicity's sake, and so as to avoid generating 750k+ .patch files, I'll create and work off of a GitHub repo for creating a plugin so folks can have an easier time testing and tracking smaller issues off of but will be reporting back here as work progresses. If anyone has need of commit access, just ping me here or on Slack.

tl;dr: CodeMirror isn't the best on accessibility, so let's let folks easily not use it if it's a degradation.

#125 @matt
3 weeks ago

This is a tough one. I'm supportive of us moving forward testing a rich code editor in trunk and accessibility of that particular editor being something we figure out in future iterations, contribute back or sponsor for CodeMirror, or have an accessibility-minded plugin we recommend that gives users fine-grained control over turning on and off. (An accessibility plugin like that could be useful for a number of reasons, like the multibyte patch plugin is for Japanese users of WP and has close to a million users.)

#126 @georgestephanis
3 weeks ago

It's not terribly pretty, but here we go:

https://github.com/georgestephanis/codemirror-wp

Once you clone it to your plugins directory, you'll need to npm install and npm run-script build to generate the include-able versions of the CodeMirror files from within the CodeMirror subdirectory.

This isn't generating any minified versions of the files, but until we decide which addons and languages we want to bundle support for into Core, this makes sure we have all the options available to us for enqueueing as needed.

It will work for CSS and PHP files in the Theme Editor currently. I'll be adding support for the Plugin editor soon as well.

I'll be adding some documentation to the readme on how to use it soon.

Last edited 3 weeks ago by georgestephanis (previous) (diff)

#127 @georgestephanis
2 weeks ago

repository is updated, and now in the Customizer with Custom CSS. Also both the Theme and Plugin editors.

Disclaimer: if you're running Jetpack, something may go splat. I don't know, haven't tested it yet, but it's messing around in the same area of the Customizer that Jetpack is, so one may win over the other -- if that happens, just deactivate the Jetpack Custom CSS module to test this.

#128 @FolioVision
13 days ago

Hi George,

It's great to hear that steps are finally being taken to include a visual Code Editor in WordPress. @jnylen0 and I worked hard to push this ahead and not to have it die in accessibility hell. Foliovision are still up for helping with the accessible plain text version. Matt's idea here is a good one.

moving forward testing a rich code editor in trunk and accessibility of that particular editor....contribute back or sponsor for CodeMirror

Sponsoring improved accessibility in the main project would help accessibility every project using CodeMirror and help CodeMirror.

Any chance you could create a bundled build of your Code Mirror so it's a one step install? We need to get there (drop-in) sometime soon and we could have a lot more testers if we moved to packaged builds right away.

Cheers, Alec

#129 @westonruter
11 days ago

  • Milestone changed from Future Release to 4.9
Note: See TracTickets for help on using tickets.