[wp-trac] [WordPress Trac] #12423: Include default code editor

[WordPress Trac]

#12423: Include default code editor
-----------------------------+----------------------------
 Reporter:  scribu           |       Owner:  afercia
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  4.8
Component:  Editor           |     Version:  3.0
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  accessibility
-----------------------------+----------------------------

Comment (by FolioVision):

 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/12423#comment:77>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform