WYSIWYG in core: Call for volunteers!

I'm on board and down to help out with UX issues. I have also used a lot of other wisywig interfaces that we could benefit from studying. I'm interested in helping from a design and usability standpoint and can help w/any layout and graphic needs that arise.

Overall, I'm interested in helping by being the advocate of the non-technical user and figure out a solution that will help the overall image of Drupal. It is my opinion that this is one of the most important low hanging fruits that will differentiate our image amongst the masses if we solve it properly. And there are already loads of folks doing it right that we can learn from.

sub

I'm in, and can help out with most things.

Subscribing ...just to get an idea of how many great minds will eventually gather around this.

...less vague title. (I am updating the issue summary at #1008522: Ship D8 with an out-of-the-box WYSIWYG editor - sorry for the noise).

subscribe

I'm in.

One of the big accessibility problems with sites comes through bad WYSIWYG editors. I'm interested in helping to see that when we get a WYSIWYG in core it produces clean HTML & can be edited effectively through assistive technology.

I can put my hand up for volunteering, have worked extensively with WYSIWYG from the early years and also in other CMS distributions both open and closed. I do not mind helping on a variety of issues of I can be placed where there might be a gap in skill set. I have worked with WYSIWYG from setting up servers (libraries etc) for them, coding/contributing to them, evaluating for corporate clients. I have also done research in the area of HCI etc so I can add to creating surveys collecting information and also performing statistical analysis of peoples feedback and comments to help the choice of which one to go with etc. Maybe the research area might be an area that has a gap etc that I could fill? anyways sign me up :D Also will be at DrupalCon Denver if there will be a code sprint/ BOF/ further discussion.

Reporting in.

I'm in.

Subscribing

Since WYSIWYG isn't super easy to setup, and isn't in Core, it is a pretty big barrier to novice participation in Drupal.

However, I echo @mgifford, WYSIWYG creates * many * accessibility issues. My guess is that the only WYSIWYG library worth considering, from an accessibility perspective, is CKEditor.

Please tag any issue where you have doubt about accessibility with "needs accessibility review"

Hi, I'd like to help, I've got pretty extensive experience of various different CMS systems and what they are doing in terms of content editing. I'm really volunteering to make it simple from a basic end user/content editor point of view. I also think we should be pushing for all the expected CMS functionality in core: images, videos, audio in a media library, linking between content and being aware of links in the content so that the site integrity can be retained when users delete or change aliases of nodes, images, etc.

I strongly believe that Drupal should come with a solution out of the box so anyone new to Drupal can get going with a basic website without having to figure out a variety of modules just to make it so that they can add content without any html knowledge. Especially if Drupal wants to compete with systems such as Wordpress. Experienced developers should still be able to disable the core version and implement their own if that meets their use cases. We shouldn't make it hard for new users to get going because experienced users want more flexibility, as experienced users have the knowledge to customise the system to meet their needs anyway.

I've had a go at quantifying what I believe should be in a standard CMS mostly with regards to the WYSIWYG editor on my blog let me know if you think this is heading wildly out of the scope of this project. It's a post that's been brewing for some time and Quicksketch's session at Drupalcon has given me the motivation to write it.

about time! :)

subscribe

Bit late to the party, but I'm in.

I'm in too.

I'm in also. Willing to do sprints, wireframes, QA, documentation, coordination of initiative activities, and more…

D7 is starting to take less of my time, so I need to start supplementing it with something. ;) Why not D8? :)

This is one of the initiatives I think is extremely important for Drupal, so I'd love to help with whatever I can.

Is there any work / support that we could be giving here?? I am working on a large accessibility website for Media Access which needs to conform to WCAG 2 (508 is only WCAG 1 in Australia we need to comply with WCAG 2) and we will be running a test on Drupal using the ATA accessibility Authoring tools criteria. From research CKEditor is the closet we can get to meeting accessibility Tiny MCE falls short in many areas. Once we complete the full report we will release it into the Drupal Community, but this will be based on Drupal7.

Once again keen to get involved and start helping out, if there are any tasks on hand or is this one of the back burner??

no problems will do, we are in the process of finalizing a report so I will get that completed and get the main points we found posted up, the team at Media Access are content experts in Accessibility so the report is a non biased approach to meeting the guidelines as they are not Drupal people or Technical experts at all etc so there approach is purley from meeting the needed Government Guidelines. I will post the information in the places you requested cheers and thanks for a quick response ;)

amaree, did you ever get around to performing that assessment?

webchick in the process of it now, plan to have completed within one week just finalising some areas and having the Accessibility content expert at Media Access to evaluate, sorry it has been longer then I expected with holiday breaks etc. But yes it will be shortly and posted under creative commons :D

No worries at all! Thanks for keeping us posted. :)

Would just like to reach out from us at Moxiecode and say we would be happy to assist Drupal devs in any TinyMCE endeavour.

Always thought it has been strange that Drupal haven't included an editor in core for more tight integration, there is so much to benefit from that!

Good luck with your choice either way!

w00t! Welcome, Joakim! :)

Thanks!

Regarding Accessibility, we have clients that are required by law to follow the WCAG 2 spec, so we have put quite a lot of effort into making sure we follow that, and now also our partner Ephox is dedicating even more time towards it.

This means 2 things.
1. The editor should be able to produce WCAG 2 compliant content.
2. The editor itself should be WCAG 2 compliant when using it.

We think we are doing ok on these things, but it could be improved even more.

@TinyMCE Dev - Can you point us to the issue queue or team who is working on this? When we have problems, it would be useful to know where we can post them and also (for the sake of this issue), get a sense of how quickly they are addressed.

It's a big challenge to keep up with WCAG 2.0 A or AA compliance. The Assistive Technology, Browsers & expectations just keep changing!

For WCAG specific bugs, use our bugtracker and tag the bugs properly and it will be verified by a developer. I would suggest setting the tag to "wcag".

http://www.tinymce.com/develop/bugtracker_bugs.php

Yes it is a big challenge to keep up with the compliance, previously we have decided to update the compliance in stages, once per year we did an internal review and see what areas needed improvment, this made the compliance lack a bit for a long time, now we are looking more activily into it when developing new features and changing the UI etc. Also a lot easier to test nowdays with quick VM's setup for the task as well as automated testing.

Great. I just signed up for an account. I'm not sure when I'll have time to submit bugs, but I'm one step closer.

Looking at wcag vs accessibility, looks like there are more posts for accessibility:
http://www.tinymce.com/develop/bugtracker_bugs.php#!filter=accessibility...
http://www.tinymce.com/develop/bugtracker_bugs.php#!filter=wcag&status=o...

There are open bugs from 2008 there that should probably just be tested and marked closed. I'm assuming those ones have been fixed in later versions.

Yes we are working on closing the old imported bugs from when we had the tracker on Sourceforge, we still keep them cause we want to verify them being fixed though.

Just tag it with both if you want, so we can filter them out somehow.

Thye do not change that much? We had WCAG 1.0 in 1999 and then we got WCAG 2.0 in 2008 so not alot of changes compared to something like HTML5 specifications which do change weekly sometimes.

check out http://www.w3.org/WAI/WCAG20/quickref/ if you ever need some help, also Media Access is starting a new website to enable the locating of tools and resources I will post when it is completed as it will be in Drupal7 and must achieve level AA compliance, I am aiming to get WTAG as well in there but I will keep everyone posted on that, anyways.

We should be aiming for AA as that is what is endorsed by governments, for example in Australia all government websites must be AA complient by 2015 and at least A compliance by 2012

see http://www.sitepoint.com/australian-government-wcag-2-accessibility/

Also for the WYSIWYG we need to focus as well on ATAG http://www.w3.org/TR/ATAG20/ and also WAI-ARIA http://www.w3.org/TR/wai-aria/

There has been alot of work at the theme level to get these technologies working in Drupal the best I can see that enables WAI-ARIA etc is http://drupal.org/project/boron

anyways just some info from an accessiblity advocate and also someone who uses assistive browser technolgoies ;)

Hi, great to see TinyMCE Dev onboard I am in the process of writting up an evaluation of TinyMCE and CkEditor. The ATAG and WAI-ARIA roles seem to be implemented from a users point of view, as in for people editing with screen readers.

Though I see that the actual output needs some further work for both also I can see that both can be made more accessible with plug-ins and changes to what buttons etc are allowed etc.

Do you have any quick link resoruces I could check at TinyMCE and accessiblity compliance for the output?

Also what I feel is going to be important for the community is how much we can extend and add to whatever editor we choose.

We will need to be able to not only contribute changes back into the editor but be able to extend it from a module point of view for Drupal. And then maybe we should start a tag for the add-on modules as in tagging if it complies with AA WCAG or if does not. That way somebody wanting to maintain AA compliance will have a better way of knowing for example if a file picker will break the ATAG, WAI-ARIA or WCAG guidelines? Just a suggestion but seems like doing something like the D7 hashtag but for accessiblity could work well?

tagging this as a future thought to consider, maybe...

@amaree No I don't really have any quick links for that, it's quite a lot of a configuration/implementation issue when it comes to the output, we provide the flexibility. And any help testing/debugging the compliance is very very welcome.

We do have unit tests on quite a few things, but mostly related to the editor gui itself if i remember correct.

https://github.com/tinymce/tinymce/tree/master/tests

Count me in as a representative of CKEditor, other guys will surely follow when needed. It's a great initiative and since we have quite some experience in connecting a WYSIWYG editor with the Drupal core (the CKEditor for Drupal module is in active development since a few years already and we have some dedicated developers working exclusively on the Drupal integration), we would be most happy to help out.

Accessibility has always been a crucial issue at CKEditor, here are some resources from our side that I can recommend for a start:
http://docs.cksource.com/CKEditor_3.x/Users_Guide/Accessibility
http://ckeditor.com/blog/CKEditor_and_WAI-ARIA_means_Usable_Accessibility

In any case, we would love to help with the tight integration of CKEditor and Drupal and can offer considerable experience in integrating an advanced WYSIWYG capability into a CMS system.

@amaree - if you have any particular questions regarding accessibility support in CKEditor, feel free to get in touch with us.

@quicksketch, @webchick and anyone interested - please do not hesitate to contact us if you have any questions regarding CKEditor features or any ideas on how to improve Drupal support in our editor. Ditto if you encounter any blocker while working with CKEditor.

Any time you need help from someone from the CKEditor team, feel free to contact Wiktor Walc: wwalc or me me.

@Anna_CKSource - can you point us to the CKEditor issue queue for accessibility issues? I'd post the same questions to the CKSource team about accessibility as I did to TinyMCE up in #32. It's useful to know more about the team that is addressing accessibility issues.

We had a very interesting discussion thread also about discoverability with the BUEditor, but there are issues here that apply to both CKEditor & TinyMCE:
#1306752: Accessibility problems with the BUEditor

@mgifford - the easiest and quickest way is to report the issues on our Development site and set the Component field to Accessibility. If the issue only occurs in the Drupal integration, please be so kind as to mention it in the ticket.

Here is the current queue of open accessibility issues.

See this article for ticket specs if you need any tips on how the tracker works.

If you have any specific questions about our accessibility support, do not hesitate to contact me or wwalc directly.

@mgifford - regarding the ARIA support that was missing in BUEditor, I can write that CKEditor already supports it since two years (starting from version 3.2). We've worked on it in the following ticket: http://dev.ckeditor.com/ticket/4502

You can learn more about accessibility support in the blog post that Anna already mentioned:
CKEditor + WAI-ARIA = Usable Accessibility.

Keyboard shortcuts are documented here: Users Guide - Keyboard Shortcuts.

Of course since introducing the ARIA support, we have improved many things (see the list of closed tickets with component set to Accessibility). For example, following the advice from the IBM accessibility experts, we have introduced the ability to group buttons, so that it was easier to navigate with keyboard and work with screen reader: http://dev.ckeditor.com/ticket/5647

It is also worth of mentioning, that CKEditor officially supports JAWS and High Contrast mode, as explained in the CKSource Graded Browser Support article.

My 2c here...

I know that accessibility is a major concern and the fact that this issue here has shifted conversation/focus in that area proves it. I also realize that this is not a place to start "flame wars" over which editor is "the best", but...

[Nathan is right, my comment doesn't belong here. So, I moved it over to: #1260052-12: Candidate WYSIWYG editors]

I'm in but I'm new. Don't know where to start.

@akmalfikri - I'm sorry that nobody got back to you on this issue. There is certainly more still to look at for CKEditor is now in D8 Core.

But I'm going to close this issue now as this call for volunteers is no longer active.