It's been requested/discussed so many times in various issue queues. Drupal needs a WYSIWYG editor in core, since so many users consider it a key feature missing (either compared to what they are used from other CMSs or that's what they expect when they first instal Drupal). Most people are aware that there is a way to achieve this feature, but what they want is an 'official' out-of-the-box solution.

Even if this gets either 'wontfixed' or 'postponed' (like for ever), at least we'll have a place to point people to each time this question comes up elsewhere. This issue will serve as an answer to people wondering if it will ever happen - not how. So...

Note/plea: this is not a place to start flaming over which particular solution is best, but rather a discussion over if this should happen or not. Once that is decided, we'll see what we'll choose to go with (based on features, looks, well-maintenance, popular demand - I don't know). So please, for the love of God if you must, then head over here instead for such comments:

- Comparison of Drupal WYSIWYG Editors
- Wysiwyg @ groups.drupal.org
- Which editor (if any) do you use for your Drupal site(s) (poll)
- Wysiwyg project & its issue queue

Status update - Latest news

- March, 2011, There is an initiative that mentions that Dries intended/wished to include a WYSIWYG editor in core for Drupal 7 (was #3 in his top-10 priorities list). This however did not happen.

- March, 2011: quicksketch started a sandbox WYSIWYG in Core project.

This project is a branch of Drupal 8 whose purpose is to bundle a WYSIWYG editor into core. This project is a branch of Drupal core (rather than a branch of the existing WYSIWYG module) because the approach used in this sandbox integrates tightly into the Filtering system.

quicksketch also states:

The most central concept we need to develop is the idea of filtering not only output but on input as well...

- June 2011: the HTML 5 Initiative group dropped the idea of adding contenteditable support in core from their Phase 2:

Decided to remove the contenteditable WYSIWYG bullet from Phase 2. It'd be a huge undertaking, not really an HTML5 issue, and one that should really be its own separate initiative.

- August 2011: quicksketch initiated a session on WYSIWYG in core at DrupalCon London:

This session is going to be a discussion more than a demo of proposed code. We'll take a look at what solutions other systems (namely WordPress) have included to deal with rich text editing, and we'll identify the central problems with building similar functionality into Drupal.

Ultimately, the solution currently being pursued will be an overhaul of the "Filter" module (which currently is only designed for filtering on output), and replacing it with a new module that controls not only filtering on output but also on input, making it possible to provided a true WYSIWYG (or at least a lot closer than anything we have today).

Comments

I think it would be a good thing to have one ship with core, as long as it wasn't a required module and could be replaced with something else. Kind of like how we ship themes with Drupal.

I don't think there's much of a possibility of this happening. The main blockade that I see is just that Drupal content is so flexible and diverse. You can use markdown, BBCode, textile, plain HTML, plain text, limit the allowable HTML tags, allow all HTML, strip JS, don't strip JS, convert issue numbers to links (ala Drupal.org), convert twitter style @usernames to links, convert blahblah to a flash video of a slideshow of images from xxx folder using blahblah background music, etc., and each of those could conceivably be different from node-to-node or textarea-to-textarea.

So for a WYSIWYG editor to be included in core, it would either have to:

1) Be flexible enough to contend with all of those (which is impossible), OR...
2) We would rely on all that magic to happen on display rather than on entry/edit, so people could enter whatever they wanted in the WYSIWYG and Drupal would hack it to bits when being displayed. This is more or less the current state, which works well enough because people installed WYSIWYGs themselves and (hopefully) know what they're getting into when they do that, but for it to be part of core seems like a usability issue waiting to happen. OR...
3) We would have to tell people "either use this with the default input formats or turn it off" which sort of ruins the point of having one in the first place.

Another issue is that there isn't a single WYSIWYG editor that has been more or less accepted as the standard for the Drupal community, so deciding on one will be near impossible as everyone has their own favorite for different reasons. Therefore, we would most likely be stuck rolling our own (which is a HUGE amount of work) or at least significantly altering an existing one (which is still a ton of work), and the fact that Drupal's been around for forever and this has always been an unsolved issue makes me think that this is work that no one wants to be doing.

That said, I would love for it to work out, if for no other reason than people seem to think the lack thereof is holding Drupal back. So subscribe.

Why would it have to solve every scenario? I don't think its unreasonable to ship with a basic texteditor out of the box for folks who aren't savvy enough (OR don't understand why Drupal comes without an editor, like Wordpress). It just needs to be simple, and support basic HTML formatting. If they are looking for more flexibility, it can point them to the appropriate section of drupal.org for more robust WYSIWYGs.

The other option would be to enhance the Drupal core experience. For example, if no text editor is installed, underneath the textarea of a node add/edit form it could say "How can I format my text like in my word processor software?" (or something friendly) which links to an internal help page which explains and links them to all the text editors on Drupal.org to find the one of their liking.

I wouldn't go so far to say that "most people" would know to come back to drupal.org, -or- that Drupal has modules. There are tons of people out there just trying to run a website, and don't know what a CMS is, or that they are extendable. Moms, dads, grandmoms, day traders, teachers, students, etc. Being developers and/or tech savvy we overlook things like this, but in my opinion, the lack of an RTE (or internal directions to obtain one) is one of the first obstacles the average person gives out on and tries something else, like Wordpress.

install profile like now in D7 the basic vs. clean install. Basic install has wyziwig editor turned on by default.

As for which to include, maybe see if any of them would like to cross promote usage the way jquery does. jquery uses drupal, drupal uses jquery kind of thing. A lot of the text editors provide additional commercial support so having a free-bee go along for the ride doesn't sound bad from their perspective either.

I agree a that basic WYSIWYG editor should be included, but not enabled by default - this should fall under the category of optional functionality like the Book module. My primary reason for supporting this idea is that for many new Drupal users getting WYSIWYG installed and working as expected is not an easy-to-grok process, and there can be several pitfalls along the way. Simplifying this for new users (and experienced users who are setting up a basic site for someone) could only be a good thing.

I agree with Jay Matwichuk and Valkyri9. There are several good reasons why a WYSIWYG won't be able to cover all eventualities, but there are numerous core modules that don't work for every case. An easily-activated WYSIWYG would make adoption vastly easier for new users.

On top of that, a core WYSIWYG module programmers with a baseline for WYSIWYG interaction. The inclusion of it would encourage programmers to consider it in their projects; its presence alone could expand the scope of drupal-WYSIWYG integration.

That said, Mcrittenden's point about choosing which WYSIWYG is valid. Making a drupal-custom editor is probably not realistic, and customizing an external one is difficult as well. Compromises might be necessary, but I thik it's worthwhile. To many clients and users, the content-editing pane is the face of the entire application.

Furthermore, I realize that Wordpress is a different product, but it shouldn't be ignored that Wordpress is (often painfully) extended beyond its original scope mostly on the strength of its editing pane. The fact that their integral WYSIWYG is such a large draw for that product is worth considering and is applicable to Drupal. If a WYSIWYG can make people stretch blog software out to enterprise scale, imagine what a boost it could give for a package that can handle enterprise applications out of the box.

Why not make WYSIWYG module part of the core then, and in D8, build the functionality to download the editor from the interface into sites/libraries and activate it?

I think part of the trouble for the average person is figuring out how to get a module in to activate a text editor, then actually doing it (provide they have FTP access, right permissions, etc). That's a big reason why Wordpress succeeds for the average user, because that end of it is just provided- and in most cases, suits just well.

Power users like us can easily disable WYSIWYG, and use something else if we want post-install.

Absolutely agree on that!

If i compare Drupal to Wordpress or Joomla the first thing coming in my mind is that WYSIWYG in Drupal is a pain.

If you want a really smart solution that works great for non techy Users, you have to install a lot of modules, wrestle with configurations and still - it won't get as comfortable or intuitive as Wordpress. Joomla got no WYSIWYG too, but there are modules like "JCE" that are VERY easy to install and are out of the box more comfortable and user-friendly (and i guess powerful too!) than anything you could do with Drupal right now. (And you'll spend much time on it)

The second big thing are Image-Gallerys. But that's another thread ;)

Greets,
Simon

but kevin, if the average user knows how to install a wyzwig editor how will I keep getting paid to turn it on ;)? What I'd like to see is that an install profile goes out to d.o. and downloads the modules it needs and a "basic" profile comes with a wyziwig editor by default. Part of the issue with moving wyziwig to core is that:
1. core wants to get smaller (esp after the bloat in 7)
2. then someone has to maintain formatting and all those other wonderful issues in a core distro when those updates could happen a lot faster as it's own project (theoretically).

I'd love to see some kind of install profile area that's like jquery UIs click checkboxes and it builds out the package. That'd be incredibly powerful toward this end.

Although I've voted strongly against wysiwyg editors in the past, it's a very, VERY common requirement and it's something that is tremendously frustrating to set up in Drupal properly. It requires threading the needle of installing a Drupal module (or two), installing a JS library, configuring both of those correctly, then configuring your input filters to match the settings the editor is using to ensure there's no mismatch between the two.

  1. An underlying API that allows textareas to be flagged as wysiwyg-OK
  2. a way of specifying what library should be used on those fields (ala the current contrib wysiwyg module)
  3. and a known baseline wysiwyg editor or markup helper in core to serve as a reliable standard UI tool

That sounds like a sound approach. Have a pre-configured setup for the editor ship as part of the Standard Profile, and leave it turned off and unconfigured for the minimal profile.

The devil is in the details: what wysiwyg editor would suit a majority of Drupal sites, and how can it be used as a default without disrupting the 20% that need something different? Wysiwyg module has already been ironing out some of these questions and is probably the single best place to look for answers at the moment.

Well said Jeff! And as for the fear of raising 'wars' over which would be the best solution to use -as you've pointed out- Wysiwyg is the way to go. It is not the editor itself, but it *aims to* provide all the API etc. required in order to have an editor relatively easily installed by the end user. It simplifies the installation and integration of the editor of your choice. ...as is well-stated in the project's page.

During installation and if the standard profile is selected, there could be a single dialog (radio boxes list) to ask which editor (JS lib) the user prefers but having one preselected as the default/recommended. After that -now that we have the update manager- the selected library could be downloaded/extracted/placed in the right place and you'd be good to go. Which would this recommended editor be though you ask?...

...well, we do have a way of getting usage stats for the modules/themes and to know how many sites use them. Why not do the same with installed/enabled wysiwyg editors? That would serve as a survey of which editor is the most preferred. If that is not enough, then we can start a full-fledged poll over it.

Anyways, I guess what I am trying to say is that this issue is not a matter of how, but of if. Before planning/brainstorming on *how* we would implement this feature, we should first clearly see the fact that this is a popular demand and agree on *if* it should be done.

I personally disagree with WYSIWYG being the way to go, at least as it was the last time I looked at it. It's a great module for what it does, but it's got it's issues as well - one of them being bloat. Most sites only need one editor, and it provides the ability to add many. If you are only using one, it's overkill. The other problem is that it doesn't allow for editor specific settings (or at least it didn't last time I played with it - maybe that's been improved on in the last year). Sometimes it's good to be able to configure very specific settings on the editor, and other editors may not have that setting.

If these two issues can be overcome however, by streamlining the module as much as possible, and adding the ability to do per-editor configuration specific to that editor, then I think it could be the way to go.

I hear you Jay when it comes to being concerned on performance and adding complexity to code (I guess that's what you mean when you use the word 'bloat'). Still what we need is to provide an easy(-ier) way to add an editor and not provide the editor itself. I am afraid that with so many solutions available out there, if we 'force' a certain editor, then there'll be 'wars' over which one is the best.

Now, Wysiwyg is the only module I am aware of that *aims* to do exactly that. I am confident that if it is chosen as the basis to move this issue, then more attention will be drawn to it and whatever issues it still has will be resolved soon(er).

The best part about WYSIWYG module is controlling the toolbar through the UI without editing the config.js manually, which can be wiped out depending on how you maintain your editor files during an update. That is why I recently switched back to WYSIWYG from CKEditor module.

Personally, I'd vote for something simple like CKEditor module added to the core distribution, but not deeply integrated into the core.

Just have the module turned on by default, so it's really simple for non-tech n00bs trying to get started with Drupal.

I understand the idea of WYSIWYG API module, but it isn't as cleanly integrated as CKEditor module. By abstracting, you gain flexibility, but lose power with any individual editor (jack of all trades, master of none.)

For those with more tech chops, it's trivial to disable CKEditor, and replace with WYSIWYG API + editor of their choice.

Ultimately this isn't the "power-user-happy" solution, but it is the "easily accessible to n00bs" version, and doesn't hurt the flexibility for power users.

Did anyone mention that quicksketch has started playing with this at http://drupal.org/community-initiatives/drupal-core/wysiwyg ?

Subscribing

+1 for wysiwyg as a standard feature. Is it possible to integrate the wysiwyg module in the core filter module?

I would think Drupal would be best suited to have an editor that was 'made for Drupal' and completely integrated with the system for best performance. Lots of editors out there put too much junk out in the markup. Sure, we can rely on HTML Purifier etc to 'hide' it- but that feels like a cop out.

I don't want to make anyone sore by saying this, but I think that Wordpresses out of the box WYSIWYG is killer. Great media management, not a lot of junk markup, has all the buttons most people need, and is intuitive. In my head thats what I think Drupal should come standard with, and would be able to be switched off in favor of other setups for power users.

FYI: the WordPress Wysiwyg editor is just TinyMCE, pre-configured to work with the features it supports and skinned to look good in its administration section.

I think most of us will agree that the most important issues that keep a WYSIWYG editor from being offered with core are:

- Concern of more code complexity & bloating core.
- So many options out there & so many debates over which is best.

I lean towards the idea of WYSIWYG in core (so that people can add their favorite one with ease) + a really-really basic drupal editor that will be offered with core. By "basic" I mean that it offers only common editing functionality that in most cases doesn't give users the "opportunity" to break the site's overall look and feel. So...

- bold/italics/underline
- image upload, insert and positioning (per content type & if user permissions allow)
- links (if user permissions allow) and ideally give the option to allow only internal links or external too.

- no font color/background color change
- no font size change
- no font family change

I think these are enough to satisfy most basic editing needs -so that users don't complain- and at the same time keep the site's identity/style consistent -so that site admins and owners don't have headaches-.

...I updated the issue's summary with Scott's mention in post #17.

Is it possible to integrate the wysiwyg module in the core filter module?

Yes, that's the intention of my sandbox (http://drupal.org/sandbox/quicksketch/1088256). The most central concept we need to develop is the idea of filtering not only output but on input as well. I'd really encourage users to participate in the sandbox if they're interested in contributing. We're a long ways off from patches in the core queue.

Issue summary:View changes

...updated issue's summary after Scott Jackson's mention of the initiative in post #17

@quicksketch great initiative

The html5 initiative group thought of implementing a html5 contenteditable WYSIWYG in core. Would implementing contenteditable WYSIWYG be the way forward?
Decided to remove the contenteditable WYSIWYG bullet from Phase 2. It'd be a huge undertaking, not really an HTML5 issue, and one that should really be its own separate initiative. (http://groups.drupal.org/node/157334)

subscribe

Good to know that quicksketch initiated a session on wysiwyg in core at DrupalCon London:

http://london2011.drupal.org/coreconversation/wysiwyg-editor-module

This session is going to be a discussion more than a demo of proposed code. We'll take a look at what solutions other systems (namely WordPress) have included to deal with rich text editing, and we'll identify the central problems with building similar functionality into Drupal.

Ultimately, the solution currently being pursued will be an overhaul of the "Filter" module (which currently is only designed for filtering on output), and replacing it with a new module that controls not only filtering on output but also on input, making it possible to provided a true WYSIWYG (or at least a lot closer than anything we have today).

There's a full range of very hard technical challenges involved with this. I wonder how people come to think that they could "quickly solve these" in a core sandbox, entirely ignoring the already existing discussions on the topics?
It would be a huge mistake to invent a new, untested, unproven, and half-baked solution in core. A clear recipe for failure.

Second, Filter module requires absolutely no changes for this, and neither does anything else in core. That proposal about changing Filter module to also filter on input is completely off and invalid. It means that people do not understand the problem space.

Third, whenever you intend to include something in core, you need to ensure that it is going to be actively maintained afterwards. The amount and diversity of technical/code contributions to this campaign (as well as Wysiwyg module) are close to zero, which contradicts that goal in the first place. If people would actually put code behind their nice wishes, then we could already have an in-production testing ground for the stuff you intend to do. There are open issues for all of the unresolved challenges, but guess what.

Hey Daniel, thanx for your input. Care to update the issue summary? - especially with a list of these unresolved challenges you mention + their respective issues. Thanx in advance.

Issue summary:View changes

Sandbox link was missing. Added it.

assuming the choice would be to see what people are using and compile that research into a statistical analysis and also then to look into to the statistics of there technical pros and cons etc and then put a report together on which one to go with? sounds hard but would not take that long as someone who has done that before in online communities i would not mind providing the time to do it or perform an analysis (researchers love to research ;)

coding one from scratch is a mammoth job and why reinvent the wheel? there are so many projects out there we need to see what would be the best fit for Drupal core/modules technically wise and also modules as there are various modules out there like IMCE etc etc etc anyways just food for thought?

I like the idea of Filter (or some other module) cleaning the input so the output is more predictable.

My problem with the WYSIWYG API module is that it is very complex and flexible, but not very accustomized to Drupal itself. For example some very simple Things are not easy and require custom coding:

-> The font-size, background from the editor is often not very identical with the style of the site itself. So its not very WYSIWYG and you have to put some effort into it to come closer. And doing that is often not very intuitive.
-> Its not easy to make h2, h3 etc styles in TinyMCE. It really makes div.h2 which is not really what I want and from structural perspective this is a big foul.
-> Also I miss some more Drupal-specific integration. Pagebreak is really the only thing in this direction.
Anyone seen JCE Editor for Joomla? This is a great example how it can be done. But i'm not sure a project like this makes sense to be in core.

Also I cant think of a single usecase where its really useful to have many different editors. Usually you choose one and stick with it, and this seems to work in every other CMS too. This way you can focus on one thing and make this really great. Drupal tends to loose itself in its flexibility sometimes ;)

Just my 2 cents
Simon

Issue tags:+accessibility

I like the idea. It * must * be easily plugable w/ other libraries and must have rol / user based permissions to toggle availability.

Whichever editor is chosen must have a UI that is WCAG 2.0 AA compliant and must allow users to produce markup that is also WCAG 2.0 AA compliant.

+1 for keeping wysiwyg in an install profile, ideally out of core. If we get that far and can make install profiles as easy to download and install as Drupal core, that would be great so core could avoid having things like this tossed into it. wysiwyg serves a rather narrow use case. My question is what is to be gained by shoving such a heavy thing into core. The JS and browser worlds are evolving much more quickly than core.

I agree with Laura, only if install profiles are:

1. Easily discoverable on d.o
2. Well documented features (clear language) and module list
3. As easy to install as drupal core
4. Have dedicated maintainers, including receiving the sme priority for security and bug fixes as core

I absolutely hate the overlay and the toolbar features that come with D7 (I use admin_menu instead) but I am aware that they were put there for good reasons and thus greatly respect that - period.

They are the first two modules I always disable after each fresh install. That gives me no right though to say that they were just "tossed into it". The sole reason is that they got in core as a result of studying how it would help people have a greater out-of-the-box UX - not as a product of a "ok. Let's just do it!!" moment one person randomly had. I guess that it was also an effort to try to be as competitive in the CMS market by providing useful features, but I am sure that comes second in importance.

Well, it's pretty much same with WYSIWYG editor in core. It won't be that difficult for experienced users like ourselves to disable it and use another contrib or custom solution. I guess what I am trying to say is that fear of bloating the core should not stop us from adding features when they are so broadly demanded and repeatedly requested for years to happen.

Instead of having Drupal and additional profiles that do things that the broad audience expects out of the box we should simply have Drupal that does these things out of the box and additional profiles that don't. All of us "hardcore", "geeky" people can surely locate these "mini", "pure-core" versions in far less time and with far less effort than Drupal newcomers (polite word for "newbies") would grasp the idea of "profiles", "contrib", "module" etc. It might be hard to admit it, but Drupal newcomers come to d.o for the sole purpose of downloading and using Drupal - not to learn our terminology and how things work internally.

Right now, we have the reputation of a "steep learning curve" (personal experience says that this is actually a fact and not some rumor). Sure, now that I'm deep in it, I have to admit that I'm hooked and I don't look back at the effort I've previously put to it. The fact remains though that even now we have 4 steps revealed to d.o visitors after hitting the "Get started with Drupal" link in our front page:

1. Download Drupal (...implies install too)
2. Extend Drupal
3. Documentation
4. Get support

I our case, why should a user that simply wants a site with a WYSIWYG editor -like most other CMSs out there- go through all the above steps (they do - especially if they can't get it to simply work) when they could *and should* be up and running from step 1?!?

Mostly following up from @Hanno in #27

Just posting some related links:
#1094094: WYSIWYG in core: Call for volunteers!
#1259750: Compare accessibility of candidate WYSIWYGs

Subscribing

FYI: the WordPress Wysiwyg editor is just TinyMCE, pre-configured to work with the features it supports and skinned to look good in its administration section.

Really, if that's the case how do I get the html tab in TinyMCE? Wordpress definitely isn't using IMCE for image uploads and I'd love to learn how to configure this all in Drupal to be exactly the same because it all just works in Wordpress. I'm for either D8 shipping with some form of basic wysiwyg editor already installed and working properly or a much easier process for installing and configuring a wysiwyg editor. Call me a n00b but I've been having a harder time with properly configuring a wysiwyg to work properly than I had with learning how to configure views. Basically, thee most basic feature expected of a modern CMS is one of the hardest features to get up and running in Drupal.

Wordpress standardized on its WYSIWYG which allowed them to tightly integrate media control into it. Drupal remained flexible so you could use what you want.. but as you said, can be tricky.

Really, if that's the case how do I get the html tab in TinyMCE?

WordPress actually includes not only TinyMCE but another JavaScript based editor for plain-text HTML editing also.

Certainly there are lots of accessibility concerns with this choice, but really it's a matter of reviewing the choice made by this group & http://drupal.org/project/spark

Issue tags:+JavaScript

tag

There are many, many contrib modules that try to solve problems related to lack of a coherent wysiwyg strategy in core (imce is a noteable example, media, plupload etc). If an wysiwyg editor was in core, then the filters for rich text would work out of the box, line breaks issues, image upload and handling within rich media could work out of the box, insert audo / video too. Think of all of the hacky modules that try to insert media into content, and sort of work. A core wysiwyg solution would give module developers a default editor that they could code for, a target that needs to work with their module that requires rich text abilities; just check out the panels / wysiwyg / lazyload issues here http://drupal.org/node/356480 to see what I mean about integration issues.

I like how the wysiwyg module switches editors based upon the input filter. That said, I'm a plain text guy, hate rich text. But I've not yet met a client / user of Drupal yet who agrees with me. :) And I think you're going to see Drupal getting knocked down on this compared to other systems. Maybe this is because Drupal is really just an application dev framework with a little cms thrown in. Whereas Wordpress is mostly a cms that has a little application dev abilities. I only say this because most core releases completely break / enhance application stuff like the form api etc, but cms features like rich text, images, audio, video seem to get very little attention in comparison.

So, if Drupal was pitched as an application dev framework then I'd be ok with wysiwyg and media stuff in contrib. If it's a true cms, then it needs to be in core, imo.

Given the excitement around Spark's in-place editing and WYSIWYG, it seems plausible (though definitely not certain) that the Aloha Editor WYSIWYG will make it into core. It even has @sun's approval!

Issue tags:+Spark

Tagging with Spark.

Incidentally, there are 65 days left before feature freeze, and 45 people subscribed to this issue who presumably want to see this happen. :) If so, #1782838: WYSIWYG in core: round one — filter types is step 1. Reviews needed.

Priority:Normal» Critical

Also, shipping a CMS in 2013 without a WYSIWYG editor out-of-the-box would pretty much be the death knell of Drupal. Raising to a critical feature.

So I don't really get what this issue is about, is to discuss whether we want it or not? If we wish to escalate it to critical, it should have something actionable behind it?

Hi webchick,

honestly, I ate a bit wysiwyg editors, especially from my blind user perspective. I am really concerned about including a wysiwyg into core because I am really afraid of having an inaccessible editor in core.

Among blind users there is the idea (that I agree with) that Drupal is one of the most, if not the most, accessible cms out-of-the-box.

So, I think that we should strongly consider this issue:
http://drupal.org/node/1259750

Unfortunately, from my initial tests, Aloa seems the less accessible candidate....

I would vote up for CkEditor, but at this time I have some accessibility issue also with this editor...

I'll write a more detailed report on my tests as soon as possible...

Agreed @webchick. If it doesn't ship with a wysiwyg editor in core, then the line has been drawn by the core team -- it's an application framework, not a true cms. Just my opinion, but I've been building many sites with drupal since 4.x and this is the most major pain next to media handling for simple cms tasks.

falcon03: Accessibility remains one of our paramount priorities. It would be wonderful if you were to work with the Aloha Editor team upstream https://github.com/alohaeditor/Aloha-Editor to provide a detailed accessibility review of their work. You can try it out by downloading the 2.x version of Aloha module http://drupal.org/project/aloha (read the README.txt though because it's a little tricky).

Hi Webchick,

I tried to install aloa 8.x-2.x-dev in my test environment following the readme.txt instructions, but I am not able to download any admin_icons release (required by aloa)... Could you help me please?

However, I checked out this demo:
http://aloha-editor.org/demos/3col/
and, if it is correct, it seems there is a ton of work to make it accessible.

Oopsie. Thanks for that. I've created -dev release nodes for the 7.x and 8.x versions of admin_icons, so they should be available within ~12 hours.

Hi Webchick,

well, I downloaded the 8.x-dev release of admin_icons (it has not appeared on drupal.org/project/admin_icons yet, but I found it using Google)...

Things are better than I thought, but there are some important accessibility issues. After a quick (very quick) review:

  • After inserting a link I cannot know that it has been inserted correctly, unless I reach it in the text;
  • Keyboard navigation seems a bit unpredictable ("format" and "insert" links are not always reached using the "tab" key, but they should be);
  • I found no way to insert headings and...I think this is a critical issue!
  • If possible, I would like to convert "format" and "insert" links (and related buttons) into the equivalent components used by CKEditor, so that a blind user "sees" a structure similar to a menu bar (at least using Voiceover and Mac OS X).

However, there are more issues that I would like to be fixed before drupal 8 release; unfortunately I am not experienced at all with javascript, so I cannot help fixing them. :(

The main concern from my perspective is the replaced "body" field; a way or another I was able to use it, but I don't know if it is really and completely accessible...

Maybe we should start a discussion on the accessibility group... What do you think about it?
And, finally, what is the best way to report these (and other) issues to Aloha developers, in your opinion?

#55: please see #1747930: contenteditable is not accessible to screen-readers for the existing accessibility issues. There are many known accessibility issues, but we're already working closely with the Aloha Editor guys to fix them :) Please follow that issue, and you will then automatically be notified once there is progress, and thus things you can review. Please stick around — we need all the accessibility feedback we can get!

Status:Closed (duplicate)» Active

I appreciate the work going on in this thread -- it is certainly an interesting read. just one quick point:

I think the big win with WordPress is not its inclusion of TinyMCE, but whatever was done to add the 'Upload/Insert' button above the (default wordpress) editor window. (see this demo page user/pw:admin/demo123)

It's the image and file management that has caused the most pain for the users of the sites I've created. (I've created many sites for community groups comprised of (generally not-super-computer-savvy) people who just want to write pages and not think too much about it. It's hard to convince them to let me use Drupal when many of them have seen how easy it is to add images in wordpress.

thanks again, tod

Issue summary:View changes

...updated with latest related news.

Status:Active» Closed (duplicate)

Issue summary:View changes
Status:Active» Closed (duplicate)