The Authoring Tools List provides information on tool accessibility for procurers and users choosing an authoring tool.
For background on authoring tool accessibility, see the Authoring Tool Accessibility Guidelines (ATAG) Overview. Under 'Who ATAG is for', you can find the types of tools that are in scope for this authoring tools list.
We invite you to use this form to submit your authoring tool to the list. When you submit the form, the data is publicly available in GitHub. We will process it and add it to the list or contact you — usually within 2 weeks. If you have any questions, please send them to: group-wai-list-authoring-tools@w3.org
Only the first few form fields are required. You can submit your tool now with some questions left unanswered, and provide an updated submission later.
When you submit your information, if you get a "Something went wrong" message, you can usually use the browser's back functionality to get back to your data. If you have questions, e-mail group-wai-list-authoring-tools@w3.org
We'd like to know who you are, so that we can contact you with questions about your submission.
Provide some information about your tool. We will list this with the tool.
Pick what best describes the license used by your tool.
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 'See also's below refer to the section of ATAG.
The full editing experience conforms to WCAG 2.0 (or other accessibility guidelines). See also: A.1.1
You selected partial support.
Please describe what your support looks like, for example “accessible templates are available, but it is not very easy to find them. Improvements in search will be available in version 11”.
We will display this description with your tool, to help people find what they need.
You selected not applicable. We will not list this criterion for your tool.
You selected not sure. We will not list this criterion for your tool.
If the interface is not on the web, it conforms to platform-specific accessibility guidelines. See also: A.1.2
If there is anything visible that is not text, like icons, images or video, there is alternative text available. See also: A.2.1
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
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
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, like videos, including previews of that kind of content, can be paused or turned off. See also: A.3.3
Users can navigate quicker by structure, for example headings, lists or HTML elements. See also: A.3.4
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
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
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
Lets users undo changes and settings. See also: A.4.1
Documents all features, including accessibility features. See also: A.4.2
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
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
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 are guided to produce accessible content. See also: B.2.2
There is a tool for providing text alternatives to “non-text content”, like images, videos and data visualisation. See also: B.2.3
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
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
Has built-in checks for common accessibility problems, for example a check to identify missing alternative text. See also: B.3.1
Provides suggestions to content editor about accessibility problems. See also: B.3.2
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
Provides suggestions to content editor about accessibility problems. See also: B.4.2
Let us know if you have any comments. This comment will be publicly available in GitHub, and not published on the tools list.
When you submit the form, we will review your tool and add it to the list. This should take 1-4 weeks.
Please review the information provided. If you need to correct any information, you can go back to the form and then proceed to your submission.