Level A (Yes)

Level AA (Yes)

Level AAA (No )

Level A (Yes)

Level AA (Yes)

Level AAA (No )

Web Content Accessibility Guidelines 2.2

Level A (Yes)

Level AA (Yes)

Level AAA (No )

Most elements added to a page provide for the option to include Screen Reader and/or alt text. For elements that cannot have alt text assigned, authors can use text-based alternatives, such as Screen Reader text to communicate meaning.

Screen Reader text is a dominKnow feature that allows an author to add additional text-based context to an element which is rendered as an ARIA label in the published output.

Components of the following elements have non-text content but do not support or have limited support for the addition of alt text or other text alternatives such as Screen Reader text: Icons, Guide Me Simulation, Scenario images, Thermometers, Flip Set images, Flash Card images, Match Card images, Drag and Drop style questions, Hotspot questions, and Menu status indicators. Note: for many of these, alternative options exist – IE a flip set, use text instead of an image.

Guides to writing Alt Text

NOTE: Release 7.4.5.0.0 will include enhancements for text alternatives for icons, flip sets, flash cards, match cards. It also will include status indicators for menus.

Authors can add text-based alternatives for audio-only and video-only content.

For audio-only content, authors can add a transcript to the audio file itself or use text-based alternatives.

For video-only content, authors can provide a text description using text-based alternatives.

Working with Transcripts for Audio Files, Video Files and Pages >> https://dki.io/b14d0f5f

For captioning, authors can import closed caption files into video players.

System supported closed caption files include: SRT, VTT, and SBV.

Easy Closed Captioning (CC) File Upload for Videos with Multi-language Support >> https://dki.io/98da8568

What is a Closed Caption File?

Guides and Tools for creating Closed Captions

Most elements are programmatically formatted to communicate informational relationships.

Interactions that need additional descriptive text include: Input Toggle, Learner Progress Radial Gauge, and Carousel.

Interactions that are simply not compliant because of inherent reliance on visual cues only: Sorting, Matching, Fill in the Blanks, and Sequencing interactions.

Release 7.4.5.0.0 will include enhancements to carousels and form controls.

1.3.2 Meaningful Sequence (Level A)

Content built in dominKnow Flow follows a top-to-bottom, left-to-right reading order by default. 

Authors should be aware of breakpoints and how responsive flow drives reading order. The author can control the order of content presented by placing the elements in sequenced Rows, Groups, and Sections.

Content built with Claro uses layer order for flow/tab order. Authors should review their layer order to make sure content proceeds in the intended reading order.

Authors should limit inline Pulldowns and inline Fill-in-the-Blank questions to one answer, so the association between question text and answer choice is clear.

Authors should provide complementary alternatives to explain information when color is used to convey information or instructions. Use patterns, textures, or text labels to differentiate information. 

Some question interactions display correct/incorrect selections using color, such as Practice/Exam Multiple-Choice, Matching, and Sequencing questions and Question/Exercises Click the Word, Matching, and Sequencing. In these cases, authors should include text-based feedback that indicates the correct/incorrect selections.

Default colors for questions can be set with the Theme Designer.

Audio and video players include play/pause and mute controls by default.

Authors can enable a more extensive set of controls or build custom controls that offer greater control of media by the learner. 

Controlling audio files.

Most elements in courses developed with dominKnow Flow support keyboard accessibility.

Exceptions include: Markers, Video Playlist, Image Hotspot, Guide Me Simulation Job Aid, Sorting, and Drag and Drop style interactions.

Content developed with native elements supports navigation of all content without keyboard traps.

For custom HTML Widgets, authors should provide learners with a way to utilize keyboard controls to exit the HTML Widget content.

The built-in keyboard content controls meet this standard and are only active on focus.

Media elements have shortcut keys/interactions but are not active when those objects are not in focus.

Authors can create actions/triggers that give the user the ability to manipulate or extend the time limit and reveal notifications based on the time limit.

Authors should avoid using system timer variables as actions/triggers cannot be set by the author to give the user the ability to manipulate or extend the time limit and reveal notifications based on the time limit.

Default media players provide pause and stop controls for media. Content produced in dominKnow Flow does not inherently include moving, blinking, scrolling, or auto-playing content natively.

If this media is included by the authors, they should provide the learner with custom pause, stop, or hide functions for moving, blinking, scrolling, or auto-updating content.

Content produced in dominKnow Flow does not inherently include anything that flashes or blinks more than three times a second.

When adding animations or videos, authors should refrain from using content that flashes or blinks more than three times a second.

Trace Research and Development Center: Learn more about photosensitivity and how to test for it with your video and animated content.

Authors should select a WCAG accessible theme. These Themes are identified with a “WCAG” badge in the Theme Browser. These Themes include skip navigation controls by default.

The course title will be automatically used as the page title that appears in the browser tab using the attribute.

Title refers to the content focus as a whole. To further enhance this capability, we are adding ARIA live regions in 7.4.5 enabling subtopics (pages etc.) to be announced.

Flow content follows a top-to-bottom, left-to-right focus order by default.

The author can control the order of content presented by placing the elements in sequenced Rows, Groups, and Sections.

Claro content follows a bottom-to-top layer order controlled by the author.

dominKnow | ONE enables authors to create links with descriptive link text.

dominKnow Flow includes and supports creation of single point operations for all functions.

Stock functions, such as Theme navigation buttons, include the name that matches the text that is presented visually.

Authors can also achieve this with custom elements. Make sure that Alt/Screen reader text matches on-screen labels.

Authors can select the language in the course’s Properties.

A language identifier is automatically added to the published output for screen readers. No further work is required by authors.

e.g., When the project language is selected the system adds the identifier (lang="fr-FR" for French (France))

By default, content does not change context when focus is brought to the element.

When developing custom content that changes context on focus, authors should provide proper explanation.

By default, content does not change context on input.

When authors develop custom content that changes context on input, proper explanation should be provided beforehand.

dominKnow | ONR provides a consistent framework that enables authors to develop content where Help is available in a consistent place.

Authors can use Themes and/or Master Headers/Footers to display content in a consistent place across pages.

dominKnow | ONE will automatically warn learners on practice and test questions if they do not make a response choice when submitting.

Authors can also use actions/triggers to provide custom validations and feedback for any actions or submissions created with form controls or other elements.

Authors can use variables to automate redundant entry.

4.1.1 Parsing (Level A)

WCAG 2.0 and 2.1 – Always answer ‘Supports’

WCAG 2.2 (obsolete and removed)

WCAG-compliant Themes provide distinct semantic groups, ARIA landmarks, and structured controls that follow a consistent order and hierarchy.

Supports

Supports

Form Controls are labelled in a way that can be determined programmatically. dominKnow | ONE does not support auto-filling forms.

Authors can select colors for their Theme and content that meet a contrast ratio of 4.5:1 or higher.

The default coloration of some elements may not pass these criteria, such as the Toggles that use red, green, and grey colors. For these, high-contrast alternatives are provided. 

Themes also support additional color editing using CSS or JavaScript. 

See Color Contrast and Visual Impairment Tools for additional information and tools. 

Authors can develop content that does not include any images of text.

Authors can use onscreen text to represent textual elements instead of images of text.

Authors can design the Theme and page content using a contrast ratio of 3:1 or higher for images and background elements to enable learners with visual impairments to consume the content.

See Color Contrast and Visual Impairment Tools for additional information and tools. 

Content responds to custom styling applied by the learner.

Theme-based player controls are labeled and identified by default.

Authors should create headings and labels that are clear and descriptive.

A visible Focus indicator is turned on by default in all courses such that all user interface components have a keyboard focus indicator that is visible. The focus defaults to a blue rectangle. The type of line (e.g., dashed, solid, dotted), color and width can all be set at the Theme level and reused across multiple projects.

The responsive nature of the dominKnow | ONE: Flow allows for all focused elements to be visible on screen.

For custom interactions, authors should use a “scroll to” action, to ensure all revealed content will be visible on screen.

The dominKnow | ONE’s native drag-type interactions cannot be completed by a single pointer without dragging.

Authors can use alternative types of interactions that do not require the learner to complete a dragging movement.

7.4.5.0.0 release will target updating drag and drop interactions to allow for click-click.

The size of all targets for pointer inputs tested were at least 24 by 24 CSS pixels.

Authors can customize the size and spacing of buttons, hyperlink text, and selectable elements as necessary to comply with the criteria.

Themes also support additional color editing using CSS or JavaScript.   

Does Not Support

Supports

Navigational elements within built-in Themes are consistent.

For custom content, authors should create navigation in a consistent location and focus order globally.

Supports

Courses developed using built-in Themes have consistently identified components.

When creating a custom Theme or user controls/icons/buttons, authors should use the same design and identification for elements or interactions that are used more than once.

Supports

Courses include generic runtime system prompts by default. An example of this is the message that appears when the learner selects the Submit button before selecting an answer to a question.

Authors can use actions/triggers to provide custom suggestions for any actions or submissions created with form controls or other elements.

Supports

When creating elements that result in a commitment, authors should use popups or other message types and actions/triggers to provide the learner with an option to confirm the action after selecting their choice or cancel and reselect the choice.

Supports