[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):

 @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 ([https://wordpress.org/plugins
 /foliopress-wysiwyg/ 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.

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