A.1.1.1 Web-Based Accessible (Level A): Web-based authoring tool user interfaces conform to WCAG 2.0 Level A. (Level A)

• Technique A.1.1.1-1 [Sufficient]: Following the requirements of WCAG Level A when developing any Web-based functionality.
• Technique A.1.1.1-2 [Advisory]: Testing Web-based authoring tool user interfaces using automated evaluation and repair tools.
  • Example: Throughout development of an authoring tool, with the tool in various representative states, the editing interface (including test content being authored) is tested using accessibility evaluation software. Problems are corrected and the process iterates.

A.1.1.2 Web-Based Accessible (Level AA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AA. (Level AA)

• See Techniques for A.1.1.1 using WCAG Level AA.

A.1.1.3 Web-Based Accessible (Level AAA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA. (Level AAA)

• See Techniques for A.1.1.1 using WCAG Level AAA.

A.1.2.1 Non-Web-Based Accessible (Level A): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) standards and/or platform conventions that benefit accessibility. (Level A)

• Technique A.1.2.1-1 [Sufficient]: The following is a non-exhaustive list of accessibility guidelines and best practice documents for various platforms:
  • Eclipse: "Designing Accessible Plug-ins in Eclipse" [ECLIPSE-ACCESS]
  • Gnome/KDE:
    • "GNOME Accessibility for Developers" [GNOME-ACCESS]
    • "Gnome/KDE Keyboard Shortcuts" [GNOME-KDE-KEYS]
  • Java:
    • "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java" [JAVA-ACCESS]
    • "Java accessibility guidelines and checklist" [JAVA-CHECKLIST]
  • Lotus Notes: "Lotus Notes accessibility guidelines" [NOTES-ACCESS]
  • Mac OS: "Accessibility Documentation" [APPLE-ACCESS]
  • "Mac OS X keyboard shortcuts" [MACOSX-KEYS]
  • Microsoft Windows:
    • "Accessibility for applications designers" [MS-ENABLE]
  • General Guides:
    • "Application Software Design Guidelines" [TRACE-REF]
    • "Ergonomics of human-system interaction -- Guidance on accessibility for human-computer interfaces" ISO standard [ISO-TS-16071]
    • "Designing for Accessibility" [SUN-DESIGN]
    • "[Electronic Information Technology Access Advisory Committee] EITAAC Desktop Software standards" [EITAAC]
    • "Making Educational Software and Web Sites Accessible" [EDU-SOFT-ACCESS]
    • "Software Accessibility" [IBM-ACCESS]
    • "What is Accessible Software" [WHAT-IS]

A.1.2.2 Non-Web-Based Accessible (Level AA): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) the "Level AA" requirements of standards and/or platform conventions that benefit accessibility. The "Level AA" requirements are those that are functionally equivalent to WCAG 2.0 Level AA success criteria. (Level AA)

• See Techniques for A.1.2.1, concentrating on requirements that are functionally equivalent to WCAG 2.0 Level AA.

A.1.2.3 Non-Web-Based Accessible (Level AAA): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) the "Level AAA" requirements of standards and/or platform conventions that benefit accessibility. The "Level AAA" requirements are those that are functionally equivalent to WCAG 2.0 Level AAA success criteria. (Level AAA)

• See Techniques for A.1.2.1, concentrating on requirements that are functionally equivalent to WCAG 2.0 Level AAA.

A.2.1.1 Recognized Alternative Content: If an editing view includes renderings of non-text content (e.g., WYSIWYG view), then authors have access to any alternative content for the rendered non-text content that are recognized by the authoring tool. (Level A)

• Technique A.2.1.1-1 [Sufficient]: When a rendered image has focus in an editing view, displaying its alternative content (e.g., short text labels, long text descriptions) as editable fields in a floating "properties" pane.
• Technique A.2.1.1-2 [Sufficient]: Allowing authors to call up a "properties" dialog for any rendered non-text object that displays its alternative content (e.g., short text labels, long text descriptions) as editable fields.
• Technique A.2.1.1-3 [Sufficient]: When appropriate for a Web technology (i.e., the technology is human-readable), providing an source content editing view that allows direct access to and editing of alternative content.
• Technique A.2.1.1-3 [Advisory]: Providing the alternative content via an platform accessibility architecture.
• Technique A.2.1.1-4 [Advisory]: Providing an option to toggle between rendered non-text objects and the text alternatives for the objects.
  • Example: An option to toggle fully rendered images with their text alternatives. On the left is the image (of the "earth rise" as seen from the moon) rendered as usual. On the right is a different rendering, this one including an area for editing the alternate text and a link to edit the long description. A small preview rendering of the image is included to provide context. (Source: mockup by AUWG)
    
• Technique A.2.1.1-5 [Sufficient]: In editing views that render multimedia, also displaying any associated synchronized alternatives (e.g., captions for video, captions for audio files, audio descriptions for videos).

A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of Web content to provide authors with additional information (e.g., underlining misspelled words), then that additional information is made available via the platform. (Level A)

• Technique A.2.2.1-1 [Sufficient]: Making available programmatically the semantics of any presentation that is added to the editing view by the authoring tool.
  • Example: A change tracking feature displays inserted text in green and deleted text in red with a strike through. Instead of implementing this using simple CSS selectors, the XHTML elements ins and del are used, since they have associated semantics.

A.2.2.2 Access to Text Presentation (Minimum): If any of the following text presentation properties are editable by the authoring tool (even via a different editing view), then if the property is rendered in an editing view (e.g., WYSIWYG view) it is made available via the platform (Level A):

• (a) text font,
• (b) text style (e.g., italic, bold),
• (c) text color, and
• (d) text size.

• Technique A.2.2.2-1 [Sufficient]: Making available via the platform, information on the size, font, foreground and background color, font weight, and position of any text that is under the control of the author.
  • Example: Using a WYSIWYG authoring tool, an author is able to mark a paragraph using a "footnote" style class, then query the text to check on the rendered size of the text to ensure that the styling information has been picked up properly.

A.2.2.3 Access to Text Presentation (Enhanced): If any text presentation property (text size, text positioning, etc.) can be modified by the authoring tool (even via a different editing view), then if the property is rendered in an editing view (e.g., WYSIWYG view) it is made available via the platform. (Level AAA)

• See Techniques for A.2.2.2, but for all text presentation properties rendered and editable by the authoring tool.

A.2.3.1 Independence of Display: Editing views that render content (e.g., WYSIWYG) allow the authors' visual display settings and audio display settings to take precedence in the editing view without affecting the Web content being edited (i.e., no effect on markup, style sheets, etc.). (Level A)

• Technique A.2.3.1-1 [Sufficient]: Providing the author with the ability to change the fonts, colors, sizing (zoom), etc. within editing views that render content (or by changing the platform display settings), independently of the ability to control the markup that is actually produced.
  • Example: A WYSIWYG authoring tool includes editing interface controls for setting the text and background colors as they will appear to the end user, but also includes a "View" area in its preference settings, where the author can choose to override the WYSIWYG rendering with their own text and background color settings.
• Technique A.2.3.1-2 [Advisory]: Allowing the author to specify a preferred style sheet that is used in the editing view to override the actual "published" style of the document.

A.3.1.1 Important Commands: If the authoring tool includes any of the following features, authors can enable key-plus-modifier-key (or single-key) access to them (where allowed by the operating environment) (Level A):

• (a) open help system,
• (b) open new content,
• (c) open existing content,
• (d) save content,
• (e) close content,
• (f) cut/copy/paste,
• (g) undo/redo, and
• (h) open find/replace function.

• Technique A.3.1.1-1 [Sufficient]: Providing key-plus-modifier-key (or single-key) access for all of the functions listed here.
  • Example: On a Windows platform, an authoring tool uses the following keyboard commands: opening help system (e.g., F1); open new content (e.g., ctrl-N); open existing content (e.g., ctrl-O); save content (e.g., ctrl-S); close content (e.g., ctrl-W); cut/copy/paste (e.g., ctrl-X, ctrl-C, ctrl-V); undo/redo (e.g., ctrl-Z, ctrl-Y); open find/replace function (e.g., ctrl-F, ctrl-H).
• Technique A.3.1.1-2 [Advisory]: Following platform conventions when choosing keystrokes, such as:
  • Mac OS: "Mac OS X keyboard shortcuts" [MACOSX-KEYS]
  • Windows: "Keyboard shortcuts for Windows" [MS-KEYS]
  • Gnome/KDE: "Gnome/KDE Keyboard Shortcuts" [GNOME-KDE-KEYS]
• Technique A.3.1.1-3 [Advisory]: Expanding direct keyboard access beyond the functions listed in this success criterion to other frequently used functions of a tool (e.g., to perform text formatting, move quickly between windows, etc.)

A.3.1.2 Avoiding Content Keyboard Traps: The authoring tool prevents keyboard traps by both of the following (Level A):

• (a) in the authoring tool user interface: if keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard keyboard navigation commands (e.g., TAB key) and
• (b) in the editing views that render content: a documented direct keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus) and a documented direct keyboard command is provided that will always move keyboard focus to the subsequent element that can receive focus.

A.3.2.1 Data Saved: If the authoring tool ends an authoring session due to a time limit (e.g., an authenticated session expires), then authors have the global option to ensure that the Web content being edited is saved. For Web-based authoring tools, this applies to any Web content that has already been submitted to the server by the user agent. (Level A)

• Technique A.3.2.1-1 [Sufficient]: If an auto-save feature is present, ensure it performs a save prior to any time-outs.

A.3.2.2 Timing Adjustable: If the authoring tool includes time limits, then authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g. pressing the enter key to accept more time). (Level A)

• Technique A.3.2.2-1 [Sufficient]: Providing a preference setting to universally extend all authoring tool-controlled time limits.
• Technique A.3.2.2-2 [Sufficient]: Allowing the author at least 20 seconds to extend authoring-controlled time limits whenever they occur.

A.3.2.3 Moving Targets: If a user interface component that accepts mouse input is capable of movement (e.g., animated vector graphic), provide authors with the option to stop the movement. (Level A)

• Technique A.3.2.3-1 [Sufficient]: All components that can be targets for author actions can be stopped.
  • Example: In a timeline-based animation editor, a draggable time indicator moves when the animation is being previewed. This movement can be stopped with the "Stop" button.

A.3.3.1 Static View: If an editing view renders time-based content (e.g., animations), provide authors with the global option of rendering only the initial state of time-based content. (Level A)

A.3.4.1 Edit by Structure: If an editing view displays a structured element set, then authors can select any element in the structured element set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements. (Level A)

• Technique A.3.4.1-1 [Sufficient]: Ensuring that when an element is selected, any content, including sub-elements, of the element are also selected. Then, ensuring that when a selected element with content, including sub-elements, is the subject of an operation (cut, copy, styling, delete) the element's content should also be subject to the same operation unless the operation targets the element only. Note that various editing functions will apply differently when performed on a selected element. These differences might be classified according to their scope, as follows:
  (a) "element, content and sub-elements": These functions target the entire selection. Examples of these functions include cut, copy, and delete.
  • Example: In an HTML editor , when a <table> element is selected and the "delete" operation is performed, the entire table is deleted including sub-elements ( <tr> and <td>) and any text content etc. within the table.
• (b) "element only": These functions only target the top level element of the selection, even if the effect cascades down to sub-element content when it is rendered. Examples of functions of this type include, "Emphasis" which should apply styling to the top level element (e.g., <p>) while not making any source changes to sub-elements (e.g., strong) (even though the content of sub-elements may be rendered differently) and "strip element tags" that deletes the markup of the top level element without affecting its sub-element.
  • Example: In an HTML editor, when a <table> element is selected and the "strip element tags" operation is performed, the operation targets the <table> only, so this set of tags is removed, leaving sub-elements ( <tr> and <td>) and any text content etc.
• (c) "content and sub-elements only": These functions target the content, including sub-elements of the top level element of the selection without having any affect on the markup of that top level element. An example of this might be a “Replace Contents” function:

A.3.4.2 Navigate By Element Type: If an editing view displays a structured element set, authors can move the editing focus forward/backward to the next instance of the same element. (Level AA)

A.3.4.3 Navigate By Headings: If an editing view displays a structured element set, authors can move the editing focus to the heading before or the heading after the element. (Level AA)

A.3.4.4 Navigate Tree Structures: If an editing view displays a structured element set, authors can move the editing focus from any element to the following other elements in the structured element set (if they exist) (Level AA):

• (a) Parent: the element immediately above,
• (b) Child: the first element immediately below,
• (c) Previous Sibling: the element immediately preceding at the same level, and
• (d) Next Sibling: the element immediately following at the same level.

• Technique A.3.4.4-1 [Sufficient]: Providing the ability to move focus from any element to the element that contains it (i.e., parent element), if any. Also providing the ability to move focus from any element to the first sub-element that it contains (i.e., first child element), if any. Also providing the ability to move focus from any element to the element immediately preceding it as a sub-element of the same parent element (i.e., previous sibling). Also providing the ability to move focus from any element to the element immediately following it as a sub-element of the same parent element (i.e., next sibling).
  • Example: An authoring tool in which a <tr> element has current focus and is therefore highlighted in the editing view. As well, breadcrumbs in the status bar trace the path from the root element to the current element, <html> <body> <table> <tr>. A pop-up menu from the selected element shows that keystrokes are available to move the selection focus to the parent element, <table>, of the current element, to the child elements, in this case two <td> elements and to the next and previous element pointed to by the same parent element (in this case to preceding and following <tr> elements). (Source: mockup by AUWG)
    
• Technique A.3.4.4-2 [Advisory]: Providing an "outline" or "structure" view of the document that organizes the structured element set into a document tree or graph.
• Technique A.3.4.4-3 [Advisory]: If loops are possible within the structured element set, providing a mechanism for alerting the author when they have completed a loop.
• Technique A.3.4.4-4 [Advisory]: Ensuring that a smooth transition exists between navigation via the content structure to a particular element and commencing to edit that element.

A.3.5.1 Text Search: Authors can perform text searches of Web content in which all of the following are true (Level AA):

• (a) Search All Editable: authors can search within any information that is text and that the authoring tool can modify (e.g., text content, text alternatives for non-text content, metadata, markup elements and attributes, etc. ).
• (b) Bi-Directional: authors can search forwards and backwards. [UAAG 2.0]
• (c) Case Sensitive: authors can search in both case sensitive and case insensitive modes. [UAAG 2.0]
• (d) May Switch Views: it is permissible to require that authors switch editing views to perform searching (e.g., from WYSIWYG view to a source content view to search for markup elements by name).

• Technique A.3.5.1-1 [Sufficient]: Supporting bi-directional, case sensitive searching for plain text sequences within the content (i.e., text between the open and close tags of an element, text in a content management database) and within text alternatives for non-text content (i.e., short text labels, long text descriptions, etc.) even when this textual information is actually encoded as part of the markup (e.g., as an attribute value).
  • Example: Searching for a term yields occurrences within regular page content but also in the alt-text of images, long descriptive text, and metadata values.
  • Example: Searching for the text string "able", with the source code option checked, yields results that include <table> elements.
• Technique A.3.5.1-2 [Advisory]: Providing structure-based searching that takes into account structural roles and relationships.
  • Example: A search facility that makes effective use of structure. Here the author has chosen to find the "element" with the name "img", "with attribute" "height" "equal to" "100", where each value in quotation marks was editable. The replacement action is to "set attribute" "height" to "50". The following checkbox options are available "match case", "ignore white space" and "search text alternatives". The facility also includes the following buttons "Find Next", "Find all", "Replace", "Replace All", "Close" and "Help". (Source: mockup by AUWG)
    
• Technique A.3.5.1-3 [Advisory]: Providing more advanced search options, such as:
  • text search options such as replacement, wildcard characters, whole word matching, search repetition, and highlighting of all occurrences.
  • option to search the content only, the markup only, or both.
  • use metadata (per WCAG 2.0 [WCAG20]) to assist searching of large collections, or of timed presentations.
  • for tools that manage a database or multiple files, provide a search function that can search through the different pieces of content at once.
  • allow the author to select an area by similarity to the search probe (e.g., closeness of color in an image editor, etc.)

A.3.6.1 Save Settings: Preference settings are stored for any of the following that the authoring tool controls (i.e., not controlled by the platform) (Level AA):

• (a) keyboard preference settings,
• (b) visual display settings, and
• (c) audio display settings.

• Technique A.3.6.1-1 [Sufficient]: Storing configuration options (not controlled by the platform) for (a) keyboard operability, (b) the visual display, (c) for the auditory display.
  • Example: In a Web-based authoring tool, the author must log in. Once they do, they are presented with display/control preferences profiles that they have previously customized. The author can change their profile at any time.

A.3.6.2 Multiple Sets: Choosing between multiple sets of preferences (e.g., personal profiles, personal settings) are supported for any of the following that the authoring tool controls (i.e., not controlled by the platform) (Level AAA):

• (a) keyboard preference settings,
• (b) visual display settings, and
• (c) audio display settings.

• Technique A.3.6.2-1 [Sufficient]: Providing the option of multiple configuration sets of options. Each set contains the configuration settings (not controlled by the platform) for (a) keyboard operability, (b) the visual display, (c) for the auditory display.

A.3.6.3 Options Assistance: An interactive mechanism helps authors configure options related to Part A. (Level AAA)

• Technique A.3.6.3-1 [Sufficient]: Providing a wizard that walks the user through the configuration options, providing explanations and previews of how the configuration options will change the display.
  • Example: The wizard follows an interview format, asking the author about general preference areas (e.g., seeing the screen, using the keyboard) and only becoming more detailed if the author affirms an area.

A.3.7.1 Return Mechanism: If a preview is provided, then it is possible for authors to return from the preview using only keyboard commands. (Level A)

A.3.7.2 Preview: If a preview is provided, then at least one of the following is true (Level A):

• (a) Existing User Agent: the preview makes use of an existing user agent that is specified in the conformance profile (e.g., opening the content in a third-party browser, browser component, video player, etc.)
• (b) Part A.1: the preview meets all of the Level A guidelines in Principle A.1 of these guidelines, or
• (c) UAAG: the preview conforms to the User Agent Accessibility Guidelines [UAAG].

• Technique A.3.7.2-1 [Sufficient]: Allowing the author to locate a user agent on the platform with which to perform the preview).
• Technique A.3.7.2-2 [Sufficient]: For Web-based authoring tools that are already running in a user agent, use that same user agent to perform be the preview.
• Technique A.3.7.2-3 [Advisory]: Allowing the author to maintain a list of user agents to be used for previewing.
• Technique A.3.7.2-4 [Advisory]: Helping the author to find a user agent to perform the preview, by auto-scanning the system for known user agents.
• Technique A.3.7.2-5 [Advisory]: Bundling user agent installer files or providing a list of download sites for appropriate user agents.
• Technique A.3.7.2-6 [Sufficient]: Ensuring that the entire preview (content view and the rest of the user interface) meets all of the requirements of Part A that might be applicable to a browser.
• Technique A.3.7.2-7 [Sufficient]: Providing conformance tests to show that the preview feature meets UAAG 1.0.

A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an "undo" function or include a warning to authors that the action is irreversible. (Level A)

• Technique A.4.1.1-1 [Sufficient]: All authoring actions are reversible.

A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible. (Level A)

• Technique A.4.1.2-1 [Sufficient]: All setting changes are reversible using the preferences.

A.4.1.3 Redo: Authors can immediately reverse the most recent "undo" action(s) (i.e., a "redo" function). (Level AA)

• Technique A.4.1.3-1 [Sufficient]: Including undo actions in the queue of the five most recent actions (see Techniques for A.4.1.1).

A.4.1.4 Multiple Undos: Authors can reverse at least 5 consecutive reversible authoring actions. (Level AAA)

• Technique A.4.1.4-1 [Sufficient]: Maintaining a queue of the five most recent actions (from most to least recent) and providing a function that can reverse the actions one-by-one starting with the most recent.

A.4.2.1 Document Accessibility Features: All features that are specifically required to meet Part A of these guidelines (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)

• Technique A.4.2.1-1 [Sufficient]: Documenting all aspects of the user interface covered by Part A of these guidelines (including keyboard accessibility, display configurability, etc.).
• Technique A.4.2.1-2 [Advisory]: Providing a documentation index to accessibility features.
• Technique A.4.2.1-3 [Advisory]: Providing additional forms of help, including context sensitive help.

A.4.2.2 Accessibility Feature Tutorials: Tutorials are provided for some of the features that are specifically required to meet Part A of these guidelines. (Level AAA)

• Technique A.4.2.2-1 [Sufficient]: Keyboard access tutorials are provided.

B.1.1.1 Tool Choice of Technologies: Only accessible technologies are ever automatically selected by the authoring tool. (Level A)

• Technique B.1.1.1-1 [Sufficient]: A Web content technology could be considered able to conform to WCAG Level A if multiple content developers have publicly claimed WCAG Level A conformance for content developed using the technology.
  • Example: A content management tool is implemented using HTML templates, JavaScript and CSS for both the user interface and author generated content. One factor in the developer choosing this combination of technologies is that Web resources already exist that are implemented using these technologies and that have publicly claimed WCAG Level A conformance.
• Technique B.1.1.1-2 [Sufficient]: A Web content technology could be considered able to conform to WCAG Level A if a WCAG Techniques document exists for the technology, regardless of whether the author of the Techniques document is the W3C-WAI WCAG Working Group or a third party (e.g., the developer of a non-W3C document format).
• Technique B.1.1.1-3 [Sufficient]: Supporting W3C Recommendations, which have been publicly reviewed for accessibility. References include:
  • Technical Reports and Publications page of the W3C.
  • W3C language specific accessibility notes: CSS [CSS2-ACCESS], SMIL [SMIL-ACCESS], HTML4 [HTML4-ACCESS], SVG [SVG-ACCESS], XML languages [XAG].

B.1.1.2 Author Choice of Technologies: If the authoring tool provides authors with Web content technology options, then any accessible technology options that are suitable for the task are at least as prominent as any other technology options. (Level A)

• Technique B.1.1.2-1 [Sufficient]: When prompting authors to choose between technologies, begin the list with technology options that can conform to WCAG Level A (see Techniques B.1.1.1-1, B.1.1.1-2, B.1.1.1-3 for methods to determine the accessibility of the options).
  • Example: An authoring tool only claims ATAG 2.0 conformance for HTML documents, but allows production of CSS style sheets, and MathML. When the author requests a new document, HTML is the first technology listed.
• Technique B.1.1.2-2 [Advisory]: Displaying a warning when the author chooses to create Web content with a technology that cannot conform to WCAG Level A or with a technology that theoretically could conform to WCAG Level A, but for which the authoring tool does not provide accessibility support.
  • Example: A sample warning might read "Accessibility support is not available for documents in this format".

B.1.2.1 Target Preserves Accessibility Information: If the Web content technology of the output of a transformation or conversion can preserve recognized accessibility information that is required for that Web content to conform to WCAG 2.0 Level A, then the accessibility information is preserved and available for end users in the outputted Web content. (Level A)

• Technique B.1.2.1-1 [Sufficient ]: Preserve accessibility information in similar data structures.
  • Example: If converting between HTML and SVG the contents of alt attributes can be stored in desc attributes.
• Technique B.1.2.1-2 [Sufficient]: Where necessary, preserve accessibility information in a dissimilar, but accessible way.
  • Example: If transforming a SMIL presentation with a closed-caption text track into a video-only format, provide the option of an open-captioned video.
• Technique B.1.2.1-3 [Advisory]: When importing images with associated descriptions into a markup document, make the descriptions available through appropriate markup.
• Technique B.1.2.1-4 [Advisory]: Avoid transforming text into images. Use style sheets for presentation control, or use an XML application that keeps the text as text. If this is not possible, ensure that the text is available as equivalent text for the image.
• Technique B.1.2-1.5 [Advisory]: Notifying the author before changing the technology (including the DTD) of the content being authored.
• Technique B.1.2.1-6 [Advisory]: Allow authors to edit transformation or conversion templates to specify the way presentation conventions should be converted into structural markup.
• Technique B.1.2.1-7 [Advisory]: Ensure that changes to graphical layouts do not reduce readability when the document is rendered serially. For example, confirm the linearized reading order with the author.
• Technique B.1.2.1-8 [Advisory]: When transforming a table to a list or list of lists, ensure that table headings are transformed into headings and that summary or caption information is retained as rendered content.
• Technique B.1.2.1-9 [Advisory]: When converting linked elements (i.e., footnotes, endnotes, call-outs, annotations, references, etc.) provide them as inline content or maintain two-way linking.
• Technique B.1.2.1-10 [Advisory]: When converting from an unstructured word-processor format to markup, ensure that headings and list items are transformed into appropriate structural markup (appropriate level of heading or type of list, etc.).
• Technique B.1.2.1-11 [Advisory]: When developing automatic text translation functions, strive to make the resulting text as clear and simple as possible.

B.1.2.2 Target Cannot Preserve Accessibility Information: If the Web content technology of the output of a transformation or conversion cannot preserve recognized accessibility information that is required for that Web content to conform to WCAG 2.0 Level A, then both of the following are true:

• (a) Option to Retain: the authoring tool provides authors with the option to retain the accessibility information in another way if possible (e.g., as a "comment", by saving a backup copy) and
• (b) Warning: the authoring tool notifies authors that this will result in Web content accessibility problems in the output. (Level A)

• Technique B.1.2.2-1 [Sufficient for (a)]: Automatically archiving a backup copy of the original content if accessibility information will be lost and notifying the author of both the location and the fact that the new location will not be available to end users needing the information.

B.1.2.3 Accessibility Information Preservation (Enhanced): If the authoring tool performs transformations or conversions during an authoring session, then any accessibility information in the pre-transformation/conversion content that is required for the Web content to conform to WCAG 2.0 Level AA or AAA is preserved and available for end users in the outputted Web content. (Level AA)

• Technique B.1.2.3-1 [Sufficient ]: Only performing transformations and conversions that preserve accessibility information.

B.1.2.4 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true (Level AA):

• (a) Preserve Accessibility Information: the authoring tool only automatically deletes Web content that it can detect is not accessibility information;
• (b) Notification Option: authors have the option to receive notification before deletion; or
• (c) No Deletion Option: authors have the option to prevent automatic deletion by the authoring tool.

• Technique B.1.2.4-1 [Sufficient]: Detecting and avoiding the deletion of any author-generated content.
• Technique B.1.2.4-2 [Sufficient for (a)]: Detecting and avoiding the deletion of author-generated content that is accessibility information.
• Technique B.1.2.4-3 [Sufficient for (b)]: Providing the author the option to confirm or override removal of content either on a change-by-change basis or as a batch process.
• Technique B.1.2.4-4 [Sufficient for (c)]: When an automatic process is to be performed that cannot be completed without removing content (even including unrecognized markup), providing the author with the option of canceling the operation.

B.1.3.1 Automatic Accessible (Level A): If the authoring tool automatically generates content, then that Web content meets WCAG 2.0 Level A prior to publishing. (Level A)

• Technique B.1.3.1-1 [Sufficient]: Ensuring that any action that the authoring tool takes without complete author knowledge that causes content to be added or modified has the result of not introducing new WCAG Level A contraventions.
• Technique B.1.3.1-2 [Advisory]: Using prompting to elicit information from the author when necessary (see Guideline B.2.1).

B.1.3.2 Automatic Accessible (Level AA): If the authoring tool automatically generates content, then that Web content meets WCAG 2.0 Level AA prior to publishing. (Level AA)

• See Techniques for B.1.3.1 using WCAG Level AA.

B.1.3.3 Automatic Accessible (Level AAA): If the authoring tool automatically generates content, then that Web content meets WCAG 2.0 Level AAA prior to publishing. (Level AAA)

• See Techniques for B.1.3.1 using WCAG Level AAA.

B.2.1.1 Guide Accessible (Level A): If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level A (Level A).

• Technique B.2.1.1-1 [Sufficient]: Ensuring that all instruction text would, if followed exactly by the author, leads to content being created or modified so as to meet WCAG Level A.
• Technique B.2.1.1-2 [Sufficient]: Consistently labeling help documents or other documentation such that, if followed exactly by the author, it would lead to content being created or modified to not meet WCAG Level A.

B.2.1.2 Guide Accessible (Level AA):If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level AA (Level AA).

• See Techniques for B.2.1.1 using WCAG Level AA.

• See Techniques for B.2.1.2 using WCAG Level AA.

B.2.1.3 Guide Accessible (Level AAA):If the authoring tool automatically prompts authors for any information as Web content is being added or updated (e.g., by an image modification dialog), then automatic prompts are also included for any accessibility information required for that content to meet WCAG 2.0 Level AAA (Level AAA).

• See Techniques for B.2.1.1 using WCAG Level AAA.

• See Techniques for B.2.1.2 using WCAG Level AAA.

B.2.2.1 Check Accessibility (Level A): At least one individual check is associated with each WCAG 2.0 Level A Success Criterion that the authoring tool has the functionality to modify (e.g., an HTML authoring tool that inserts images should check for alt text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A)

• Technique B.2.2.1-1 [Sufficient]: Providing accessibility checking for the various success criteria in WCAG, identified as Level A. In some cases several checks may be required to appropriately test whether a WCAG success criterion has been met.
• Technique B.2.2.1-2 [Advisory]: Providing a listing of the checks performed in the conformance claim.

B.2.2.2 Availability: Checking is available prior to publishing in a manner appropriate to the workflow of the authoring tool. (Level A)

• Technique B.2.2.2-1 [Sufficient]: Providing accessibility checking as an action (e.g., as a menu item, etc.) at all times.
• Technique B.2.2.2-2 [Sufficient]: Prompting the author to perform an accessibility check if the author chooses to close or publish the content

B.2.2.3 Help Authors Locate: For any checks that require author judgment to determine whether a potential Web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant Web content is identified (e.g., displaying the content, displaying line numbers, etc.) (Level A)

• Technique B.2.2.3-1 [Sufficient]: Identifying the entire span of elements covered by a potential accessibility problem.
  • Example: A instruction-level authoring tool displays errors in a separate pane by the line number of the first element in the span.
  • Example: A instruction-level authoring tool displays errors in-line by underlining all of the markup for the affected span of elements.
  • Example: A WYSIWYG authoring tool displays errors in-line with the rendered content in the WYSIWYG editing view as blue outlining around or under the affected span of elements.
• Technique B.2.2.3-2 [Advisory]: Displaying manual checks in a way that balances the need for the author to make specific changes to some kinds of content (e.g., non-text objects, acronyms, table cells, etc.) while not overwhelming the author with numerous manual checks for other kinds of content that can be checked more generally (e.g., background color contrast, reading level, etc.). Excessively general checks (e.g., "does the page meet all of the requirements?") should be avoided.

B.2.2.4 Help Authors Decide: For any checks that require author judgment to determine whether a potential Web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided to help authors to decide. (Level A)

• Technique B.2.2.4-1 [Sufficient]: Ensuring that the wording of prompts answers the following questions: "What part of the content should be examined?" and "What is present or absent in the event that the problem exists?".
• Technique B.2.2.4-2 [Advisory]: Saving author judgments for manual checks and only prompting for new judgments after substantial changes is a more user-friendly approach.
• Technique B.2.2.4-3 [Advisory]: Providing preview modes to authors view their content in ways it may be viewed by others, but that they may not have considered:
  • an alternative content view (with images and other multimedia replaced by any alternative content)
  • a monochrome view (to test contrast)
  • a collapsible structure-only view (to test keyboard navigation)
  • a text to speech view (to test the availability of text alternatives)
  • no scripts view
  • no frames view
  • no style sheet view
  • Example: A WYSIWYG authoring interface includes a list of rendering options as sub-menu options of a View menu. The options include "All" (i.e., render as in a generic browser), "text-only" (i.e., non-text items replaced by textual equivalents), "no styles", "no frames", and "grayscale" (used to check for sufficient contrast). In the background, the "earth rise" image in the WYSIWYG view can be seen in grayscale. (Source: mockup by AUWG)
    

B.2.2.5 Check Accessibility (Level AA): At least one individual check is associated with each WCAG 2.0 Level AA Success Criterion that the authoring tool has the functionality to modify. (Level AA)

• See Techniques for B.2.2.1 using WCAG level AA.

B.2.2.6 View Status: If the authoring tool records Web content accessibility problems found during checking, then a list of any problems is available to authors prior to the end of the authoring session. (Level AA)

• Technique B.2.2.6-1 [Sufficient]: Providing the option to view a single consolidated list of all of the accessibility problems that are detected by the checking function (see Guideline B.2.2), organized by problem type and number of instances.
• Technique B.2.2.6-2 [Advisory]: Providing direct links to additional help and repair assistance from the list of accessibility problems.

B.2.2.7 Save Status for Repair: If repair assistance is not provided during checking , authors have the option to save a list of Web content accessibility problems to facilitate interoperability between checking and repair. (Level AA)

• Technique B.2.2.7-1 [Sufficient]: Providing the option of storing accessibility status information in a format that can be processed by a variety of tools (e.g., using Evaluation and Repair Language [EARL]).

B.2.2.8 Metadata for Discovery: If the authoring tool records accessibility status, then authors have the option to associate this status with the Web content as metadata to facilitate resource discovery by end users. (Level AA)

• Technique B.2.2.8-1 [Sufficient]: Providing the option of storing accessibility status information using the IMS AccessForAll Meta-data mechanism [ACCESSFORALL].

B.2.2.9 Check Accessibility (Level AAA): At least one individual check is associated with each WCAG 2.0 Level AAA Success Criterion that the authoring tool has the functionality to modify. (Level AAA)

• See Techniques for B.2.2.1 using WCAG level AAA.

B.2.3.1 Repair Accessibility (Level A): For each WCAG 2.0 Level A Web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level A)

• Technique B.2.3.1-1 [Sufficient]: For each potential accessibility problem identified by the checking function (required in Guideline B.2.2), providing repair instructions that an author (with sufficient skill and knowledge to use the rest of the tool) could follow to correct the problem. At the authoring tool developer's discretion, semi-automated repairs (that prompts the author for required information) or automated repairs (that are able to complete the repair without prompting the author) may be substituted.
• Technique B.2.3.1-2 [Advisory]: Providing as much automated repair as possible. Where necessary provide semi-automated repairing (see Appendix C: Levels of Repair Automation). Where neither of these options is possible, provide manual repairing.
• Technique B.2.3.1-3 [Advisory]: When appropriate, reusing affected elements' property editing mechanisms. This has the advantage that the author is already somewhat familiar with the interface. However, this practice does not necessarily focus the author's attention on the dialog control(s) that are relevant to the required correction.
• Technique B.2.3.1-4 [Advisory]: Implementing a special-purpose correcting interface, analogous to a spelling or grammar checker, that includes only the input field(s) for the information currently required. Additional information and tips that the author may require in order to properly provide the requested information can be added.
  • Example: A special-purpose correction interface supports the author's repair task by providing (1) a short description of the problem (here: "Missing Alternate Text Label for an Image"), (2) a preview (here: the "earthrise" image that is missing a label), (3) tips for performing the repair (here: "Alternate text should be 10 words or less and should include any text in the image."; "Image buttons should have alternate text that describes the button function."; and "Image bullets should have "bullet" as alternate text."), and (4) an offered semi-automated repair in an editable drop-down box (here: "An earth rise as seen from the moon"). (Source: mockup by AUWG)
    
  Technique B.2.3.1-5 [Advisory]: Presenting accessibility problems and repair options in a sequential manner analogous to a typical spelling or grammar checking "wizard". Because of the wider range of problems an accessibility checker needs to handle (i.e., missing text, missing structural information, improper use of color, etc.), the interface template will likely need to be especially flexible.
  • Example: A sequential accessibility checker. The special-purpose correction interface from the previous example is supplemented by a progress indicator ("5 of 25") and navigation buttons to move backwards ("back") and forwards ("skip") through the list of repair tasks. Buttons to "repair", get "help" and "cancel" are also provided. (Source: mockup by AUWG)
    
  Technique B.2.3.1-6 [Advisory]: Where an authoring tool is able to detect site-wide errors, allowing the author to make site-wide corrections. This should not be used for alternative content when the function is not known with certainty (see Guideline B.2.4).
• Technique B.2.3.1-7 [Advisory]: Providing a mechanism for authors to navigate sequentially among uncorrected accessibility errors. This allows the author to quickly scan accessibility problems in context.
• Technique B.2.3.1-8 [Advisory]: Consulting the Techniques for Accessibility Evaluation and Repair Tools [AERT] Public Working Draft document for evaluation and repair algorithms.

B.2.3.2 Repair Accessibility (AA): For each WCAG 2.0 Level AA Web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level AA)

• See Techniques for B.2.3.1 using WCAG Level AA.

B.2.3.3 Repair Accessibility (AAA): For each WCAG 2.0 Level AAA Web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level AAA)

• See Techniques for B.2.3.1 using WCAG Level AAA.

B.2.4.1 Editable: Authors are able to modify alternative content for non-text content. This includes types of alternative content that may not typically be displayed on screen by user agents. (Level A)

• Technique B.2.4.1-1 [Sufficient]: Proving editing mechanisms for all applicable alternative content types in a properties editor.
• Technique B.2.4.1-2 [Sufficient]: Providing a mechanism for the author to accept, modify, or reject any alternative content that the authoring tool supplies during the insertion process.
• Technique B.2.4.1-3 [Advisory]: Allowing the author to accept patterns of future uses of an alternative content under certain conditions (e.g., whenever the same non-text content is marked with the same semantic role).
• Technique B.2.4.1-4 [Advisory]: If the author changes the alternative equivalent for non-text content, asking the author whether all instances of the non-text content with the same known function should also be updated.
• Technique B.2.4.1-5 [Advisory]: Providing an editing capability for any alternative content managed by the tool.
  • Example: A text equivalents registry viewer allows the author to query and edit the various text equivalents stored in the registry. For maximum flexibility, the design takes into account multiple non-text content objects of the same name, multiple types of text equivalents for each non-text content object, and multiple versions of each text equivalent type. In the viewer shown here, the author has selected "image" as the "media type" and then selected pic123.gif as the "content" to edit. This has brought up a rendering of the "earthrise" image. The viewer also shows that the content has three text labels. The author has selected one ("An earth rise as seen from the moon") in order to edit it. In addition some authoring tips are included ("Alternate text should be 10 words or less and should include any text in the image", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have "bullet" as alternate text."(Source: mockup by AUWG)
    

B.2.4.2 Automated suggestions: During the authoring session, the authoring tool can automatically suggest alternative content for non-text content only under the following conditions: (Level A)

• (a) author control: authors have the opportunity to accept, modify, or reject the suggested alternative content prior to insertion and
• (b) relevant sources: the suggested alternative content is only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description).

• Technique B.2.4.2-1 [Sufficient]: Placing, within the appropriate field of the non-text content editing dialog box, a text alternative (or multiple alternatives if a drop-down is used) that was obtained from one of the acceptable sources.

B.2.4.3 Let user agents repair: After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text content using text values that is equally available to user agents (e.g., the filename is not used). (Level A)

• Technique B.2.4.3-1 [Sufficient]: Not attempting to repair alternative content that is equally available to user agents.

B.2.4.4 Special Values: The authoring tool follows recommendations on special values for alternative content (e.g., in HTML4, alt="" denotes images that should be ignored by assistive technology). (Level A)

• Technique B.2.4.4-2 [Advisory]: In HTML4, not using alt="" to denote unknown alt text.

B.2.4.5 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse. (Level AA)

• Technique B.2.4.5-1 [Sufficient]: Maintaining a registry that associates object identity information with the text and URIs of alternative information (e.g., making use of the Resource Description Framework (RDF) [RDF10]). Whenever an object is used and an alternative content is collected, via prompting (see Guideline B.2.1) or repair (see Guideline B.2.3) the object's identifying information and the alternative information is added to the registry. The stored alternative information is presented back to the author as default text in the appropriate field, whenever the associated object is inserted.
• Technique B.2.4.5-2 [Advisory]: Allowing several different versions of alternative information to be associated with a single object.
• Technique B.2.4.5-3 [Advisory]: Ensuring that the stored alternative information required for pre-authored content (see Guideline B.1.5) is made interoperable with the management system to allow the alternative equivalents to be retrieved whenever the pre-authored content is inserted.
• Technique B.2.4.5-4 [Advisory]: Using the stored alternatives to support keyword searches of the object database (to simplify the task of finding relevant images, sound files, etc.).
• Technique B.2.4.5-5 [Advisory]: Allowing the equivalents alternatives registry to be made shareable between authors in collaborative systems.

B.2.5.1 Templates "A" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level A when used. (Level A)

• Technique B.2.5.1-1 [Sufficient]: Ensuring all templates meet at least WCAG Level A when used.

B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates, then there are accessible template options for a range of template uses. (Level A)

• Technique B.2.5.2-2 [Sufficient]: Ensuring that a reasonably representative set of templates is accessible.
  • Example: A tool provides several template choices for home pages, guest books and on-line albums. For each type of functionality, the basic option is accessible.

B.2.5.3 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true (Level A):

• (a) Indicate: the selection mechanism indicates the accessibility status of templates (if known).
• (b) Prominence: any accessible template options are at least as prominent as other template options.

• Technique B.2.5.3-1 [Sufficient]: Listing the available templates and providing accessibility status as a sortable field.
• Technique B.2.5.3-2 [Advisory]: Storing the accessibility status within the template.
• Technique B.2.5.3-3 [Advisory]: Storing the accessibility status external to the template within a template management system.
• Technique B.2.5.3-4 [Advisory]: If suitable, evaluating templates for accessibility at run-time.

B.2.5.4 Templates "AA" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level AA when used. (Level AA)

• See Techniques for B.2.5.1 using WCAG Level AA.

B.2.5.5 New Templates: If authors can use the authoring tool to create new templates for use by a template selection mechanism, they have the option to record the accessibility status of the new templates. (Level AA)

• See Techniques or B.2.5.3 for ways in which the status might be stored.
• Technique B.2.5.5-1 [Sufficient]: Providing a status saving option as part of the accessibility checking feature (see Guideline B.2.2).
• Technique B.2.5.5-2 [Advisory]: Making accessibility checks mandatory before saving templates.
• Technique B.2.5.5-3 [Advisory]: Advising the author that templates should be held to a high accessibility standard, since they will be repeatedly reused.

B.2.5.6 Templates in Repository: If the authoring tool provides a repository of templates, then each of the templates has a recorded accessibility status. (Level AA)

• See Techniques for B.2.5.3 for ways in which the status might be stored.

B.2.5.7 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true (Level AA):

• (a) Indicate: the selection mechanism indicates the accessibility status of the pre-authored content (if known).
• (b) Prominence: any accessible options are at least as prominent as other pre-authored content options.

• See Techniques for B.2.5.3, reading "pre-authored content" in place of "templates".
• Technique B.2.5.7-1 [Advisory]: Ensuring that alternative content provided for pre-authored content are compatible with features to manage, edit, and reuse alternative content (see Guideline B.2.4).
  • Example: An authoring tool is shipped with a clip art collection. Each image in the collection has a short text label and long text description and the associations have all been pre-loaded into the alternative content management system so that whenever the author inserts an image its alternative content are automatically retrieved.

B.2.5.8 Pre-Authored Content in Repository: If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AA)

• See Techniques for B.2.5.3 for ways in which the status might be stored.

B.2.5.9 Templates "AAA" Accessible: If the authoring tool automatically select templates or pre-authored content, then the selection meets WCAG 2.0 Level AAA when used. (Level AAA)

• See Techniques for B.2.5.1 using WCAG Level AAA.

B.3.1.1 Accessible Options Prominent (Level A): If authors are provided with multiple options for an authoring task, options that will result in Web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not.

• Technique B.3.1.1-1 [Sufficient]: Removing less accessible options.
• Technique B.3.1.1-2 [Sufficient]: Providing the more accessible choice with a higher position in the menus and having it appear in interface shortcuts such as toolbars.
  • Example: An authoring tool that supports two methods for setting text color: using CSS and using font. Since using CSS is the more accessible option, it is given a higher prominence within the authoring interface by: (1) the "CSS Styling" option appearing above the "FONT Styling" option in the drop down Text menu, and (2) the CSS styling option being used to implement the one-click text color formatting button in the tool bar. The association is made clear because the toolbar button has the same icon (an "A" beside a color spectrum) as the "Color" sub-menu item under the "CSS Styling" menu option.). An (Source: mockup by AUWG)
    

B.3.1.2 Accessible Options Prominent (Level AA): If authors are provided with multiple options for an authoring task, options that will result in Web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not.

• See Techniques for B.3.1.1 using WCAG Level AA.

B.3.1.3 Accessible Options Prominent (Level AAA): If authors are provided with multiple options for an authoring task, options that will result in Web content conforming to WCAG 2.0 Level AAA are at least as prominent as options that will not.

• See Techniques for B.3.1.1 using WCAG Level AAA.

B.3.2.1 Sequencing Features: Features that sequences authoring actions for authors (e.g., "wizard"-type mechanisms) provide any accessibility prompts relevant to the content being edited at or before the first opportunity to successfully complete the sequence. (Level AA)

• Technique B.3.2.1-1 [Sufficient]: Features that sequence author actions are all structured to ensure that accessibility prompts appear before the first end point of the feature.

B.3.2.2 Sequenced Instructions: Instructions (e.g., tutorials, reference manuals, design guides) that consist of a sequence of steps for authors to follow include the relevant accessible authoring practices in the sequence before the first opportunity to successfully complete the sequence. (Level AA)

• Technique B.3.2.2-1 [Sufficient]: Instructions are all structured to ensure that accessibility guidance is provided before the first end point of the instruction.

B.3.3.1 Active by Default: All accessible content support features are turned on by default. (Level A)

• Technique B.3.3.1-1 [Sufficient]: Ensuring that all accessible content support features are turned on by default within the authoring tool preferences area.
  • Example: The preference setting area of an authoring tool, open to an "Accessibility" section, shows the default settings. "W3C-WCAG" and a level (e.g. "Double-A") are selected as are the following options: "Check accessibility as you type", "Check accessibility after saving", "Auto-correct when possible", "Highlight accessibility related fields", "Prompt when highlighted fields are left blank", and "Provide accessibility 'Quick Tips'". (Source: mockup by AUWG)
    

B.3.3.2 Reactivate Option: If authors turn off an accessible content support feature, then they can always turn on the feature. (Level A)

• Technique B.3.3.2-1 [Sufficient]: Providing an authoring tool preferences area where any deactivated features can be reactivated.

B.3.3.3 Deactivation Warning: If authors deactivate an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. (Level AA)

• Technique B.3.3.3-1 [Sufficient]: Providing the author with a warning whenever an accessible content support feature is turned off (e.g., from the authoring tool preferences area.
  • Example: In an authoring tool, the author has unchecked a "highlighting accessibility related fields" feature the tool. As a result the tool displays a warning that reads "You have just turned off the highlighting accessibility related fields feature. This feature is designed to inform you when information must be provided in order for your documents to comply with your target accessibility setting. Turning this feature off could cause your documents to be less accessible to many users. In some jurisdictions accessibility is a legal requirement. Are you sure you want to proceed?". The author has the option to answer "Yes", "No" or "Cancel". (Source: mockup by AUWG)
    

B.3.3.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of Web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors). (Level AA)

• Technique B.3.3.4-1 [Sufficient in combination]: Ensuring that prompting for accessibility information has the same prominence as prompting for information critical to content correctness (e.g., a tool that prompts the author for a required multimedia file name attribute has prompts with the same prominence for short text labels and long descriptions for that object.
  • Example: An "Image Properties" dialog box in which the input fields are ordered (from top to bottom, left to right): source ("src"), short label ("alt"), long description ("longdesc"), height, and width. The buttons at the bottom are "More...", "OK" and "Cancel". (Source: mockup by AUWG)
    
• Technique B.3.3.4-2 [Sufficient in combination]: Ensuring that utilities for checking and repairing accessibility problems has the same prominence as utilities for checking for information critical to content correctness (e.g., a tool that checks for spelling, grammar, or code syntax will have checks with the same prominence as checking for accessibility problems).
  • Example: An authoring interface that checks for and displays spelling and accessibility errors with the same prominence in that both are shown as underlines, one red, one blue. In this case, the author has activated a right-click pop-up menu on the word "CHZ" that includes spelling repair options ("1 Khz", "2 Chi", "Check Spelling...") and accessibility repair options ("Repair: Set acronym expansion…", "Skip", "Ignore", and "Check Accessibility...") and "Help...". (Source: mockup by AUWG)
    
• Technique B.3.3.4-3 [Sufficient in combination]: Ensuring that documentation for accessibility has the same prominence as documentation for information critical to content correctness. (e.g., a tool that documents any aspect of its operation will have documentation with the same prominence for accessibility).
  • Example: Accessibility documentation is part of the main documentation of an authoring tool, with very similar prominence to that of the spelling-related features. In the right pane is the documentation table of contents, where "Accessibility Features" appears as a top level topic just below "Spelling Features". In the left panel is the help text, demonstrating a style typical of the rest of the help system: "Checking for Accessibility: A variety of accessibility checking options are available: Accessibility verifier, Check accessibility as you type, Manual test support materials. These are suitable for use at different times during the authoring process and all have options that can be changed with the accessibility preferences. To get more information on accessible Web content, see the References.". (Source: mockup by AUWG)
    

B.3.4.1 Instructions: Instructions for using the accessible content support features appear in the documentation. (Level A)

• Technique B.3.4.1-1 [Sufficient]: Ensuring that the help system answers the question "What features of the tool encourage the production of accessible content?" with reference to all of the accessible content support features and for each feature identified, the help system answers the question "How are these features operated?".
• Technique B.3.4.1-2 [Advisory]: Providing direct links from accessible content support features to context sensitive help on how to operate the features.
• Technique B.3.4.1-3 [Advisory]: Providing direct links from within the accessibility-related documentation that take the author directly to the relevant accessible content support features.
• Technique B.3.4.1-4 [Advisory]: During prompting and repairs, providing the author with immediate access to some basic accessibility documentation and one-step access to more comprehensive documentation.
  • Example: An accessibility checker includes some limited tips for authoring short text labels listed beneath the text entry area as well as a "Help" button linking to the full documentation. The tips are: "Alternate text should be 10 words or less and should include any text in the image.", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have 'bullet' as alternate text.". The screen shot also includes the name of the problem ("Missing Alternate Text Label for an Image"), a field for adding the short text label and a preview rendering of the image ("earthrise"). At the bottom are five buttons: "Help", "< Back", "Repair", "Skip", and "Cancel". (Source: mockup by AUWG)
    

B.3.4.2 Accessible Authoring Tutorial: A tutorial on the accessible authoring process that is specific to the authoring tool is provided. (Level AAA)

• Technique B.3.4.2-1 [Sufficient]: Providing a tutorial that describes how to use the authoring tool to increase the accessibility of Web content. The tutorial begins at the typical starting point for the tool (e.g., empty document) and, for example, describes how accessibility prompting should be followed as content is being added or modified. The tutorial also covers when and how checking and repair should be performed.
• Technique B.3.4.2-2 [Advisory]: Ensuring that wherever rationales appear, the text avoids referring to accessibility features as being exclusively for particular groups (e.g., "for blind authors"). Instead, the rationales emphasize the importance of accessibility for a wide range of content consumers, from those with disabilities to those with alternative viewers (see "Auxiliary Benefits of Accessibility Features", a W3C-WAI resource).
• Technique B.3.4.2-3 [Advisory]: Providing a dedicated accessibility section.
• Technique B.3.4.2-4 [Advisory]: Providing context-sensitive help definitions for accessibility-related terms.
• Technique B.3.4.2-5 [Advisory]: Including pointers to more information on accessible Web authoring, such as WCAG and other accessibility-related resources.
• Technique B.3.4.2-6 [Advisory]: Including pointers to relevant technology specifications. This is particularly relevant for languages that are easily hand-edited, such as most XML languages.
• Technique B.3.4.2-7 [Advisory]: Calling author attention to accessibility-related idiosyncrasies of the tool compared to other authoring tools that create the same kind of content.
  • Example: Content might need to be saved before an automatic accessibility checking feature becomes active.

B.3.5.1 Model Accessible Practice (Minimum): Any examples of authoring practices in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices. (Level AA)

• Technique B.3.5.1-1 [Sufficient]: Ensuring that in the authoring tool documentation, all examples of content conform to WCAG Level A and also that all screen shots of the authoring tool interface are in states that corresponds with the production of content that conforms to Level A (e.g., prompts filled in, optional accessibility features turned on, etc.).
  • Example: Documentation for the input element in this instruction-level authoring tool makes use of the label element in an example in order to reinforce the routine nature of the pairing. The help text reads: "Input Element: Input elements are form controls. They let the reader of your page use text entry, checkboxes, radio buttons, etc. to interact with your page. The most important attribute of the INPUT element is type. The value of type can be: button, checkbox, file, hidden, image, password, radio, reset, submit, and text. Examples:<label>Enter your name: <input type="text" name="name" maxlength="30"></label><input type="submit">. (Source: mockup by AUWG)
    
• Technique B.3.5.1-2 [Advisory]: Ensuring all examples of content pass the authoring tool's own accessibility checking mechanism (see Guideline B.2.2).
• Technique B.3.5.1-3 [Advisory]: Ensuring that the documentation includes at least one model of a wide range of WCAG Level A accessible authoring practices.
• Technique B.3.5.1-4 [Advisory]: Ensuring plug-ins that update the accessibility features of a tool also update the documentation examples.

B.3.5.2 Model "AA" Accessible Practice (Enhanced): Any examples of authoring practices in the documentation demonstrate WCAG 2.0 Level AA accessible authoring practices. (Level AAA)

• See Techniques for B.3.5.1 using WCAG Level AA.