Authoring Tool Accessibility Guidelines 2.0 - Composr version 10.0 compliance
Written by Chris Graham (ocProducts)
The document is brief, but the developers are happy to clarify any issues that organisations or individuals may have, and if any flaw is found in our compliance, we will work to fix this.
At the time of writing we believe Composr does indeed fully comply with ATAG, and we have made numerous changes to get Composr to that point.
Some of the wording in the specification is, however, not completely appropriate to the kind of tool Composr is, and hence some guidelines are met in spirit rather than a strict literal interpretation would require; we believe that this is reasonable and expected.
Conformance profile
Product: ComposrVendor: ocProducts
Version: 10.0.0
Language: British English
Authoring tool functions available: Code-level, WYSIWYG, Indirect, Object-orientated
ATAG version: 2.0 Working draft, 23rd November 2005
ATAG level: Triple-A
WCAG version: 1.0 [most of the checkpoints for WCAG 2.0 are met]
URL to this document: https://compo.sr/docs10/atag.htm
User agents: Microsoft Edge 20, Internet Explorer 11, Firefox 40, Google Chrome 45, Safari 8
Content-type: XHTML 5.0 + CSS 2.1 [ + optional JavaScript: JavaScript may not be accessible, therefore it is assumed to be disabled for the purposes of accessibility]
WCAG Compliance details
Note: As Composr is web-based, all success criteria met by meeting WCAG, or met automatically, have been omitted.ATAG checkpoint said
The author must be able to configure the presentation settings of editing views without affecting the Web content being edited.
Composr has a high separation between document structure and presentation, allowing the user to use their own browsing style-sheets, browser zoom.
All of the administrative interfaces are configurable by editing templates.
All the administrative interfaces meet WCAG.
Most interfaces are abstract from the actual content, as they operate on a declarative level rather than a WYSIWYG level. Those interfaces that are WYSIWYG also support 'Comcode', which is a text language that may be fully edited non-visually.
ATAG checkpoint said
There must be an option to add and modify key-plus-modifier-key (or single-key) access to all selectable actions.
This is not feasible in a simple form, as the very-limited number of web-safe access-keys are already used within the system (for the system as a whole to be accessible). However, as all interfaces are template driven, behaviour may be fully edited by an experienced user who knows HTML and Composr's Tempcode.
ATAG checkpoint said
There must be an option to customize the items (from the set of all selectable actions) and their order within at least one area of the user interface that is controllable by a single selection (e.g. button bar, palette, panel, etc).
The non-administrative interfaces are menu driven, by default. These menus may freely be reordered, thus meeting the 'at least one' sub-criteria. The administrative interfaces are icon-driven and these icons are ordered alphabetically.
ATAG checkpoint said
For any structured element set, the author must always be able to move the editing focus from any element to any other element with the following relationship (if they exist): the element immediately above (i.e. parent), the first element immediately below (i.e. child), the element immediately preceding at the same level (i.e. previous sibling), and the element immediately following at the same level (i.e. next sibling).
Focus may be shifted by pressing tab, as is standard for web browsing interfaces.
ATAG checkpoint said
For any structured element set, the author must always be able to select content and perform editing functions (e.g. cut, copy, paste, styling) on any element along with any content, including sub-elements.
'element' would refer to some aspect of a Composr 'resource', rather than resources as a whole. Standard browser and WYSIWYG features provide such control as to meet this criterion.
ATAG checkpoint said
The authoring tool must provide the ability to save and reload all configuration settings related to visual or auditory output and keyboard operability.
As the interface is that of a web interface, such configuration would be stored in a user's own web browser. It is assumed that different users use different web browser installs. If more control is needed than a web browsers CSS override and view settings can provide, it is possible to edit templates to distinguish between users and usergroups - as this criteria is rationalised in order to allow personal settings, this should meet the criteria.
ATAG checkpoint said
The author must be able to select, within the application, from multiple configuration sets.
This may be performed as users of the Composr system have their own profiles. Web browser or operating system profiles may give further control.
ATAG checkpoint said
If a preview is provided, then:
As Composr is administered inside a web browser, any supported web browser may be used to view the preview.
ATAG checkpoint said
At least one version of the documentation must conform to the minimum requirements (Level 1) of WCAG (whether delivered on the Web, CD-ROM, etc.).
The documentation meets the same level of compliance as Composr itself.
ATAG checkpoint said
All features that benefit the accessibility of the authoring interface must be documented in the help system (e.g., keyboard shortcuts).
There are accessible authoring and keyboard-map tutorials. Other information is provided in other tutorials.
ATAG checkpoint said
The current configuration of selectable actions must be displayed in either a centralized fashion (e.g., a list of keyboard shortcuts) or a distributed fashion (e.g., by listing keyboard shortcuts in the user interface menus).
The web browser performs this function.
ATAG checkpoint said
Any authoring tool that chooses the content type used for publication on the Web for the author must always choose content types for which a published content type-specific WCAG benchmark exists.
This document provides that benchmark.
ATAG checkpoint said
Any authoring tool that allows authors to choose the content type used for publication on the Web must always support at least one content type for which a published content type-specific WCAG benchmark exists and always give prominence to those content types.
This document provides that benchmark, and prominence is given.
ATAG checkpoint said
All transformations and conversions supported by the authoring tool must always meet both of the following conditions
Composr does not perform transformations/conversions on mark-up, other than on mark-up of languages that are controlled by the developers and hence always fully understood.
ATAG checkpoint said
All markup and content that is automatically generated by the authoring tool (i.e. not authored "by hand") must always conform to WCAG.
This is considered a core part of our WCAG compliance.
ATAG checkpoint said
Any Web content (e.g., templates, clip art, example pages, etc.) that is bundled with the authoring tool or preferentially licensed to the users of the authoring tool (i.e. provided for free or sold at a discount), must conform to WCAG when used by the author.
This is considered a core part of our WCAG compliance.
ATAG checkpoint said
Every time that content that requires accessibility information from the author in order to conform to WCAG is added or updated, then the authoring tool must inform the author that this additional information is required (e.g. via input dialogs, interactive feedback, etc.).
The interface captions provide explicit information about accessibility. Where documentation would be required to understand how to use advanced functionality (such as typing Comcode directly), the documentation makes accessibility issues clear.
ATAG checkpoint said
Whenever the tool provides instructions to the author, either the instructions (if followed) must lead to the creation of Web content that conforms to WCAG, or the author must be informed that following the instructions would lead to Web content accessibility problems.
This is considered a core part of our WCAG compliance.
ATAG checkpoint said
An individual check must be associated with each requirement in the content type benchmark document (i.e. not blanket statements such as "does the content meet all the requirements").
The Composr webstandards checker will check all criteria, although some are non-pragmatically verifiable and hence the checks for these provide information rather than error reports.
ATAG checkpoint said
For checks that are associated with a type of element (e.g. img), each element instance must be individually identified as potential accessibility problems. For checks that are relevant across multiple elements (e.g. consistent navigation, etc.) or apply to most or all elements (e.g. background color contrast, reading level, etc.), the entire span of elements must be identified as potential accessibility problems, up to the entire content if applicable.
This is how the webstandards checker works; it only uses global context for building up information to do fully local checking.
ATAG checkpoint said
If the authoring tool relies on author judgment to determine if a potential accessibility problem is correctly identified, then the message to the author must be tailored to that potential accessibility problem (i.e. to that requirement in the context of that element or span of elements).
This is the case - errors are targeted.
ATAG checkpoint said
The authoring tool must present checking as an option to the author at or before the completion of authoring.
If an author does not immediately validate the item, then they can see an error 'before completion'; otherwise they see it at completion. They may also generate previews before anything is submitted, and these previews would show the problems before the actual preview was viewable.
ATAG checkpoint said
For each potential accessibility problem identified by the checking function (required in checkpoint B.2.2) provide at least one of the following:
Information is provided in the error that details the problem and the solution is either obvious from this, or also mentioned.
ATAG checkpoint said
When the author inserts an unrecognized non-text object, the tool must never insert an automatically generated text equivalent (e.g. a label generated from the file name).
This never happens.
ATAG checkpoint said
When the author inserts a non-text object for which the tool has a previously authored equivalent alternatives (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool must always prompt the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent.
This does not really apply - object re-use is not a concept appropriate to Composr. Attachments may be re-used and the caption is known with certainty and hence re-used, however it may be changed to differ from the original usage if so desired by the author.
ATAG checkpoint said
The authoring tool must always keep a record of alternative equivalents that the author inserts for particular non-text objects in a way that allows the text equivalent to be offered back to the author for modification and re-use if the same non-text object is reused.
Attachments do this.
ATAG checkpoint said
The authoring tool must provide an option to view a list of all known accessibility problems (i.e. detected by automated checking or identified by the author) prior to completion of authoring.
The Composr webstandards checker does this.
ATAG checkpoint said
All features that play a role in creating accessible content must be documented in the help system.
There is a tutorial intended solely for this purpose.
ATAG checkpoint said
All examples of markup and screenshots of the authoring tool user interface that appear in the documentation and help must demonstrate accessible Web content.
This is the case. It is not easy to create inaccessible content in Composr and examples are usually basic and thus accessible.
ATAG checkpoint said
A tutorial on the accessible authoring process for the specific authoring tool must be provided.
There is a tutorial intended solely for this purpose.
ATAG checkpoint said
When the author has more than one authoring option for a given task (e.g. changing the color of text can be changed with presentation markup or style sheets) then any options that conform to WCAG must have equal or higher prominence than any options that do not.
This is considered a core part of our WCAG compliance.
ATAG checkpoint said
Any choices of content types or authoring practices presented to the author (e.g., in menus, toolbars or dialogs) that will lead to the creation of content that does not conforms to WCAG must be marked or labeled so that the author is aware of the consequences prior to making the choice.
This is considered a core part of our WCAG compliance.
ATAG checkpoint said
All accessibility prompting, checking, repair functions and documentation that is continuously active must always be enabled by default and if the author disables them (e.g. from a preferences screen), then the tool must inform the author that this may increase the risk of accessibility problems.
The webstandards checker is on by default with accessibility checks on by default. It is clearly labelled that disabling this will increase the risk of accessibility problems.
ATAG checkpoint said
All user interface controls for accessibility prompting, checking, repair functions and documentation must have at least the same prominence as the controls for prompting, checking, repair and documentation for other types of Web content problems (e.g. markup conformance, program code syntax, spelling and grammar).
The prominence is extremely high - the system will actually put up a blocker page that the administrators need to click through each time they view invalid content. All errors quoted are fixable, and hence the blocking is informative rather than problematic.
ATAG checkpoint said
Any authoring tool feature that helps to sequence author actions (such as object insertion dialogs, design guides, templates, wizards, tutorials, or instruction text) must integrate relevant accessibility prompts at or before the author is required to make the authoring decision related to the prompt (e.g. finalize a page design wizard or an image insertion operation).
Any accessibility information that is required is requested as an integral part of the operation, not as an 'addon'. If manual input of HTML is being performed, the webstandards checker would pick up on any problems. Hence this is not totally appropriate, but is in essence complied with.
ATAG checkpoint said
The configurability of all functions related to accessibility prompting, checking, repair, and documentation must at least match the configurability of other prompting, checking, repair, and documentation functions of the tool (respectively), in terms of both of the following
Checking and repair is configurable using a number of checkboxes that control what aspects are checked.
Prompting for what will constitute accessibility information is an integral part of the system, and hence the criteria are met in essence.
Documentation is not configurable.
WCAG Compliance details
Our WCAG compliance is detailed in a separate document.This is because the information is important for those who modify templates in Composr, so that they understand the techniques we have used and know how to apply them themselves.
Feedback
Please rate this tutorial:
Have a suggestion? Report an issue on the tracker.