Chapter 4: Platforms, Applications, and Interactive Content

  • 401  General
  • 402  Non-Text Content
  • 403  Distinguishable Content
  • 404  Keyboard Operation
  • 405  Time Limits
  • 406  Navigation
  • 407  Predictability
  • 408  Input Assistance
  • 409  User Preferences
  • 410  Interoperability with Assistive Technology
  • 411  Compatible Technologies
  • 412  Assistive Technology Function
  • 413  Authoring Tools

401 General

401.1 Scope.  The provisions of this chapter shall apply to platforms, applications, and interactive content and where required by Chapter 1 or where referenced by a requirement in this document.

Exception:  Platforms, applications, and interactive content complying with the WCAG 2.0 Level AA Success Criteria and Conformance Requirements and, where applicable, 409 and 413 of this chapter shall not be required to comply with other requirements of this chapter. 

Advisory 401.1 Scope.  Examples of platforms include, but are not limited to, desktop, mobile, or embedded operating systems, web browsers, plug-ins to web browsers which render a particular media or format, or a set of components which allow other applications to execute.

Examples of applications include, but are not limited to, web-based and traditional applications, such as an email client, word processor, help desk system, content management system, e-learning course, or terminal emulator.

When applications provide accessibility services that other applications use, they are also considered to be platforms.  Accessibility services are an application programming interface (API) or other mechanism for software to interact with assistive technology.

Electronic content can also function as a platform.  Some formats provide for the inclusion of interactive user interface elements and a set of accessibility services.

Examples of electronic content formats that are a platform include, but are not limited to, interactive forms, spreadsheets, web-based content which includes user inputs, and other content which includes user input functionality.

Interactive elements written only using HTML according to specification are known to meet the provisions of this part.

When scripting is used to produce web-based interactive user interface elements all requirements from this chapter and from Chapter 5 (Electronic Documents) apply.

Additional requirements for non-interactive electronic content are identified in Chapter 5 (Electronic Documents).  Those requirements are applicable to applications or interactive electronic content which includes non-interactive content.

402 Non-Text Content

402.1 Non-Text Content.  When applications contain non-text content, the non-text content shall conform to 502.

402.2 Audio and Video Content.  When an application contains audio and video content, the audio and video content shall conform to Chapter 6 (Synchronized Media Content and Players).

402.3 Alternate CAPTCHA.  When a CAPTCHA is provided, an alternative form of CAPTCHA using an output mode for a different type of sensory perception shall be provided.

403 Distinguishable Content

403.1 General.  ICT that contains audio or text content shall conform to 403.

Advisory 403.1 General.  Many individuals with visual and hearing disabilities have difficulty separating foreground and background information.  A best practice to make it easier for users to see and hear content is to separate foreground from background.

For visual presentations, this involves making sure that information presented on top of a background contrasts sufficiently with the background.  For audio presentations, this involves making sure that foreground sounds are sufficiently louder than the background sounds.

403.2 Audio Control.  ICT containing audio that plays automatically for more than three seconds shall conform to either 403.2.1 or 403.2.2.

Advisory 403.2 Audio Control.  A best practice is for ICT to conform to both 403.2.1 and 403.2.2.

403.2.1 Pause or Stop Audio.  A mode of operation shall be available to pause or stop audio.

403.2.2 Independent Volume Control.  A mode of operation shall be available to control audio volume independently from the overall platform volume.

Advisory 403.2.2 Independent Volume Control.  Individuals who use screen reading software can find it hard to hear the speech output if there is other audio playing at the same time.  This difficulty is made worse when the screen reader’s speech output is software based and is controlled by the same volume control as the sound.  Therefore, it is important that the user be able to turn off the background sound.  Having control of the volume includes being able to reduce its volume to zero (also called “mute”).

403.3 Resizable Text.  ICT shall support the ability to resize text content up to 200 percent without loss of content or functionality and without relying upon assistive technology.

Exception:  Images of text, including text used for captioning, are not required to support the ability to be resized.

Advisory 403.3 Resizable Text.  A best practice is to use text rather than images of text wherever text can be used to achieve the desired visual presentation.

404 Keyboard Operation

404.1 General.  ICT that accepts user input shall conform to 404.

404.2 Keyboard Interface.  All functionality of the ICT shall be operable through a keyboard interface without requiring specific timings for individual keystrokes.

Exceptions:  1.  When the underlying function requires input that depends on the path of a user’s movement and not just the endpoints of the movement, a keyboard interface shall not be required.

2.  When the underlying function requires voice input, and voice operation that does not require user vision is provided, a keyboard interface shall not be required.

Advisory 404.2 Keyboard Interface.  This provision refers to the underlying function of the input method.  This provision does not prohibit and should not discourage providing for mouse input or other input methods in addition to providing for keyboard operation.

An example of ICT that requires a keyboard interface is a product which by default provides for handwriting as a means to enter text.  The default input technique (handwriting) requires path-dependent input, but the underlying function (text entry) does not.  Therefore, Exception 1 is not applicable.

The phrase “without requiring specific timings” is included so that end users can enter keystrokes through a keyboard interface at their preferred pace.

Examples of “specific timings for individual keystrokes” include situations where a user would be required to repeat or execute multiple keystrokes within a short period of time or where a key must be held down for an extended period before the keystroke is registered.

The use of “MouseKeys” would not satisfy this provision because “MouseKeys” is not a keyboard equivalent to the application; it is a mouse equivalent (that is, it looks like a mouse to the application).

Advisory 404.2 Keyboard Interface Exception 1.  The phrase “underlying function requires input that depends on the path of the user’s movement, and not just the endpoints” is included as an exception to distinguish operations that cannot reasonably be controlled from a keyboard.

This exception refers to the underlying function, not to the default input technique.

An example of an underlying function that uses path dependent input is a watercolor painting program.  The brush strokes (the user’s input in this example) vary depending on the speed and duration of the movements, therefore a keyboard interface is not required.

Another example where the exception might appear to apply but does not apply, involves the use of drag and drop functionality.  Although performing a drag and drop function with a mouse would require path-dependent movement and would thus seem not to require keyboard access, here again, the underlying function, moving items from one location to another or selecting an item from one list while another item is highlighted in another list of items would in fact require keyboard access, since the moving or selecting of data can be accomplished through non-path-dependent keyboard mechanisms such as select boxes and other similar controls.

Advisory 404.2 Keyboard Interface Exception 2.  An example of a product that does not require a keyboard interface is a voice operated speaker telephone that does not have a screen and that provides for all dialing and on/off hook functions to be executed through voice commands.

404.3 No Trapping of the Keyboard Focus Cursor.  When the keyboard focus can be moved to a component of ICT using a keyboard interface, a mode of operation shall be provided to move the keyboard focus away from that component using only a keyboard interface.

Advisory 404.3 No Trapping of the Keyboard Focus Cursor.  This requirement ensures mobility of the keyboard focus.  The intent of this provision is to ensure that a product does not “trap” the keyboard focus cursor within a subsection of content.  This is a common problem that can occur when multiple formats are combined within content or embedded applications.

404.3.1 Exit Method.  The ICT shall provide an exit method that conforms to either 404.3.1.1 or 404.3.1.2 for moving the keyboard focus away from a component.

404.3.1.1 Standard Exit Method.  ICT shall use the standard exit method or standard navigation keys for the platform.

Advisory 404.3.1.1 Standard Exit Method.  The unmodified arrow or tab keys are the standard navigation keys for software used on personal computers.

404.3.1.2 Non-standard Exit Method.  The ICT shall provide instruction of the non-standard exit method to the user.

Advisory 404.3.1.2 Non-standard Exit Method.  There may be times when it is appropriate to temporarily restrict the keyboard focus cursor to a subsection of the content, as long as the user is provided instruction on how to leave that state and “untrap” the focus.

404.4 Presentation of Keyboard Shortcuts.  ICT shall provide at least one mode of operation where all keyboard shortcuts associated directly with user interface controls are presented to the user.

Advisory 404.4 Presentation of Keyboard Shortcuts.  Keyboard shortcuts include keystroke commands such as those used to activate a menu item or button, for example, the “S” of a “Save File” menu item.

An example of one mode of operation is a help screen that lists keyboard commands.

A best practice is for the keyboard shortcuts to be available directly as part of the live user interface.

This provision does not require adding keyboard shortcuts beyond those usually associated with a platform.

There are many common conventions that do not require a visual indication of keyboard shortcuts because they are not associated with specific visual elements of the user interface.  Examples include the command to switch windows (such as Alt-Tab) and the command to advance the caret in text (such as Ctrl-Arrow).

User-configurable keyboard shortcuts are not considered to be directly tied to interface elements and thus are not required to be displayed.  However, a best practice is to display user-configurable keyboard shortcuts.

404.5 Visible Keyboard Focus Indicator.  A mode of operation shall be provided so the keyboard focus indicator is visible.

Advisory 404.5 Visible Keyboard Focus Indicator.  An example of a visible keyboard focus indicator is an I-beam cursor.

The focus indicator may be provided by the interface itself or by the interface in combination with accessibility services provided by the platform.

For a text area, the presence of the default text insertion point indicator (for example, an I-beam cursor) is sufficient for most platforms to conform to this provision.

When a user relies on the keyboard to interact with content, this provision requires a visible cursor so that the user can visually determine the component with which keyboard operations will interact at any point in time.

People with low vision (but who are not using assistive technology), attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to determine where the focus is visually located.

404.6 Focus, Text Cursor, and Attributes.  Programmatically determinable object information shall include information necessary to track and modify: focus, text insertion point, and selection attributes of user interface components.

405 Time Limits

405.1 General.  ICT that contains time based content shall conform to 405.

405.2 Control Over Time Limits.  ICT shall provide a mode of operation that conforms to one of 405.2.1 through 405.2.3.

Exceptions:  1.  When the time limit is essential and user modification of the time limit would invalidate the activity, no user control over the default time limit is required.

2.  When the time limit is a required part of a real-time event and no alternative to the time limit is possible, no user control over the default time limit is required.

3.  When the time limit is at least eight hours, no user control over the default time limit is required.

Advisory 405.2 Control Over Time Limits Exception 1.  A server time out, even for security reasons, is not a situation when user modification of the time limit would invalidate the activity.  Therefore, a server time out is not an appropriate use of Exception 1.

Advisory 405.2 Control Over Time Limits Exception 2.  An example is an on-line ticket-purchasing site which gives the user two minutes to confirm a purchase before the seats are returned to the general pool.  Because tickets on such sites can sell out quickly, this is a case in which the time limit is a required part of a real-time event.  A best practice is for the site to move as much of the process out of the time-limited period as possible, allowing users to provide necessary information like name, payment method, etc., before entering the time-limited period.

Advisory 405.2 Control Over Time Limits Exception 3.  A best practice is to provide the option to turn off, adjust, or extend the time limit even when the time limit is at least eight hours.

405.2.1 Turn Off.  Before encountering a time limit, a mode of operation shall be provided for the user to turn off the time limit.

405.2.2 Adjust.  Before encountering a time limit, a mode of operation shall be provided for the user to adjust the time limit to at least ten times the length of the default time limit.

405.2.3 Extend.  A mode of operation shall be provided for the user to extend a time limit with a simple action that conforms to 405.2.3.1 and 405.2.3.2.

Advisory 405.2.3 Extend.  An example of a simple action to extend the time limit is a prompt to “press the space bar for more time.”

405.2.3.1 Expiration Warning.  The user shall be warned at least twenty seconds before a time limit expires.

405.2.3.2 Multiple Extensions.  The user shall be able to extend a time limit at least ten times.

405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates.  Moving, blinking, or scrolling information, and automatically updating information shall conform to 405.3.1 or 405.3.2 as applicable.

Exceptions:  1. Moving, blinking, or scrolling information, and automatically updating information that is an essential part of an activity shall not be required to conform to 406.4.

2.  Moving, blinking, or scrolling information, and automatically updating information that does not start automatically shall not be required to conform to 405.3.

3.  Moving, blinking, or scrolling information, and automatically updating information that is not presented at the same time and in the same location as other content shall not be required to conform to 405.3.

Advisory 405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates.  Content that is streamed, or otherwise automatically updated periodically, might not be preserved when paused.  Preservation might not be technically possible, and in many situations might be misleading.

Examples of moving, blinking, scrolling, or automatically updating information include:

  • A Web site helps users understand “how things work” through animations that demonstrate processes.  Animations have “pause” and “restart” buttons.
  • An advertisement blinks to get viewers attention but stops after five seconds.
  • A form blinks an arrow near the submit button if a user finishes filling out the form but does not activate the submit button.  The blinking stops after five seconds.
  • An animation runs in the upper portion of the page but has a “freeze animation” button near the bottom of the animation.

Advisory 405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates Exception 1.  An example of essential moving content is animation that occurs as part of a preloading phase, when interaction cannot occur during that phase for all users.  In this situation, not indicating progress would likely confuse users or cause them to think that content was frozen or broken.

Advisory 405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates Exception 2.  Automatically updating information does not start automatically when users have to activate a control to start the update and are advised of the behavior before the automatic update starts.

Advisory 405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates Exception 3.  An example is animation that is shown on a web page which requires a certain percentage of a large video file to be downloaded before video play can begin.  The animation is the only content on the web page.  The user has to wait while the video loads.  Because the moving content is not presented at the same time and in the same location as other content, no mode of operation to pause, stop, or hide the animation is required, even though the animation may run for more than five seconds for users with slower connections.

Another example is a web site that requires all users to view a fifteen second advertisement before they can access free content available from the site.  Because the advertisement is not presented in parallel with other content, a mode of operation to pause, stop, or hide the advertisement is not required.

405.3.1 Pause, Stop, or Hide.  When moving, blinking, or scrolling information lasts for more than five seconds, a mode of operation shall be provided for the user to pause, stop, or hide the moving, blinking, or scrolling information.

405.3.2 Pause, Stop, Hide, or Control Frequency.  When information updates automatically, a mode of operation shall be provided for the user to pause, stop, hide, or to control the frequency of the update.

406 Navigation

406.1 General.  ICT shall conform to 406.

Advisory 406.1 General.  A best practice is for developers to provide ways to help users navigate, find content, and determine where they are within an ICT product.

406.2 Bypass Blocks of Content.  A mode of operation shall be provided for the user to bypass blocks of content that are repeated within an ICT product.

Advisory 406.2 Bypass Blocks of Content.  The ability to bypass blocks of content is used to jump focus (or “reading”) to get to other portions of content.

An example is when the start of the content of an onscreen interface includes a set of menu options.  A user may choose to bypass this set of menu options by jumping focus to the main content.

A best practice that meets this provision is consistently providing headings within content.  Assistive technologies often allow users to navigate from heading to heading.  Therefore, consistently providing headings is providing a mode of operation that provides users the ability to bypass blocks of content.

Use of tables of content and internal “same page” links can be used to meet this requirement as they allow navigation to specific content without requiring lengthy sequential “skimming”.

406.3 Focus Order.  When content can be navigated sequentially and the navigation sequences affect meaning or operation, components that are capable of receiving focus shall receive focus in an order that preserves meaning and operation.

406.4 Multiple Ways to Locate Content.  More than one way shall be provided for a user to locate content within ICT.

Exception:  When the content is the result of, or a step in a process, more than one way for a user to locate content is not required.

Advisory 406.4 Multiple Ways to Locate Content.  Examples of ways to meet this provision include providing a site map, index, table of contents, or flexible search features.

407 Predictability

407.1 General.  ICT shall conform to 407.

Advisory 407.1 General.  A best practice is for interfaces to appear and to operate in predictable ways.

407.2 No Change of Context from Focus.  When any component receives focus, the component shall not initiate a change of context.

Advisory 407.2 No Change of Context from Focus.  A change of context is a major change in the content that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously.

This provision does not prohibit changes of context.  Changes of context are an expected consequence of the user actively interacting with components.  This provision prohibits changes of context that are triggered by the user only moving the focus around the user interface.

Users of assistive technology move the focus around the user interface in order to explore and read the web page or screen.  This provision prohibits components from activating because the component receives focus.

Focus can be indicated by keyboard, mouse-over cursor, or through other input devices.  Any component that is able to trigger an event when it receives focus must not change the context.

Examples of automatically changing context when a component receives focus which are prohibited by this provision include, form submission without a submit button, new windows opening without activation of a link (pop-over and pop-under), and changing (jumping) focus from the current component to another (perhaps on the same screen or in the same document).

407.3 No Change of Context from Change of Settings.  Changing the setting of any user interface component shall not automatically cause a change of context.

Exception:  When advance notice of a potential change in context is provided before a user activates any component which will change user interface settings, conformance with 407.3 shall not be required.

Advisory 407.3 No Change of Context from Change of Settings Exception.  An example is a form which contains an auto-advance feature, which is described to the user at the beginning of the form.  The form requires the user to enter a series of identification numbers.  After the user enters a certain number of digits in each field, the focus automatically moves to the next field, without requiring the user to press enter or tab.

407.4 Consistent Navigation Order.  When navigation mechanisms are repeated within an ICT product, they shall occur in the same relative order each time they are repeated.

Exception:  When a change to the navigation mechanism is initiated by the user, conformance to 407.4 shall not be required.

407.5 Consistent Identification.  Components that have the same functionality within an ICT product shall be identified consistently.

408 Input Assistance

408.1 General.  ICT shall conform to 408.

408.2 Input Error Identification and Description.  When an input error is automatically detected, the item that is in error shall be identified, and the error shall be described to the user in text.

Advisory 408.2 Input Error Identification and Description.  The intent of this provision is to ensure that users are aware that an error has occurred and can determine what is wrong.

A best practice is for the error identification and description to be as specific as possible.

409 User Preferences

409.1 General.  Applications, including web applications, shall conform to 409.

409.2 User Preferences.  Applications shall provide a mode of operation that uses user preferences for platform settings for color, contrast, font type, font size, and focus cursor.

409.2.1 Underlying Platform Settings.  Applications that are also platforms shall provide a mode of operation that uses the underlying platform’s settings for color, contrast, font type, font size, and focus cursor.

Advisory 409.2.1 Underlying Platform Settings.  An example of an application that is also a platform is a web browser. 

410 Interoperability with Assistive Technology

410.1 General.  Platforms, including applications which are also platforms, and software toolkits for those platforms shall conform to 410.

Exception:  Platforms, including applications which are also platforms, and software toolkits for those platforms, that have closed functionality, shall not be required to conform to 410.

Advisory 410.1 General Exception.  Requirements for ICT that has closed functionality are found in 302 (Closed Functionality).

410.2 Accessibility Services.  Platforms and software toolkits for those platforms shall provide a set of accessibility services that support a mode of operation for applications running on the platform to interoperate with assistive technology.

410.3 Documented Accessibility Usage.  Platforms and applications that have platform documentation available to application developers shall conform to both 410.3.1 and 410.3.2.

410.3.1 User Control of Accessibility Features.  Platforms shall provide a mode of operation for end-user control over platform features that are defined in the platform documentation as having an accessibility usage.

410.3.2 No Disruption of Accessibility Features.  Applications shall not disrupt platform features that are defined in the platform documentation as having an accessibility usage.

410.4 Object Information.  Information about components, interactive elements, and other objects shall be programmatically determinable using platform accessibility services.

Advisory 410.4 Object Information.  Object information must be exposed to assistive technologies using information from content, application, or platform accessibility services as is most appropriate for the ICT.  When access to remote graphical user interfaces is provided by software, such software must expose the object information from the remote system to the assistive technology for use. 

Delivering the object information to the assistive technology from a remote graphical user interface is not equivalent to operating the assistive technology remotely. 

Operation of assistive technology remotely does not meet the requirements for providing the objective information via content, or application or platform accessibility services.  While remote operation of assistive technology can provide functional access in some circumstances, currently such solutions are not scalable to a general solution for more than very small environments, and are limited only to specific assistive technologies. 

Additionally, it is a best practice for platform software and accessibility services to include keyboard shortcuts and implicit designators in the object information that is exposed.

411 Compatible Technologies

411.1 General.  ICT content shall conform to 411.

Advisory 411.1 General.  ICT content includes information and sensory experience communicated to the user and encoding that defines the structure, presentation, and interactions associated with those elements.  Examples of content are text, images, sounds, videos, controls, and animations.

A best practice is to maximize compatibility with current and future technologies, including assistive technology.

411.2 User Interface Components.  User interface components found in content shall conform to 411.2.1 through 411.2.4.

Advisory 411.2 User Interface Components.  Providing role, state, and value information on all user interface components enables compatibility with assistive technology.  Examples of assistive technology that can make use of role, state, and value information include screen readers, screen magnifiers, and speech recognition software.

This provision is primarily aimed at content providers who develop or script their own user interface components and includes but is not limited to form elements, links, and components generated by scripts.

For example, standard HTML controls and form elements conform to this requirement when used according to specification.

A best practice is for the information which is programmatically determinable to be descriptive.  Examples include:

  • Any possible value ranges, including any minimum or maximum.
  • Any relationship a component has as a label for, or how it is labeled by, another component.
  • The name of any parent or containing component, and a list of any children components (nesting).
  • Boundary information, including size and coordinates.
  • Whether the component can accept focus.
  • Whether the component can be used for “drag-and-drop” operations, either as object or target.

411.2.1 Name and Role.  For all user interface components, the name and role shall be programmatically determinable.

411.2.2 States, Properties, and Values.  States, properties, and values shall conform to 412.2.2.1 and 412.2.2.2.

411.2.2.1 Programmatically Determinable.  When states, properties, and values are conveyed to the user, they shall be programmatically determinable.

411.2.2.2 Set Programmatically.  When states, properties, and values can be set by the user, they shall be capable of being set programmatically.

411.2.3 Change Notification.  Notification of changes to states, properties, and values shall be available to user agents, including assistive technologies.

411.2.4 Tables.  Components in a table shall conform to 411.2.4.1 and 411.2.4.2.

411.2.4.1 Row and Column.  A component’s object information shall include row and column location within the table.

411.2.4.2 Headers.  When the table has row or column headers, a component’s object information shall include the headers associated with the row or column.

411.3 Use of Platform Accessibility Services.  Applications shall use platform accessibility services to make information about components, interactive elements, and other objects programmatically determinable.

Advisory 411.3 Use of Platform Accessibility Services.  Platform accessibility services define the rules for interaction between assistive technology, other applications, content, and the platform.

This provision requires the use by assistive technology of the information exposed through platform accessibility services to deliver the alternate interface to the user with a disability.  This ensures that electronic content designed to be accessible is available to the end-user.  An example is an alternate text description of an image, which is invisible, but which a screen reader vocalizes.

This provision is not intended to limit the creativity of assistive technology developers or to limit methods of delivering alternate user interfaces.  This provision requires that when a platform provides accessibility services, such services must be used to provide accessibility.

412 Assistive Technology Function

412.1 General.  Applications providing an alternate user interface that functions as assistive technology shall use, at a minimum, platform accessibility services to make information about components, interactive elements, and other objects programmatically determinable.

413 Authoring Tools

413.1 General.  Applications that are used for creating documents or otherwise used for authoring shall conform to 413.

Exception:  When content formats do not support the provisions of Chapter 5 (Electronic Documents), applications shall not be required to conform to 413 when working with files of those formats.

Advisory 413.1 General.  Applications that are used to create documents or otherwise used for authoring content are called “authoring tools”.

An example of an authoring tool is a web application that allows users to create new web pages.

Another example is an application for editing video.

Authoring tools can also be used to create and publish content for use with telecommunications products or services.  An example is an interactive voice response system (IVR) that includes software for the creation of content used to populate menu choices.  These requirements for authoring tools enable this content to be accessible.

413.2 Authoring Tools.  For all formats supported by the authoring tool, authoring tools shall provide a mode of operation to create or modify content that conforms to Chapter 5 (Electronic Documents).

Exceptions:  1. Simple text editors that can only create or modify content in conforming formats by directly editing raw source code shall not be required to conform to 413.2.

2.  The author shall retain the ability to override information required for accessibility.

Advisory 413.2 Authoring Tools.  Content includes information and sensory experience communicated to the user and encoding that defines the structure, presentation, and interactions associated with those elements.  Examples of content are text, images, sounds, videos, controls, and animations.

Content includes materials derived from programmatic sources.

Examples of content formats include, but are not limited to:  word processing files, presentation files, spreadsheet files, text files, PDFs, and HTML files.

Authoring tools which remove information required for accessibility do not conform to this provision.  For example, if a video editing tool is used to edit a captioned movie, the tool must not remove the captioning.

Advisory 413.2 Authoring Tools Exception 1.  Examples of content formats that do not support the provisions of Chapter 5 include image-only formats, such as JPEG, and audio-only formats, such as MP3 or audio tape.

Some audio formats do support the provisions of Chapter 5 (Electronic Documents).  An example is Daisy or National Instructional Materials Accessibility Standards (NIMAS) digital talking books.  An example of a simple text editor is an ASCII text editor such as Windows Notepad.

Advisory 413.2 Authoring Tools Exception 2.  Authoring tools which automatically provide information required for accessibility can make mistakes.  As with automated spelling or grammar checking, which also can make mistakes, it is important for authors to retain control of the process with authoring tools.

413.2.1 Preservation of Accessibility Information in Format Conversion.  When authoring tools include the ability to convert from one format to another or to save content in multiple formats, these authoring tools shall preserve the information required for accessibility to the extent that information is supported by the destination format.

Advisory 413.2.1 Preservation of Accessibility Information in Format Conversion.  When converting from one format to another, a best practice is for authors to have control over how information required for accessibility is handled in the destination format to ensure consistent use of the information required for accessibility in both formats.

413.3 Prompts.  When programmatically determinable, authoring tools shall provide a mode of operation that prompts authors to create content that conforms to Chapter 5 (Electronic Documents).

Advisory 413.3 Prompts.  Prompts do not need to be provided for every element in the content.  Overuse of prompts can decrease usability.

413.4 Templates.  When templates are provided with authoring tools, at least one template for each template type supported by the authoring tool shall conform to Chapter 5 (Electronic Documents).