This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.

Submit an authoring tool

Back to List of Authoring tools

The Authoring Tools List shows tools from different vendors, so that people can make informed decisions when they choose an authoring tool.

We'd like to display as many authoring tools as we can, we welcome you to submit yours using this form.

Note: all information will be publicly available as this page generates a Pull Request on our GitHub repository.

About you

We'd like to know who you are, so that we can contact you with questions about your submission.

About the tool

Provide some information about your tool. We will list this with the tool.
Cost model (required)

Pick what best describes what using your tool would cost.

Accessibility features

Tell us which accessibility features are supported by your tool (fully or partially), so that we can list this. If you explain what support looks like, we will also list that information.

The authoring tool user interface follows applicable accessibility guidelines

Web-based functionality is accessible

The full editing experience conforms to WCAG 2.0 (or other accessibility guidelines). See also: A.1.1

Non-web-based functionality is accessible

If the interface is not on the web, it conforms to platform-specific accessibility guidelines. See also: A.1.2

Editing-views are perceivable

Alternative content available to editors

If there is anything visible that is not text, like icons, images or video, there is alternative text available. See also: A.2.1

Editing-view presentation can be programmatically determined

Status indicators (like changes or spelling errors) and text properties (like italics or bold) are conveyed to users of assistive technologies. See also: A.2.2

Editing-views are operable

Works with keyboard

Everything that can be done with a mouse, can just as easily be done with a keyboard, including drag and drop and drawing capabilities. There should be no keyboard traps. Keyboard usage should be efficient and easier to use than just with sequential access (for example: use WAI-ARIA landmarks or offer keyboard shortcuts). See also: A.3.1

Enough time

Time limits in the editor, like for auto-save, can be turned off or extended (some exceptions apply). See also: A.3.2

Flashing content optional

Flashing content, like videos, including previews of that kind of content, can be paused or turned off. See also: A.3.3

Content can be navigated by structure

Users can navigate quicker by structure, for example headings, lists or HTML elements. See also: A.3.4

Content searchable

Users can search in text content, results are focused when shown. If there are no matches, this is indicated. User can search in two directions (backwards and forwards). See also: A.3.5

Supports display preferences

If there are user settings for display, this only affects the editing view, not the output. If a content editor uses OS settings like high contrast mode or their own stylesheet, this does not break the editing experience. See also: A.3.6

Previews are accessible

When the tool shows a preview of the content, that preview is at least as accessible as in current browsers and other user agents. See also: A.3.7

Editing-views are understandable

Helps editor prevent and correct mistakes

Lets users undo changes and settings. See also: A.4.1

(Accessibility) features documented

Documents all features, including accessibility features. See also: A.4.2

Fully automatic processes produce accessible content

Generates accessible markup

When the tool generates markup, that markup is accessible. If accesssibility information is required, like alternative texts, the content editor is prompted to provide that information. See also: B.1.1

Preserves accessibility information

If content is pasted from a word processor or converted from one format into another, any accessibility information is preserved. See also: B.1.2

Supports producing accessible contentt

Accessible content production is possible

If some options produce more accessible content than others, they are displayed more prominently. If properties and attributes can be set, those relevant for accessibility can also be set. See also: B.2.1

Editors guided

Editors are guided to produce accessible content. See also: B.2.2

Text alternatives can be managed

There is a tool for providing text alternatives to “non-text content”, like images, videos and data visualisation. See also: B.2.3

Accessible templates available

There are accessible templates available. If there is a repository of templates, it is easy to find the ones that prioritise accessibility. See also: B.2.4

Accessible components/plug-ins available

If any components or plugins are built-in to the tool, they are accessible. If there is a gallery of components or plug-ins, it indicates accessible options. See also: B.2.5

Helps with improving the accessibility of existing content

Checks accessibility automatically

Has built-in checks for common accessibility problems, for example a check to identify missing alternative text. See also: B.3.1

Helps content editors fix problems

Provides suggestions to content editor about accessibility problems. See also: B.3.2

Promotes and integrates accessibility features

Accessibility features prominent

Accessibility features are on by default and a prominent part of the editing workflow. Documentation shows examples of how to create accessible content, for instance with example markup or screenshots. See also: B.4.1

Documentation promotes accessibility

Provides suggestions to content editor about accessibility problems. See also: B.4.2

Submitting your tool

Let us know if you have any comments.

When you submit the form, we will review your tool and add it to the list. This should take 1-4 weeks.

Back to Top

This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.