[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:  close            |     Focuses:  accessibility
-----------------------------+----------------------------

Comment (by JDTrower):

 I noticed a couple of references to CodePen and ran across a
 [https://blog.codepen.io/2016/07/14/blind-accessibility-testers-society-
 guide-codepen/ 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.

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