[wp-trac] [WordPress Trac] #12423: Include Ace (or similar) as default code editor

[WordPress Trac]

#12423: Include Ace (or similar) as 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):

 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**?

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