Accessible. Faster. More Customizable.
Wed, November 30, 2016
In the last months we've been working on some great improvements for the Froala Editor. Yesterday we've wrapped them together into a new release V2.4.0-rc.1. It is for now a release candidate and will get out of the RC phase in a couple of weeks.
Froala Editor has always been about enabling a great editing experience in applications that rely on a web browser component. The editor’s UX got better and better release after release, but we have never fully focused on interacting with the editor using only the keyboard. Now, that moment has came. We redesigned how you can navigate through the entire interface: main editing area, toolbars, popups and modals. They are all keyboard accessible, therefore you can stop at anytime using the mouse and start using solely the keyboard.
The only keyboard combination that you should know to start the magic is ALT + F10. It brings the focus to the toolbar or active popup and from there you can simply navigate using the keyboard arrows, ENTER, TAB and ESC keys. It's been a long process that took around 2 months and we did lots of iterations in order to arrive where it is now. It was important for us to create a consistent navigation that you can easily get familiar with and use the editor interface naturally.
Next things we're focusing on the accessibility feature is adding ARIA states and making sure that everything is compliant with the Section 508 Standards. We have already started to work in this direction and any suggestions coming from you are always highly appreciated.
Typing is the core of the WYSIWYG HTML editors and all the rich text editors rely on the browser's contenteditable attribute. However, there is no official standard for it and every browser is implementing the keyboard actions differently producing inconsistent outputs. At Froala, we're using the browser editable feature only as basic support and all the keyboard sensitive actions such as enter, backspace, delete or space have their custom implementation. This is of course adding an overhead on the typing performance and working directly with the DOM in the right way is essential.
If initially we were using jQuery, in the release 2.4.0 all operations related to typing are performed directly on the DOM with a minimum possible overhead. This enables our WYSIWYG HTML editor to edit at the same speed both small and large amounts of text. And when I'm saying large amounts, I really mean large, like 10 million words.
Since now there was the possibility to add custom buttons, dropdowns and popups, but the modals were missing. Therefore, a module for modals, together with a help plugin, is the last but not the least major addition in the new release. We've been asked by dozens of you if there is the possibility to create a modal similar to the Image Manager one. Now that is possible, and you can put anything you want in its head and body. More details will come shortly in docs for creating them.
I invite you all to give it a try to the new V2.4.0-RC.1 release and send us your feedback and suggestions through the comments below or using our contact page.