ARIA Described

This website contains links to software which is either no longer maintained or will be supported only until the end of 2019 (CKFinder 2). For the latest documentation about current CKSource projects, including software like CKEditor 4/CKEditor 5, CKFinder 3, Cloud Services, Letters, Accessibility Checker, please visit the new documentation website.

If you look for an information about very old versions of CKEditor, FCKeditor and CKFinder check also the CKEditor forum, which was closed in 2015. If not, please head to StackOverflow for support.

This page provides technical information about the ARIA support provided in CKEditor (starting at version 3.2.).

CKEditor 3.2 is fully "ARIA aware". In fact all the accessibility support preset in the editor core has been switched to ARIA, without considering specific accessibility requirements and limitations existing on browsers and assistive technology (mostly).

Currently Firefox 3.5+ and JAWS 11 provide the best accessibility experience with CKEditor. These tools are our recommendation when accessibility is needed. IE8 is also a good option, but not as good as Firefox 3.5.

The "application" root

Each of the editor instances is enclosed into the following element, placed in the exact DOM location we expect the editor to be shown:

<span id="cke_[editor-name]" role="application" aria-labelledby="cke_[editor-name]_arialbl" ...>
    <span id="cke_[editor-name]_arialbl">Rich Text Editor</span>
    ....
    [ Here goes the editor ]
    ....
</span>

This created a landmark in the page for each editor, and ATs should enter in application mode when reaching it.

The inner structure

Inside the application root, we have a complex structure that defines the editor interface. We have a couple of <span> elements holding a <table> element which defines the main editor spaces: top, contents and bottom. This complex structure is necessary to workaround CSS limitations present in some browsers (IE6/IE Quirks).

Here is a simplification of it:

<span ...>
    <span ...>
        <table ...>
            <tr><td class="cke_top" ...>
                [ Top elements ]
            </td></tr>
            <tr><td class="cke_contents" ...>
                [ Contents elements ]
            </td></tr>
            <tr><td class="cke_bottom" ...>
                [ Bottom elements ]
            </td></tr>
        </table>
    </span>
</span>

All elements in this structure are marked with the "presentation" role. In this way they are ignored in the accessibility description of the page.

The Toolbar

The editor toolbar is rendered, by default, into the top space of the inner editor structure. Internally, it's called instead "toolbox", which holds a series of small "toolbars".

The following represents its structure:

<div role="toolbar" class="cke_toolbox" aria-labelledby="cke_[number]">
    <span id="cke_[number]">Toolbar</span>
    ...
    [ "n" toolbars]
    ...
</div>

Inside the above toolbox we'll have then several "toolbars", each of them having the following structure:

<span class="cke_toolbar" role="presentation">
    ...
    [ "n" toolbar groups ]
    ...
</span>

Each toolbar will then contain a series of "toolbar groups", with the following structure:

<span class="cke_toolgroup" role="presentation">
    ...
    [ "n" toolbar items ]
    ...
</span>

This complex structure makes the UI quite flexible, so rich skinning is possible.

Finally, the toolbar groups hold the toolbar items. Currently, the following types of items are available: Button, Menu Button and Combo Box.

When moving the UI focus into the toolbar (ALT+F10), it's first element is focused.

Toolbar Button

The following is the structure of a toolbar Button (e.g. the Source button):

<span class="cke_button">
    <a role="button" aria-labelledby="cke_5_label" tabindex="-1" title="Source">
        <span class="cke_icon"></span>
        <span class="cke_label" id="cke_5_label">Source</span>
    </a>
</span>

Toolbar Menu Button

The following is the structure of a toolbar Menu Button (e.g. the Text Color button):

<span class="cke_button">
    <a role="button" aria-haspopup="true" aria-labelledby="cke_75_label" tabindex="-1" title="Text Color">
        <span class="cke_icon"></span>
        <span class="cke_label" id="cke_75_label">Text Color</span>
        <span class="cke_buttonarrow"></span>
    </a>
</span>

Toolbar Combo Box

The following is the structure of a toolbar Combo Box (e.g. the Font Size combo box):

<span class="cke_rcombo">
    <span class="cke_fontSize cke_off" id="cke_73">
        <span class="cke_label" id="cke_73_label">Size</span>
        <a role="button" aria-haspopup="true" aria-labelledby="cke_73_label" aria-describedby="cke_73_text" tabindex="-1" title="Font Size">
            <span>
                <span id="cke_73_text">[ Current Value ]</span>
            </span>
            <span class="cke_openbutton"></span>
        </a>
    </span>
</span>

For the visually impaired, what we graphically represent and call as combos will act just like Menu Buttons. This is done because the user must activate it by pressing space bar, instead of changing their values directly with the arrow keys. This brings no usability impact to the visually impaired.

When activating (opening) a combo, a floating panel is created on the fly, holding the list of items available for that combo. The following structure represents it:

<div role="presentation">
    <div role="presentation">
        <iframe role="listbox" aria-label="Font Size">

            <html>
                <head></head>
            <body>
                <div tabindex="-1" role="presentation">
                    <h1 role="presentation">Font Size</h1>
                    <ul role="presentation">
			<!-- Item -->
                        <li>
                            <a role="option" aria-posinset="1" title="8" aria-setsize="16">
                                <span>8</span>
                            </a>
                        </li>
                        ...
                        [ Repetitions of the above <li> structure for each item in the list ]
                        ...
                    </ul>
                </div>
            </body>
            </html>

        </iframe>
    </div>
</div>

After opened, the UI focus is set to the "listbox" <iframe>. Then, when using the ARROW-DOWN key, the first list item is focused.

The Elements Path

The Elements Path is rendered at the bottom space of the inner structure of the editor. The following represents its structure scheme:

<span id="cke_path_editor1_label">Elements path</span>
<div role="group" aria-labelledby="cke_path_editor1_label">
    <a role="button" aria-labelledby="cke_elementspath_2_2_label" title="body element" tabindex="-1">
        body
        <span id="cke_elementspath_2_2_label">body element</span>
    </a>
    ...
    [ Several of the above <a> structures for each element ]
    ...
</div>

When moving the UI focus into the elements path (ALT+F11), the button representing it's deeper element is focused.

The Editing Area

The editing area is rendered into the contents space of the inner editor structure. By default the editor provides two editing modes: WYSIWYG and Source.

WYSIWYG Mode

In WYSIWYG mode, the editor renders an <iframe> element, setting its contents as editable through the contenteditable attribute in the <body> element (for IE only) or the document.designMode DOM property (all other browsers).

The following represents this structure, including the inner document:

<iframe tabindex="0">
    <html>
        <head>
            <title>Rich text editor, editor1, press ALT 0 for help.</title>
        </head>
        <body>
        ...
        [ The raw HTML contents of the editor ]
        ...
        </body>
    </html>
</iframe>

Note that no ARIA attributes are used here. ATs should use the default role for HTML documents, which is "document", enhanced by the enabled editing support.

Source Mode

In Source mode, the editor simply renders a <textarea> element. The following represents its definition:

<textarea tabindex="0" role="textbox" aria-label="Rich text editor, editor1, press ALT 0 for help.">
    ...
    [ The raw HTML contents of the editor ]
    ...
</textarea>

Focus grabbing

The application root doesn't wait for user focus directly (tabindex=-1). It instead expects having elements inside of it that would participate in the page tabbing order.

In a standard editor installation, the editing area is the only element that participates into the page tabbing. The tabindex used for it is inherited from the <textarea> replaced by the editor, or even specified through the "tabIndex" setting.

In the WYSIWYG mode, the element that receives the focus is the <iframe> element that holds the editable document. In Source mode, we have instead a normal <textarea> element.

None of the other UI elements in the editor, like the toolbar or the elements path, will participate in the page tabbing order. Focus and tabbing in these elements is managed by the editor code.

Dialogs

Some of the editor commands open UI dialogs. Those are floating elements usually used to request user information for the creation and modification of specific elements, like links and tables.

The following is a sample for the full structure of a dialog, including it's basic UI elements (the Anchor dialog is used to exemplify):

<div role="dialog" aria-labelledby="cke_dialog_title_91">
    <table role="presentation">
        <tr><td role="presentation">
            <div role="presentation" class="cke_dialog_body">

                <!-- Title -->
                <div role="presentation" class="cke_dialog_title" id="cke_dialog_title_91">Anchor Properties</div>

                <!-- Close (X) button -->
                <a role="button" title="Close"><span class="cke_label">X</span></a>

                <!-- Tabs (optionally visible) -->
                <div role="tablist">
                    <a role="tab" aria-labelledby="info_98_arialbl" tabindex="-1" title="Anchor Properties">
                        <span id="info_98_arialbl">Anchor Properties</span>
                    </a>
                    ...
                    [ Repetitions of the above <a> for each tab ]
                    ...
                </div>

                <!-- Central contents -->
                <table role="presentation">
                    <tr><td role="presentation">
                        <div role="tabpanel" aria-hidden="false">
                            ...
                            [ Dialog contents ]
                            ...
                        </div>
                    </td></tr>
                </table>

                <!-- Footer buttons -->
                <div role="presentation" class="cke_dialog_footer">
                    <table role="presentation">
                        <tr><td role="presentation">
                            <a role="button" aria-labelledby="100_label" title="OK">
                                <span id="100_label">OK</span>
                            </a>
                        </td>
                        ...
                        [ The same <td> structure for the "Cancel" button ]
                        ...
                        </tr>
                    </table>
                </div>
            </div>
            ...
        </td></tr>
    </table>
</div>

As soon as the dialog is rendered, the UI focus is set into one of its content elements (usually an <input> element).

Tabbing inside dialogs is managed by the editor code.

Context Menu

The context menu is a floating element created on the fly at first open. This element holds an <iframe> element into which the menu contents is rendered.

The following represents its structure:

<div role="presentation">
    <div role="presentation">
        <iframe role="menu" aria-label="Options">

            <html>
            <head></head>
            <body>
                <div tabindex="-1" role="presentation">
                    <div role="presentation" class="cke_menu">
                        <!-- Menu item -->
                        <span class="cke_menuitem">
                            <a role="menuitem" tabindex="-1" title="Cut">
                                <span class="cke_icon_wrapper"><span></span></span>
                                <span class="cke_label">Cut</span>
                            </a>
                        </span>
                        ...
                        [ Repetitions of the above <span> structure of each menu item ]
                        ...
                    </div>
                </div>
            </body>
            </html>

        </iframe>
    </div>
</div>

When opened, the UI focus is set to the "menu" <iframe>. Then, when using the ARROW-DOWN key, the first menu item is focused.

Notes

  • Floating elements, like dialogs, context menus or combos and menu buttons panels, are not created inside the application root element. They are instead placed at the very end of the page structure, right before the </body> element closing. It's done in this way because a single panel can be used by more than one editor instance present in the page (to enhance performance and save resources).
  • We avoid using "aria-label", using instead "aria-labelledby". In an ARIA point of view, this is not necessary in most cases, and it even makes the DOM structure and our code more complex, but unfortunately IE has no support for "aria-label".
  • The aria-disabled attribute is properly used to indicate buttons and menu options that are disabled.
  • We use the <a> element for several UI elements (like buttons, menu items, tabs, etc). In this way we are able to use the :hover CSS pseudo-class, which is not supported in all elements in some browsers.
  • The HTML structures illustrated in this page are not complete, including exclusively the elements and attributes that have ARIA relevance or that enhances the structure understanding.
This page was last edited on 19 February 2010, at 13:15.